GHSA-J6GC-4893-QWMP

Vulnerability from github – Published: 2026-08-17 16:36 – Updated: 2026-08-17 16:36
VLAI
Summary
New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass
Details

Summary

Authenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota.

Impact

A low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing.

Affected Components

  • controller/user.go: UpdateSelf language/sidebar_modules branches
  • model/user.go: User.Update / UpdateWithTx full snapshot update
  • model/user_cache.go: updateUserCache RedisHSetObj full hash write
  • model/user.go: GetUserQuota reads Redis cache first

Root Cause

Normal billing uses Redis HINCRBY on user:.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field.

Patches

This issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths.

Workarounds

If upgrading immediately is not possible, operators should temporarily restrict or rate-limit PUT /api/user/self and avoid allowing frequent user setting updates while Redis-backed quota cache is enabled. This is only a mitigation; upgrading is recommended.

Remediation

Upgrade to v1.0.0-rc.16 or later. Deployments with Redis enabled should restart application instances after upgrading so stale in-process code paths are removed.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-rc.15"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/QuantumNous/new-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-rc.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-64865"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T16:36:19Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nAuthenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota.\n\n### Impact\nA low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing.\n\n### Affected Components\n- controller/user.go: UpdateSelf language/sidebar_modules branches\n- model/user.go: User.Update / UpdateWithTx full snapshot update\n- model/user_cache.go: updateUserCache RedisHSetObj full hash write\n- model/user.go: GetUserQuota reads Redis cache first\n\n### Root Cause\nNormal billing uses Redis HINCRBY on user:\u003cid\u003e.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field.\n\n### Patches\nThis issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths.\n\n### Workarounds\nIf upgrading immediately is not possible, operators should temporarily restrict or rate-limit PUT /api/user/self and avoid allowing frequent user setting updates while Redis-backed quota cache is enabled. This is only a mitigation; upgrading is recommended.\n\n### Remediation\nUpgrade to v1.0.0-rc.16 or later. Deployments with Redis enabled should restart application instances after upgrading so stale in-process code paths are removed.",
  "id": "GHSA-j6gc-4893-qwmp",
  "modified": "2026-08-17T16:36:19Z",
  "published": "2026-08-17T16:36:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-j6gc-4893-qwmp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/commit/dfc0d6324b40c1d6c2972e524409f933541bfb0f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/QuantumNous/new-api"
    },
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/releases/tag/v1.0.0-rc.16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…