New API CVE-2026-71479

Requires an authenticated New API account that is low-privileged but must hold a positive balance or an active subscription - that funded/active state is the explicit prerequisite named in the advisory, because settlement paths only trigger for accounts eligible to be charged. The attacker must then supply an out-of-range value in a user-controlled billing multiplier - image n, video seconds/duration, max_tokens, max_completion_tokens, maxOutputTokens, audio duration, or a billing-expression quantity - large enough to overflow the int32-width quota conversion in common/quota_math.go. Limiting factors: exploitation is confined to accounts that can register and fund a balance, affects only deployments prior to 1.0.0-rc.18, and depends on reaching a relay/settlement path that lacks the new saturation/bounds. Note the CVSS vector's PR:N contradicts this authenticated, funded-account requirement.

This is a genuine, high-priority integrity/financial-abuse issue rather than a theoretical high-CVSS artifact, but the input signals conflict on one key point. The provided CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H (9.1), asserting no privileges required, yet the description explicitly states exploitation requires 'a low-privileged account with positive balance or an active subscription' - i.e. an authenticated, funded tenant. Per the available data these disagree: the CVSS vector says unauthenticated (PR:N) while the description implies authentication plus a funded balance is a prerequisite - verify with vendor; I assess PR:L as more accurate. Confidentiality impact is correctly N (no data disclosure); the real damage is to integrity of billing records and availability of upstream funds/credit, which is why I/A are High. No EPSS score or CISA KEV status was provided, and no weaponized exploit is referenced - only fix commits and a GHSA advisory - so treat exploitation likelihood as driven by disclosure of the patched code paths rather than confirmed in-the-wild use. For any operator running a paid/multi-tenant New API instance this warrants prompt patching because abuse directly converts to monetary loss and requires only ordinary account access.

A tenant registers or funds a low-privileged account, then submits an API request (e.g. image generation, video/audio, or a chat completion) with a crafted oversized quantity such as an enormous max_tokens or duration value engineered so the quota product overflows the 32-bit charge. The recorded settlement wraps negative, crediting the attacker's balance instead of debiting it, and repeated calls inflate credit while consuming the operator's upstream provider funds. No public exploit is identified at time of analysis, though the patched code paths are disclosed in the fix commits.