How severe is GHSA-29jh-8cfq-rr8x?

No CVSS score has been assigned to GHSA-29jh-8cfq-rr8x yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-29jh-8cfq-rr8x?

GHSA-29jh-8cfq-rr8x affects the following packages: github.com/zitadel/zitadel (Go). Ecosystems affected: Go.

How do I fix GHSA-29jh-8cfq-rr8x?

Update github.com/zitadel/zitadel to 1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-29jh-8cfq-rr8x is resolved across your whole dependency graph.

How do I detect GHSA-29jh-8cfq-rr8x in my Go dependencies?

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

How do I mitigate GHSA-29jh-8cfq-rr8x if there is no patch (or I can't update yet)?

Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Is GHSA-29jh-8cfq-rr8x actively exploited in the wild?

No public exploit code has been indexed for GHSA-29jh-8cfq-rr8x 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-29jh-8cfq-rr8x?

GHSA-29jh-8cfq-rr8x has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 36th 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-29jh-8cfq-rr8x?

GHSA-29jh-8cfq-rr8x is classified as Server-Side Request Forgery (SSRF) (CWE-918). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was GHSA-29jh-8cfq-rr8x published, and has it been updated?

GHSA-29jh-8cfq-rr8x was published on June 18, 2026 and was last updated on June 25, 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

ZITADEL: Server-Side Request Forgery (SSRF) and Denylist Bypass in Outgoing HTTP ComponentsGHSA-29jh-8cfq-rr8x

Fix: zitadel/zitadel@8e82ec1

GHSA-29jh-8cfq-rr8x is a Server-Side Request Forgery (SSRF) vulnerability in github.com/zitadel/zitadel. A fix is available for github.com/zitadel/zitadel — see the affected versions and patch details below.

Also known asCVE-2026-55671GO-2026-5059

Published

Jun 18, 2026

Updated

Jun 25, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

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

Exploitation Status

No confirmed exploitation observed yet

CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
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-29jh-8cfq-rr8x.

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs36th percentile — riskier than 36% 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/zitadel/zitadel

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

A Server-Side Request Forgery (SSRF) vulnerability was discovered in Zitadel affecting:

HTTP Notification Channels: Used as an alternative to SMTP/Twilio configurations, sending payloads to user-defined URLs via HTTP POST webhooks.
OIDC BackChannel Logout: Terminates sessions across different applications. When a session ends, the Zitadel server sends an HTTP POST request to configured endpoints.
SAML Metadata URL Fetches: Fetches SAML metadata configurations from user-provided external URLs.

User-defined URLs in these components were not properly validated against an internal denylist, allowing potentially malicious URLs to bypass restrictions. Furthermore, the existing denylist mechanism previously introduced for Actions was found to be vulnerable to DNS rebinding, HTTP redirects, and protocol downgrades (HTTPS to HTTP), and it missed several common local network default entries.

Because an attacker can supply arbitrary URLs—including loopback addresses, internal IPs, or cloud link-local addresses—they could potentially gather internal network architecture details, scan internal ports, or interact with unauthorized internal services and infrastructure.

Impact

When a user-supplied URL points to a local host or internal IP address, an adversary can perform a Server-Side Request Forgery (SSRF) attack. This allows them to map internal network structures and exploit exposed internal services.

By leveraging DNS rebinding, an attacker could also bypass standard DNS-level checks, creating Time-of-Check to Time-of-Use (TOCTOU) gaps to access restricted internal endpoints. Additionally, vulnerabilities to HTTP redirects and protocol downgrades could allow attackers to manipulate the request flow or intercept sensitive communication.

Notably, if Zitadel is deployed within cloud environments (such as AWS, GCP, or Azure) that still permit legacy IMDSv1 or unauthenticated cloud metadata endpoints (169.254.169.254), an attacker could theoretically attempt to target these metadata services.

While Zitadel expects specific schemas or response formats for these features (which inherently limits data exfiltration capabilities and reduces the severe execution of the threat vector), users are strongly advised to patch immediately.

Affected Versions

Systems running one of the following versions are affected:

4.x: 4.0.0 through 4.15.1 (including RC versions)
3.x: 3.0.0 through 3.4.11 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by securely validating target URLs against a hardened denylist. By default, localhost, loopback IPs, and standard internal network blocks are denied.

Note on Backports: This fix was only released on v4.x. While some of the affected components were generally available (GA), backporting the security fix to v3.x was not feasible due to the extensive code refactoring required to implement the unified network client securely. Please check the workarounds section if an upgrade to v4.x is not immediately possible.

4.x: Upgrade to $\ge$4.15.2
3.x: Update to $\ge$v4.15.2 or check out workarounds

Workarounds

The recommended solution is to update Zitadel to a patched version.

If an immediate upgrade is not possible, you can mitigate the risk by implementing strict network policies, egress firewalls, or reverse proxy rules within your infrastructure to block Zitadel from initiating outbound connections to your internal network, loopback interfaces, or cloud metadata endpoints. Note that managing these network controls is outside the scope of Zitadel's native configurations.

Questions

If you have any questions or comments about this advisory, please email us at [email protected]

Credits

Thanks to everyone who reported this or a part of the vulnerability:

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/zitadel/zitadel`	all versions	1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2`go get github.com/zitadel/zitadel@v1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2`

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/zitadel/zitadel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/zitadel/zitadel to 1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-29jh-8cfq-rr8x is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

### Summary A Server-Side Request Forgery (SSRF) vulnerability was discovered in Zitadel affecting: * **HTTP Notification Channels:** Used as an alternative to SMTP/Twilio configurations, sending payloads to user-defined URLs via HTTP POST webhooks. * **OIDC BackChannel Logout:** Terminates sessions across different applications. When a session ends, the Zitadel server sends an HTTP POST request to configured endpoints. * **SAML Metadata URL Fetches:** Fetches SAML metadata configurations from user-provided external URLs. User-defined URLs in these components were not properly validated aga

O3 Security · Impact-Aware SCA

Is GHSA-29jh-8cfq-rr8x in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works