CVE-2026-64865

New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass

CVSS 4.0 6.0 MEDIUMEUVD CVSS 4.0 6.0 CVSS 4.0 · [email protected] · Secondary 6.0 MEDIUMCVSS_V4 Publisher rating MODERATEFixed by github.com/QuantumNous/new-api 1.0.0-rc.16osv · severity unknownFixed by github.com/QuantumNous/new-api 1.0.0-rc.16KEV status unknown

Original advisory

cve-program · CVE-2026-64865

Published

New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.16, repeated PUT /api/user/self requests that update language or sidebar_modules can race relay billing because controller/user.go calls User.Update and updateUserCache performs a full RedisHSetObj write to user:.Quota, overwriting concurrent HINCRBY deductions and allowing an authenticated user to keep cached quota artificially high. This issue is fixed in version 1.0.0-rc.16.

Read the publisher's advisory

euvd · EUVD-2026-60263

Published

Read the publisher's advisory

nvd · CVE-2026-64865

Published

Read the publisher's advisory

osv · GHSA-j6gc-4893-qwmp

Published

### Summary Authenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota. ### Impact A low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing. ### Affected Components - controller/user.go: UpdateSelf language/sidebar_modules branches - model/user.go: User.Update / UpdateWithTx full snapshot update - model/user_cache.go: updateUserCache RedisHSetObj full hash write - model/user.go: GetUserQuota reads Redis cache first ### Root Cause Normal billing uses Redis HINCRBY on user:<id>.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field. ### Patches This issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths. ### Workarounds If upgrading immediately is not possible, operators should temporarily restrict or rate-limit PUT /api/user/self and avoid allowing frequent user setting updates while Redis-backed quota cache is enabled. This is only a mitigation; upgrading is recommended. ### Remediation Upgrade to v1.0.0-rc.16 or later. Deployments with Redis enabled should restart application instances after upgrading so stale in-process code paths are removed.

Read the publisher's advisory

osv · GO-2026-6243

Published

New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass in github.com/QuantumNous/new-api

Read the publisher's advisory

Affected versions, risk and source history

Exploitation and risk

Source status

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

Which CVEs have scores here?

This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

Risk history

Compare earlier KEV listings and daily EPSS scores. Advisory wording and affected versions have a separate history.

When does an EPSS score appear as a change?

A prediction change is reported when EPSS rises from below 10% to 10% or higher. Other daily score changes remain in this history.

Advisory history

12 saved versions

See how the publisher's advisory changed over time. Each link opens the version saved at that time. The publisher's update date can differ from the date shown here.

How advisory history works

Each link identifies one complete publisher record. History can include advisories that previously shared an identifier; an identifier removed by a publisher no longer establishes a current relationship. A historical link shows only that record and earlier saved versions. Failed checks and unchanged reads do not create new versions.

11 Nov 2026 15:07:45 UTC