CVE-2026-82909: QuantumNous new-api Auth Bypass Vulnerability

CVE-2026-82909 Overview

CVE-2026-82909 is a session management vulnerability in QuantumNous new-api through version 1.0.0-rc.15. The flaw resides in the Revoked API Token Handler at the /api/usage/token/ endpoint. Manipulating this endpoint leads to improper session expiration handling, allowing tokens in states that should be restricted to still access read-only resources. The issue is classified under [CWE-613: Insufficient Session Expiration]. The vulnerability is remotely exploitable and a public proof-of-concept has been published. Version 1.0.0-rc.17 resolves the issue via commit 0d5995eb63f8801d32eb32fbe74b75b68752bfa9.

Critical Impact

Authenticated attackers holding non-active API tokens can query read-only endpoints such as token usage logs, bypassing the intended session expiration boundary.

Affected Products

• QuantumNous new-api versions up to and including 1.0.0-rc.15
• Component: Revoked API Token Handler (middleware/auth.go)
• Endpoint: /api/usage/token/

Discovery Timeline

• 2026-08-31 - CVE-2026-82909 published to NVD
• 2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-82909

Vulnerability Analysis

The vulnerability affects the TokenAuthReadOnly middleware in QuantumNous new-api. This middleware controls access to read-only API endpoints, including token usage log queries under /api/usage/token/. Before the fix, the middleware did not explicitly reject tokens whose status was TokenStatusDisabled. As a result, tokens that administrators had revoked or disabled could still be used to retrieve read-only data. This weakens the security guarantee that revocation immediately terminates a token's ability to interact with the API. The behavior maps to [CWE-613], which covers cases where sessions or credentials remain valid beyond their intended lifetime. EPSS data places exploitation likelihood at a low probability, and the CVSS 4.0 assessment indicates limited confidentiality impact with no impact on integrity or availability.

Root Cause

The root cause is a missing status check inside TokenAuthReadOnly. The middleware validated the presence and format of a token but did not enforce the TokenStatusDisabled state before permitting downstream handlers to run. Any disabled token therefore reached the user cache lookup and continued processing read-only requests.

Attack Vector

A remote attacker who possesses a disabled or revoked API token can send an authenticated request to /api/usage/token/. The server returns usage data associated with the token rather than rejecting the call. Because privileges required are low and no user interaction is needed, exploitation reduces to sending an HTTP request with the disabled token in the authorization header.

// Security patch in middleware/auth.go (commit 0d5995e)
// fix(auth): allow read-only access for non-disabled tokens
			return
		}

		// TokenAuthReadOnly must keep allowing other token states to query read-only
		// data, such as token usage logs; only explicitly disabled tokens are denied.
		if token.Status == common.TokenStatusDisabled {
			c.JSON(http.StatusUnauthorized, gin.H{
				"success": false,
				"message": common.TranslateMessage(c, i18n.MsgTokenStatusUnavailable),
			})
			c.Abort()
			return
		}

		userCache, err := model.GetUserCache(token.UserId)
		if err != nil {
			common.SysLog(fmt.Sprintf("TokenAuthReadOnly GetUserCache error for user %d: %v", token.UserId, err))

Source: GitHub Commit 0d5995e

Detection Methods for CVE-2026-82909

Indicators of Compromise

• HTTP requests to /api/usage/token/ that succeed while the presenting API token has status TokenStatusDisabled in the tokens database table.
• Access log entries showing 200 responses on /api/usage/token/ from tokens that administrators previously revoked.
• Unexpected read-only queries originating from user accounts flagged as inactive or offboarded.

Detection Strategies

• Correlate application access logs with the tokens table to identify requests authenticated by disabled tokens.
• Add server-side audit logging inside TokenAuthReadOnly to record token status at each request boundary.
• Review the public proof-of-concept at yaowenxiao721/Poc to build signatures for the exact request pattern.

Monitoring Recommendations

• Alert on any successful response from /api/usage/token/ when the associated token status is not active.
• Monitor rates of token usage queries following administrative revocation events.
• Track deployments of new-api and confirm the running version reports 1.0.0-rc.17 or later.

How to Mitigate CVE-2026-82909

Immediate Actions Required

• Upgrade QuantumNous new-api to version 1.0.0-rc.17 or later, which contains commit 0d5995eb63f8801d32eb32fbe74b75b68752bfa9.
• Rotate all API tokens that were previously issued, especially any tokens marked as disabled but still known to third parties.
• Audit recent access to /api/usage/token/ and identify any calls made after a token's revocation timestamp.

Patch Information

The fix is available in the v1.0.0-rc.17 release of the QuantumNous new-api repository. The patch adds an explicit TokenStatusDisabled check in TokenAuthReadOnly that returns HTTP 401 and aborts the request chain before any downstream handler executes. Additional context is available at VulDB CVE-2026-82909.

Workarounds

• If patching is not immediately possible, place /api/usage/token/ behind a reverse proxy that enforces token status validation against the application database.
• Manually delete disabled token records rather than leaving them in a disabled state, so lookups fail at the token resolution step.
• Restrict network exposure of the new-api service to trusted client networks until the upgrade is completed.

# Verify the running version after upgrade
docker exec new-api /new-api --version
# Expected output: v1.0.0-rc.17 (or later)

# Confirm the patch commit is present in the deployed source
git -C /path/to/new-api log --oneline | grep 0d5995e