How severe is GHSA-j6gc-4893-qwmp?

No CVSS score has been assigned to GHSA-j6gc-4893-qwmp yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-j6gc-4893-qwmp?

GHSA-j6gc-4893-qwmp affects the following packages: github.com/QuantumNous/new-api (Go). Ecosystems affected: Go.

How do I fix GHSA-j6gc-4893-qwmp?

Update github.com/QuantumNous/new-api to 1.0.0-rc.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j6gc-4893-qwmp is resolved across your whole dependency graph.

How do I detect GHSA-j6gc-4893-qwmp in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/QuantumNous/new-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-j6gc-4893-qwmp if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is GHSA-j6gc-4893-qwmp actively exploited in the wild?

No public exploit code has been indexed for GHSA-j6gc-4893-qwmp yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-j6gc-4893-qwmp?

GHSA-j6gc-4893-qwmp has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 20th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-j6gc-4893-qwmp?

GHSA-j6gc-4893-qwmp is classified as CWE-362 (CWE-362). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-j6gc-4893-qwmp published, and has it been updated?

GHSA-j6gc-4893-qwmp was published on August 17, 2026 and was last updated on August 18, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

GHSA-j6gc-4893-qwmp — new-api

Fix: QuantumNous/new-api@dfc0d63

GHSA-j6gc-4893-qwmp is a CWE-362 vulnerability in github.com/QuantumNous/new-api. A fix is available for github.com/QuantumNous/new-api — see the affected versions and patch details below.

New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass

Also known asCVE-2026-64865GO-2026-6243

Published

Aug 17, 2026

Updated

Aug 18, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 3, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-j6gc-4893-qwmp.

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs20th percentile — riskier than 20% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐹github.com/QuantumNous/new-api

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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:<id>.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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/QuantumNous/new-api`	all versions	1.0.0-rc.16`go get github.com/QuantumNous/new-api@v1.0.0-rc.16`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/QuantumNous/new-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/QuantumNous/new-api to 1.0.0-rc.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j6gc-4893-qwmp is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### 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 cach

O3 Security · Impact-Aware SCA

Is GHSA-j6gc-4893-qwmp in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works