one-api EUVD-2026-34996

Exploitation requires an authenticated user session (PR:L in CVSS vector - unauthenticated exploitation is not possible). The attacker must possess at least one valid, unused redemption code. High attack complexity (AC:H) is required: the exploit depends on winning a narrow race condition window between concurrent database transactions, which is timing-sensitive and may vary with server load, database response time, and network latency. The vulnerability only materializes in deployments where the redemption code top-up feature is enabled and in use. Limiting factors: the attacker cannot exploit this to gain root access, read data, or impact availability - the ceiling of impact is unauthorized quota credits within the application. The race window narrows further if the database server enforces transaction serialization at its own level (e.g., serializable isolation), though this is not the default for most configurations.

CVSS 4.0 scores this at 1.3, reflecting realistic low severity: AV:N (network-reachable) is offset by AC:H (high complexity due to race condition timing) and PR:L (requires an authenticated session). The only impact is VI:L - limited integrity loss confined to the vulnerable component - with no confidentiality or availability impact confirmed. The exploit maturity modifier E:P (proof-of-concept) is consistent with the publicly referenced GitHub issue, but POC availability does not equal active exploitation; this is not listed in CISA KEV and no evidence of in-the-wild use is present. No EPSS data was provided; given the low CVSS base and high attack complexity, exploitation probability is expected to be negligible. The primary real-world consequence is financial/quota fraud in deployments monetizing API access rather than a system compromise. This is a genuine low-priority finding, not a high-CVSS-but-low-risk inversion - the CVSS score accurately reflects the bounded impact.

An authenticated user with any valid account and a single legitimate redemption code opens multiple HTTP client threads and fires them simultaneously at the redemption endpoint with the same code. Because the database FOR UPDATE row lock is silently not applied due to the deprecated GORM syntax, all concurrent transactions read the code as valid before any transaction marks it consumed, allowing each concurrent request to succeed and credit the attacker's quota multiple times. A proof-of-concept demonstrating this race is publicly documented in GitHub issue #2397 (https://github.com/songquanpeng/one-api/issues/2397).