new-api EUVD-2026-68773

Exploitation requires the attacker to possess a previously issued new-api API token that has been explicitly set to the disabled/revoked status in the system - a revoked-but-known credential. The /api/usage/token/ endpoint must be network-reachable from the attacker. No special server-side configuration beyond a default new-api deployment is required for the vulnerable code path to be active. Exploitation is inherently self-limiting: only former token holders (e.g., ex-employees, owners of a previously leaked credential) can trigger it, and the accessible data is scoped to the usage logs associated with that token. The CVSS 4.0 PR:L rating reflects this credential prerequisite. There is no path to write access or availability impact through this vector.

The CVSS 4.0 base score of 2.1 accurately characterizes the limited blast radius of this vulnerability. The attacker must already possess a formerly valid, now-revoked API token (PR:L), and the only observable impact is low-confidentiality disclosure of usage log data (VC:L) with zero integrity or availability consequences. No EPSS score is provided in the input, so exploitation probability cannot be quantified numerically. A public POC exists but no CISA KEV listing is present, indicating no confirmed widespread exploitation - likely because the attack surface is inherently self-limiting to former token holders. The most realistic risk scenario involves revoked credentials from a leaked or departing-employee situation, where token revocation was the intended security boundary. Organizations relying on token revocation as an access-termination control face the highest realistic exposure, even though the disclosable data (a user's own usage logs) is low sensitivity.

An attacker who previously held a valid new-api token - for example, a former employee or the holder of a leaked credential that was subsequently revoked - retains the token string and sends an authenticated HTTP GET request to /api/usage/token/ on a vulnerable instance. Because the TokenAuthReadOnly middleware did not check for disabled token status before the patch, the server returns usage log data without error. A public POC demonstrating this flow is available at https://github.com/yaowenxiao721/Poc/blob/main/New-API/new-api-poc1.md.