CVE-2026-71479: New API Integer Overflow Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-8r8v-xf7q-rcpr",
  "modified" : "2026-08-17T16:36:13Z",
  "published" : "2026-08-17T16:36:13Z",
  "aliases" : [ "CVE-2026-71479" ],
  "summary" : "New API: Integer overflow in quota billing yields negative charges (self-crediting)",
  "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's balance — turning a small positive balance into an enormous one.\n\n## Timeline（UTC+8）\n\nThis vulnerability was confirmed **exploited in the wild**. Response timeline (UTC+8):\n\n- **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.\n- **2026-07-07 01:17** — 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)** — 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** — [`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 `> 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.\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 — 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's 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 `>= 0` check is insufficient — 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/QuantumNous/new-api"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.0.0-rc.18"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.0.0-rc.17"
    }
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-190", "CWE-682" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-17T16:36:13Z",
    "nvd_published_at" : null
  }
}