GHSA-j6gc-4893-qwmp
Fix: QuantumNous/new-api@dfc0d63GHSA-j6gc-4893-qwmp is a CWE-362 vulnerability in github.com/QuantumNous/new-api. O3 Security confirms whether GHSA-j6gc-4893-qwmp is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass
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.
Real-World Exposure
github.com/QuantumNous/new-apiReal-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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/QuantumNous/new-api | all versions | 1.0.0-rc.16 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/QuantumNous/new-api. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
How O3 protects you
O3 pinpoints whether GHSA-j6gc-4893-qwmp is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j6gc-4893-qwmp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j6gc-4893-qwmp in your dependencies?
O3 detects GHSA-j6gc-4893-qwmp across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.