GitHub Advisoryadvisory · Go
GHSA-wq4w-vwvq-q3x9 Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable
MEDIUM
Official page ↗
- Aliases
- CVE-2026-84321
- Ecosystem
- Go
- Packages
- github.com/0xJacky/Nginx-UI
- Severity
- Moderate
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
- Weaknesses
- CWE-613
- Reviewed
- 2026-10-15
Affected packages
• Go github.com/0xJacky/Nginx-UI: < 1.9.10-0.20260703131214-23d1934099b0 → fixed in 1.9.10-0.20260703131214-23d1934099b0
Description
Summary
Standalone short tokens issued for WebSocket and explicit-token authentication can survive administrative revocation in cache. If the same account is later re-enabled before the cache entry expires, the deleted short token becomes valid again.
Details
`GenerateShortToken()` creates an `AuthToken` row that contains only `ShortToken` and no long `Token`. `DeleteUserTokens()` removes database rows, but when clearing caches it only invalidates entries where `authToken.Token != ""`. This leaves standalone short-token cache entries behind. `GetTokenUserByShortToken()` checks that cache first and then loads the user by ID, so the stale short token becomes usable again if the account status is restored to `true`.
Relevant code paths:
• internal/user/user.go
• internal/user/user.go
• internal/user/user.go
• api/user/short_token.go
• internal/middleware/middleware.go
PoC
This was verfied locally in an isolated environment with a temporary package-level harness that exercised the real token issuance, revocation, cache, and re-authentication paths.
What the executed test did:
1. Created an enabled user in a temporary SQLite database.
2. Called the real `GenerateShortToken(user.ID)` function to issue a standalone short token.
3. Verified that the token authenticated successfully and was present in the short-token cache.
4. Disabled the user and called the real `DeleteUserTokens(user.ID)` function.
5. Verified that the database token rows were removed.
6. Verified that the short-token cache entry still existed after `DeleteUserTokens`.
7. Re-enabled the same user.
8. Reused the previously deleted short token via the real `GetTokenUserByShortToken()` path and observed successful authentication.
Observed result from the actual local verification:
• The database token rows were removed during revocation.
• The short-token cache entry remained present.
• Re-enabling the user restored successful authentication through the stale short token.
Impact
Any deployment using standalone short tokens is affected. If a short token is stolen, administrative disable/delete-token handling may not fully revoke it. Re-enabling the account within the cache lifetime restores access for the stale token to any HTTP or WebSocket routes that accept short-token authentication.
Related
Weakness · not in database (1)
Alias · CVE (1)
- CVE-2026-84321 Nginx UI is a web user interface for the Nginx web server. vulnerability
References
- https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-wq4w-vwvq-q3x9 web
- https://nvd.nist.gov/vuln/detail/CVE-2026-84321 advisory
- https://github.com/0xJacky/nginx-ui/commit/23d1934099b05b2a01589b48129dc3d3159d91c2 web
- https://github.com/0xJacky/nginx-ui package
- https://github.com/0xJacky/nginx-ui/releases/tag/v2.4.1 web