## 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/bind` - `GET /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.go` and `controller/user.go`.
## 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/bind` - `GET /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.go` and `controller/user.go`.
Update github.com/QuantumNous/new-api to 0.12.0-alpha.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNew API is vulnerable to CSRF through user email binding affects github.com/QuantumNous/new-api (go). Severity is medium. ## 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/bind` - `GET /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.go` and `controller/user.go`.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/QuantumNous/new-apigo | <0.12.0-alpha.1 | 0.12.0-alpha.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/QuantumNous/new-api to 0.12.0-alpha.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNew API is vulnerable to CSRF through user email binding affects github.com/QuantumNous/new-api (go). Severity is medium. ## 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/bind` - `GET /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.go` and `controller/user.go`.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/QuantumNous/new-apigo | <0.12.0-alpha.1 | 0.12.0-alpha.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard