CVE-2026-64865: New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass
Summary Authenticated users can repeatedly call PUT /api/user/self with language or sidebarmodules 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/sidebarmodules branches - model/user.go: User.Update / UpdateWithTx full snapshot update - model/usercache.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.
Other sources
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 sidebarmodules 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/QuantumNous/new-apito a version that resolves this vulnerability.Fixed in 1.0.0-rc.16 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.0.0-rc.16 - Compensating control
If upgrading is not possible, temporarily restrict or rate-limit PUT /api/user/self and avoid allowing frequent updates to language or sidebar_modules while Redis-backed quota cache is enabled.
- Operational
If Redis-backed quota cache is enabled, restart application instances after upgrading to remove stale in-process code paths.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-64865?
CVE-2026-64865 has a risk rating of 33.
How do I fix CVE-2026-64865?
To mitigate CVE-2026-64865, upgrade to New API version 1.0.0-rc.16 or later.
What type of vulnerability is CVE-2026-64865?
CVE-2026-64865 is classified as a race condition vulnerability.
What does CVE-2026-64865 affect?
CVE-2026-64865 affects the New API's user quota management when using the PUT /api/user/self endpoint.
Is CVE-2026-64865 exploitable remotely?
Yes, CVE-2026-64865 can be exploited remotely through the New API interface.