Summary
New API: Integer overflow in quota billing yields negative charges (self-crediting)
Multiple billing paths multiplied user-controlled quantity parameters into the quota calculation without an upper bound or overflow-safe integer conversion. A crafted extreme value (e.g. image n = 18446744073686646784, a wrapped-negative accepted by a *uint field) makes conversions like int(float64(quota) * n) wrap past the int64/int32 range into a large negative quota. The negative quota takes effect at settlement (not at pre-consume), where it is equivalent to crediting the user's balance, turning a small positive balance into an enormous one.
Timeline（UTC+8）
This vulnerability was confirmed exploited in the wild. Response timeline (UTC+8):
- 2026-07-06 23:00, Community user @lihui12388 reported that their deployment had been exploited via this vulnerability (large negative consumption entries in logs and abnormally inflated balances). We confirmed in-the-wild exploitation and started an emergency response immediately.
- 2026-07-07 01:17, Emergency fix released as
v1.0.0-rc.18, roughly 2 hours after the report. - 2026-07-07 (next day), Given the confirmed active exploitation, we publicly disclosed the vulnerability and the fixed version to the community the following day so that all operators could upgrade and audit promptly.
- 2026-07-07 13:19,
v1.0.0-rc.19released with additional observability (quota-saturation warning logs) to help operators audit and monitor abuse.
Preconditions
This is not a zero-balance freebie. The attacker must hold an account whose wallet balance is > 0 and at least covers the request's normal (un-inflated) pre-consume amount, the pre-consume gate rejects userQuota <= 0 and insufficient balance with HTTP 403. Quantity multipliers (n, duration, ...) are not applied at pre-consume; the overflow only manifests at settlement, flipping the charge negative and crediting the balance.
Severity escalates when the deployment enables any feature that grants free starting balance, because the required positive balance is then obtained at zero cost and at scale: check-in rewards (CheckinSetting.Enabled), invite rebates (QuotaForInviter / QuotaForInvitee), or new-user quota gifts (QuotaForNewUser). With self-registration on by default and any of these enabled, an attacker can register (or mass-register) to obtain seed balance for free, then inflate it via a single crafted request, effectively unauthenticated exploitation.
Root cause
Single root cause: user-controlled multipliers lacked upper-bound validation before entering quota math, and the float/decimal-to-int conversions lacked saturation. Because *uint accepts huge positive values (a wrapped negative), a >= 0 check is insufficient, an explicit upper bound is required.
Impact
A low-privilege user with a positive balance can massively inflate their own balance with a single crafted request (negative settlement = credit), violating billing integrity. Sustained abuse can drain the operator's prepaid upstream funds and render billing/service unavailable. Exploitation in the wild has been confirmed (see Timeline above).
An arithmetic operation produces a value that exceeds the integer type's maximum, causing it to wrap to an unexpected small value. Typical impact: incorrect size calculations leading to heap overflows or logic errors.
CVE-2026-71479 has a CVSS score of 9.1 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.0.0-rc.18); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed via defense-in-depth: (1) upper-bound validation at request ingress (400 on violation), (2) local clamping of the same quantities on validation-bypass paths (passthrough/metadata/multipart), and (3) centralized saturating conversions in common/quota_math.go that clamp to int32 and never wrap. Saturation events are additionally audited on the related consume/task log under admin_info.quota_saturation (admin-only) and via request-correlated backend warnings.
Frequently Asked Questions
- What is CVE-2026-71479? CVE-2026-71479 is a critical-severity integer overflow or wraparound vulnerability in github.com/QuantumNous/new-api (go), affecting versions <= 1.0.0-rc.17. It is fixed in 1.0.0-rc.18. An arithmetic operation produces a value that exceeds the integer type's maximum, causing it to wrap to an unexpected small value.
- How severe is CVE-2026-71479? CVE-2026-71479 has a CVSS score of 9.1 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/QuantumNous/new-api are affected by CVE-2026-71479? github.com/QuantumNous/new-api (go) versions <= 1.0.0-rc.17 is affected.
- Is there a fix for CVE-2026-71479? Yes. CVE-2026-71479 is fixed in 1.0.0-rc.18. Upgrade to this version or later.
- Is CVE-2026-71479 exploitable, and should I be worried? Whether CVE-2026-71479 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-71479 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-71479? Upgrade
github.com/QuantumNous/new-apito 1.0.0-rc.18 or later.