GHSA-xqxv-4jc2-x56x is a high-severity (CVSS 7.4) Improper Authentication vulnerability in github.com/zitadel/zitadel. O3 Security confirms whether GHSA-xqxv-4jc2-x56x is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
ZITADEL: Missing client_id binding in OIDC authorization code exchange and refresh token flows (RFC 6749 Section 4.1.3 violation)
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- 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-xqxv-4jc2-x56x.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-xqxv-4jc2-x56x plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 363,908 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/zitadel/zitadelReal-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
Zitadel's OAuth2 / OIDC CodeExchange and RefreshToken implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.
Impact
This flaw creates potential vulnerabilities in two main authentication phases, provided specific external preconditions are met:
- Authorization Code Injection: An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (
ClientB) registered on the same Zitadel instance. Zitadel will authenticateClientBand issue tokens for the victim user without verifying the client binding. - Refresh Token Cross-Use: An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token's format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.
- Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.
Scope and Mitigation Factors:
- External Preconditions: It is critical to note that exploiting either vector requires a pre-existing vulnerability or data leak within the target application environment to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.
- Multi-tenant risk: On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant's clients if they are successfully intercepted.
- PKCE protection: Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the
code_verifier. However, PKCE does not protect against refresh token cross-use.
Affected Versions
Systems running one of the following versions are affected:
- 4.x:
4.0.0through4.15.1(including RC versions) - 3.x:
3.0.0through3.4.11(including RC versions)
Patches
The vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the CodeExchange and RefreshToken grants.
Please upgrade to one of the following secure versions:
Workarounds
The recommended solution is to upgrade to a patched version.
To reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of PKCE for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.
Questions
If you have any questions or comments about this advisory, please email us at [email protected]
Credits
Thanks to kodareef5, Shubham Raj / Causal Security, and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/zitadel/zitadel | all versions | 1.80.0-v2.20.0.20260616131956-0973b074b488 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/zitadel/zitadel. 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/zitadel/zitadel to 1.80.0-v2.20.0.20260616131956-0973b074b488 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xqxv-4jc2-x56x 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-xqxv-4jc2-x56x 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-xqxv-4jc2-x56x. 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-xqxv-4jc2-x56x in your dependencies?
O3 detects GHSA-xqxv-4jc2-x56x across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.