{"id":"CVE-2026-84321","aliases":["EUVD-2026-97864","GHSA-wq4w-vwvq-q3x9","GO-2026-6801"],"status":"published","title":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable","description":"Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GenerateShortToken creates standalone short-token records without a long Token value, but DeleteUserTokens invalidates cached entries only when the long Token field is nonempty. A revoked short token can therefore remain in the short_token cache and authenticate again if the associated account is re-enabled before the cache entry expires because GetTokenUserByShortToken reads the surviving entry, restoring access to HTTP or WebSocket routes that accept short-token authentication. This issue is fixed in version 2.4.1.","severity":{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.0021,"percentile":0.11267,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-613"],"published":"2026-10-12T20:49:36Z","modified":"2026-10-28T02:31:11Z","fixes":[{"ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","fixed_in":["1.9.10-0.20260703131214-23d1934099b0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.10-0.20260703131214-23d1934099b0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.9.10-0.20260703131214-23d1934099b0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/0xJacky/Nginx-UI","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.9.10-0.20260703131214-23d1934099b0"}]}]}],"products":[{"vendor":"0xjacky","product":"nginx-ui"}],"references":[{"url":"https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-wq4w-vwvq-q3x9","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/0xJacky/nginx-ui/commit/23d1934099b05b2a01589b48129dc3d3159d91c2","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/0xJacky/nginx-ui/releases/tag/v2.4.1","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-84321","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-wq4w-vwvq-q3x9"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/84xxx/CVE-2026-84321.json","tags":["advisory"]},{"url":"https://github.com/0xJacky/nginx-ui","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-84321","title":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable","description":"Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GenerateShortToken creates standalone short-token records without a long Token value, but DeleteUserTokens invalidates cached entries only when the long Token field is nonempty. A revoked short token can therefore remain in the short_token cache and authenticate again if the associated account is re-enabled before the cache entry expires because GetTokenUserByShortToken reads the surviving entry, restoring access to HTTP or WebSocket routes that accept short-token authentication. This issue is fixed in version 2.4.1.","status":"published","published":"2026-10-12T20:49:36.955Z","modified":"2026-10-13T15:50:29.123Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-613"],"updated_at":"2026-11-02T14:20:08.391556Z"}],"euvd":[{"id":"EUVD-2026-97864","description":"Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GenerateShortToken creates standalone short-token records without a long Token value, but DeleteUserTokens invalidates cached entries only when the long Token field is nonempty. A revoked short token can therefore remain in the short_token cache and authenticate again if the associated account is re-enabled before the cache entry expires because GetTokenUserByShortToken reads the surviving entry, restoring access to HTTP or WebSocket routes that accept short-token authentication. This issue is fixed in version 2.4.1.","status":"published","published":"2026-10-12T20:49:36Z","modified":"2026-10-13T15:50:29Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T17:27:20.028612Z"}],"ghsa":[{"id":"GHSA-wq4w-vwvq-q3x9","title":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable","description":"### Summary\nStandalone 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.\n\n### Details\n`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`.\n\nRelevant code paths:\n- [internal/user/user.go](/home/kali/Desktop/bounty/nginx-ui/internal/user/user.go:43)\n- [internal/user/user.go](/home/kali/Desktop/bounty/nginx-ui/internal/user/user.go:118)\n- [internal/user/user.go](/home/kali/Desktop/bounty/nginx-ui/internal/user/user.go:204)\n- [api/user/short_token.go](/home/kali/Desktop/bounty/nginx-ui/api/user/short_token.go:13)\n- [internal/middleware/middleware.go](/home/kali/Desktop/bounty/nginx-ui/internal/middleware/middleware.go:82)\n\n### PoC\nThis 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.\n\nWhat the executed test did:\n1. Created an enabled user in a temporary SQLite database.\n2. Called the real `GenerateShortToken(user.ID)` function to issue a standalone short token.\n3. Verified that the token authenticated successfully and was present in the short-token cache.\n4. Disabled the user and called the real `DeleteUserTokens(user.ID)` function.\n5. Verified that the database token rows were removed.\n6. Verified that the short-token cache entry still existed after `DeleteUserTokens`.\n7. Re-enabled the same user.\n8. Reused the previously deleted short token via the real `GetTokenUserByShortToken()` path and observed successful authentication.\n\nObserved result from the actual local verification:\n- The database token rows were removed during revocation.\n- The short-token cache entry remained present.\n- Re-enabling the user restored successful authentication through the stale short token.\n\n### Impact\nAny 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.","status":"published","published":"2026-10-15T20:14:01Z","modified":"2026-10-15T20:14:02Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-613"],"updated_at":"2026-11-02T14:41:32.483482Z"}],"nvd":[{"id":"CVE-2026-84321","description":"Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GenerateShortToken creates standalone short-token records without a long Token value, but DeleteUserTokens invalidates cached entries only when the long Token field is nonempty. A revoked short token can therefore remain in the short_token cache and authenticate again if the associated account is re-enabled before the cache entry expires because GetTokenUserByShortToken reads the surviving entry, restoring access to HTTP or WebSocket routes that accept short-token authentication. This issue is fixed in version 2.4.1.","status":"published","published":"2026-10-12T21:17:22.817Z","modified":"2026-10-13T16:17:23.713Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-613"],"updated_at":"2026-11-02T14:12:56.72789Z"}],"osv":[{"id":"CVE-2026-84321","title":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable","description":"Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GenerateShortToken creates standalone short-token records without a long Token value, but DeleteUserTokens invalidates cached entries only when the long Token field is nonempty. A revoked short token can therefore remain in the short_token cache and authenticate again if the associated account is re-enabled before the cache entry expires because GetTokenUserByShortToken reads the surviving entry, restoring access to HTTP or WebSocket routes that accept short-token authentication. This issue is fixed in version 2.4.1.","status":"published","published":"2026-10-12T20:49:36.955Z","modified":"2026-10-28T02:31:11.999159209Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-613"],"updated_at":"2026-11-02T15:45:18.482949Z"},{"id":"GHSA-wq4w-vwvq-q3x9","title":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable","description":"### Summary\nStandalone 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.\n\n### Details\n`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`.\n\nRelevant code paths:\n- [internal/user/user.go](/home/kali/Desktop/bounty/nginx-ui/internal/user/user.go:43)\n- [internal/user/user.go](/home/kali/Desktop/bounty/nginx-ui/internal/user/user.go:118)\n- [internal/user/user.go](/home/kali/Desktop/bounty/nginx-ui/internal/user/user.go:204)\n- [api/user/short_token.go](/home/kali/Desktop/bounty/nginx-ui/api/user/short_token.go:13)\n- [internal/middleware/middleware.go](/home/kali/Desktop/bounty/nginx-ui/internal/middleware/middleware.go:82)\n\n### PoC\nThis 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.\n\nWhat the executed test did:\n1. Created an enabled user in a temporary SQLite database.\n2. Called the real `GenerateShortToken(user.ID)` function to issue a standalone short token.\n3. Verified that the token authenticated successfully and was present in the short-token cache.\n4. Disabled the user and called the real `DeleteUserTokens(user.ID)` function.\n5. Verified that the database token rows were removed.\n6. Verified that the short-token cache entry still existed after `DeleteUserTokens`.\n7. Re-enabled the same user.\n8. Reused the previously deleted short token via the real `GetTokenUserByShortToken()` path and observed successful authentication.\n\nObserved result from the actual local verification:\n- The database token rows were removed during revocation.\n- The short-token cache entry remained present.\n- Re-enabling the user restored successful authentication through the stale short token.\n\n### Impact\nAny 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.","status":"published","published":"2026-10-15T20:14:01Z","modified":"2026-10-19T21:41:20.936879864Z","cvss":[{"version":"3.1","score":5.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-613"],"updated_at":"2026-11-02T15:46:58.767335Z"},{"id":"GO-2026-6801","title":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable in github.com/0xJacky/Nginx-UI","description":"Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable in github.com/0xJacky/Nginx-UI","status":"published","published":"2026-10-19T21:08:35Z","modified":"2026-10-19T21:31:53.420955791Z","updated_at":"2026-11-02T15:47:03.11707Z"}]}}