CVE-2026-64865 in New API
Summary
by MITRE • 08/17/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in New API versions prior to 1.0.0-rc.16 represents a critical race condition within the application's authentication and billing subsystems, specifically affecting authenticated users managing their profile settings. As an LLM gateway and AI asset management system, New API relies heavily on accurate quota tracking to manage resource consumption for language model inference requests. The flaw resides in the controller logic located at user.go, where the handling of PUT /api/user/self endpoints creates a window for concurrent modification attacks. When an authenticated user sends repeated requests to update non-critical profile attributes such as their preferred language or sidebar module configurations, the backend triggers a sequence that updates the primary database record via User.Update and simultaneously refreshes the cached session data in Redis through updateUserCache.
The core technical flaw is rooted in the atomicity of these operations within the caching layer. The updateUserCache function performs a full write operation using RedisHSetObj to update the user's quota field, effectively overwriting the entire object associated with that user key rather than performing an incremental adjustment. Concurrently, the system processes API usage by deducting from the user's quota via HINCRBY commands in Redis. Because the full overwrite of the cached quota occurs without proper synchronization or locking mechanisms relative to the increment operations, a race condition emerges. If an attacker sends rapid PUT requests for profile updates while simultaneously generating high volumes of AI inference traffic that trigger quota deductions, the timing can align such that the updateUserCache operation overwrites the Redis hash with stale data from the database before the HINCRBY deduction is fully committed or reflected in the cache read path.
This race condition allows an authenticated user to artificially inflate their cached quota balance. By carefully orchestrating these concurrent requests, a malicious actor can cause the system to retain a higher remaining credit amount than they have actually purchased or earned. This bypasses the intended billing logic, leading to unauthorized access to premium AI services without corresponding financial cost. The impact extends beyond simple service abuse; it undermines the integrity of the platform's revenue model and resource allocation policies. In enterprise environments relying on New API for centralized LLM management, this could lead to significant financial loss and potential denial of service for other users if quota limits are bypassed excessively, causing backend resources to be exhausted by unpaid usage.
From a classification perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the failure lies in the lack of proper locking when multiple threads or processes access and modify shared state concurrently. It also relates to CWE-840: Incorrect Assignment of Critical Privileges, although here it manifests as incorrect assignment of resource limits rather than direct privilege escalation. In terms of offensive security frameworks, this technique is consistent with ATT&CK T1539: Steal Web Session Cookie or similar session manipulation tactics where the attacker manipulates state to gain unauthorized benefits, though specifically targeting quota integrity rather than authentication tokens directly.
Mitigation strategies for this vulnerability involve ensuring atomicity in cache updates and database writes. The most effective fix is to implement distributed locking mechanisms around the user update process to prevent concurrent modifications during critical sections of code execution. Alternatively, the system should utilize Redis transactions or Lua scripts to ensure that reading the current quota, calculating deductions, and updating the profile information occur as a single atomic operation without interleaving from other requests. Upgrading to version 1.0.0-rc.16 resolves this issue by addressing these synchronization gaps in the user controller logic. Until an upgrade is performed, administrators should monitor for anomalous patterns of rapid profile updates coupled with high inference volume and consider rate-limiting PUT /api/user/self endpoints to reduce the window of opportunity for such race conditions.