Nginx UI EUVD-2026-97864

Exploitation requires that the attacker already possess a previously-issued short token for a user account (short-token authentication must be in use for the targeted HTTP or WebSocket routes), that the account subsequently be disabled and then RE-ENABLED, and that this re-enablement occur before the stale short_token cache entry naturally expires. The limiting factors are significant: the attacker must hold a valid pre-existing short token (PR:L, not unauthenticated), the specific administrative sequence of disable-then-re-enable must occur, and the replay window is bounded by the cache TTL - making this an opportunistic/timing-dependent flaw rather than reliably reproducible on demand against default deployments.

This is a genuine but moderate-severity session-management flaw (CWE-613, Insufficient Session Expiration), not a drop-everything priority. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N = 5.4 Medium) tells us exploitation is network-reachable, requires some existing privilege (PR:L), needs no user interaction, and yields only partial confidentiality and integrity impact with no availability effect - consistent with regaining an authenticated session rather than gaining code execution. No EPSS score, CISA KEV listing, or public POC was provided, so there is no evidence of active or probable exploitation; exploitation status is 'no public exploit identified at time of analysis.' One signal to verify: the vendor's own CVSS set AC:L, but the described mechanism is conditional and timing-dependent (a revoked short token only works if the account is re-enabled before the cache entry expires), which argues for higher attack complexity - I assess AC:H below. Also note a data-consistency caveat: the fix commit diff shown wraps backup/auto_backup routes in a RequireSecureSession middleware, which addresses secure-session enforcement for OTP users rather than the short-token cache-invalidation logic the Description attributes to this CVE, so the exact code path should be confirmed against the full v2.4.1 changeset and the GHSA-wq4w-vwvq-q3x9 advisory. Overall: a real authorization-persistence bug worth patching, but low real-world urgency absent exploitation signals.

An administrator revokes a user's access (disables the account), but a short-token record the user previously obtained survives in the short_token cache because DeleteUserTokens only invalidates entries whose long Token field is nonempty. If the account is re-enabled before that cache entry naturally expires, the holder of the old short token can present it to GetTokenUserByShortToken and silently regain authenticated access to HTTP or WebSocket routes. No public exploit code was provided; the attack is a logic/timing race rather than a memory-corruption exploit.