GHSA-8R8V-XF7Q-RCPR
Vulnerability from github – Published: 2026-08-17 16:36 – Updated: 2026-08-17 16:36Summary
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.
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).
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.
Fix
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-rc.17"
},
"package": {
"ecosystem": "Go",
"name": "github.com/QuantumNous/new-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0-rc.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71479"
],
"database_specific": {
"cwe_ids": [
"CWE-190",
"CWE-682"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-17T16:36:13Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nMultiple 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\u0027s balance \u2014 turning a small positive balance into an enormous one.\n\n## Timeline\uff08UTC+8\uff09\n\nThis vulnerability was confirmed **exploited in the wild**. Response timeline (UTC+8):\n\n- **2026-07-06 23:00** \u2014 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.\n- **2026-07-07 01:17** \u2014 Emergency fix released as [`v1.0.0-rc.18`](https://github.com/QuantumNous/new-api/releases/tag/v1.0.0-rc.18), roughly 2 hours after the report.\n- **2026-07-07 (next day)** \u2014 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.\n- **2026-07-07 13:19** \u2014 [`v1.0.0-rc.19`](https://github.com/QuantumNous/new-api/releases/tag/v1.0.0-rc.19) released with additional observability (quota-saturation warning logs) to help operators audit and monitor abuse.\n\n## Preconditions\n\nThis is **not** a zero-balance freebie. The attacker must hold an account whose wallet balance is `\u003e 0` and at least covers the request\u0027s normal (un-inflated) pre-consume amount \u2014 the pre-consume gate rejects `userQuota \u003c= 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.\n\n**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 \u2014 effectively unauthenticated exploitation.\n\n## Impact\n\nA 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\u0027s prepaid upstream funds and render billing/service unavailable. **Exploitation in the wild has been confirmed** (see Timeline above).\n\n## Root cause\n\nSingle 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 `\u003e= 0` check is insufficient \u2014 an explicit upper bound is required.\n\n## Fix\n\nFixed 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.",
"id": "GHSA-8r8v-xf7q-rcpr",
"modified": "2026-08-17T16:36:13Z",
"published": "2026-08-17T16:36:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-8r8v-xf7q-rcpr"
},
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/commit/c9943d37ad93477dd937fc4901cc3c4e0fd8aaab"
},
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/commit/d0bd8aac742d1e160a5ca61743fe35f4fff880e8"
},
{
"type": "PACKAGE",
"url": "https://github.com/QuantumNous/new-api"
},
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/releases/tag/v1.0.0-rc.18"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "New API: Integer overflow in quota billing yields negative charges (self-crediting)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.