GHSA-26v7-h57m-gh9m
MEDIUMNew API is vulnerable to CSRF through user email binding
Blast Radius
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
The email and WeChat account binding endpoints used GET requests for state-changing account operations. In deployments where session cookies could be sent on cross-site navigations, an attacker could trigger a logged-in user's browser to bind an attacker-controlled email address or OAuth identity.
Affected endpoints included:
GET /api/oauth/email/bindGET /api/oauth/wechat/bind
Impact
A successful attack could change account binding state. For email binding, the attacker could bind an email address they control and then attempt follow-on account recovery flows. The default session cookie configuration uses SameSite=Strict, which mitigates common cross-site navigation attacks in modern browsers, so the issue is rated Medium.
Affected versions
Versions before v0.12.0-alpha.1 are affected.
Patches
This issue is fixed in v0.12.0-alpha.1. The fix changes email and WeChat binding routes from GET to POST and reads parameters from a JSON request body instead of query parameters. The same change set also normalizes password reset responses to avoid disclosing whether an email is registered.
Workarounds
If upgrading immediately is not possible, ensure session cookies are configured with strict SameSite behavior and block GET requests to /api/oauth/email/bind and /api/oauth/wechat/bind at the reverse proxy.
Resources
- Fixed by commit
e099117c61391abdf888fb75e382a582e550bd0e. - Relevant code paths:
router/api-router.goandcontroller/user.go.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/QuantumNous/new-api | all versions | 0.12.0-alpha.1 |
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 0.12.0-alpha.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-26v7-h57m-gh9m 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-26v7-h57m-gh9m 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-26v7-h57m-gh9m. 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-26v7-h57m-gh9m in your dependencies?
O3 detects GHSA-26v7-h57m-gh9m across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.