EUVD-2026-42978
GHSA-29jh-8cfq-rr8x
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
URL configuration requires low-privilege authenticated access; scope changes because SSRF reaches systems outside Zitadel's security boundary, with high confidentiality impact from potential cloud metadata access.
Primary rating from Vendor (https://github.com/zitadel/zitadel).
CVSS VectorVendor: https://github.com/zitadel/zitadel
Lifecycle Timeline
3DescriptionCVE.org
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.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. 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.
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 [security@zitadel.com](mailto:security@zitadel.com)
Credits
Thanks to everyone who reported this or a part of the vulnerability:
AnalysisAI
Server-Side Request Forgery in Zitadel's outgoing HTTP subsystems - HTTP Notification Channel webhooks, OIDC BackChannel Logout endpoints, and SAML Metadata URL fetches - enables authenticated users with application configuration privileges to force the Zitadel server to issue HTTP requests to internal network addresses, loopback interfaces, and cloud metadata endpoints such as the link-local IMDSv1 address 169.254.169.254. The pre-existing denylist for the Actions subsystem was additionally bypassable via DNS rebinding (TOCTOU), HTTP redirect following, and HTTPS-to-HTTP protocol downgrade, and all three newly affected components lacked denylist coverage entirely. No public exploit code has been identified at time of analysis; however, the vulnerability was independently reported by 13+ researchers, and a vendor patch is available in v4.15.2 with no backport for the v3.x branch.
Technical ContextAI
Zitadel is an open-source identity and access management (IAM) platform written in Go (pkg:go/github.com/zitadel/zitadel). The root cause class is CWE-918 (Server-Side Request Forgery), manifesting across three distinct outgoing HTTP subsystems: HTTP Notification Channels (user-defined webhook URLs accepting HTTP POST payloads as an alternative to SMTP or Twilio), OIDC BackChannel Logout (server-initiated session termination requests sent to application-registered endpoints), and SAML Metadata URL fetches (retrieval of IdP metadata from administrator-supplied URLs). These components did not apply the denylist that had previously been introduced for the Actions subsystem. The Actions denylist itself had three bypass vectors: DNS rebinding - where a domain initially resolves to an allowed external IP at check time but switches to an internal IP before the TCP connection is made, creating a TOCTOU gap; HTTP redirect following - where the server obediently follows a redirect chain leading to an internal address; and HTTPS-to-HTTP downgrade - where a redirect from a trusted HTTPS endpoint to an internal HTTP endpoint was honored. The patch (commit 8e82ec1cb9a2b154ff48d3a0fa96b43d1428061f) introduces a unified HTTPClient configuration block with a comprehensive DenyList enforced at the network dialer level, covering all RFC1918 ranges, loopback, carrier-grade NAT, link-local (169.254.0.0/16), IPv6 equivalents, and IPv4-mapped IPv6 addresses, with CIDR-level checks at connection time to prevent DNS rebinding bypasses.
RemediationAI
The primary fix is to upgrade Zitadel to v4.15.2 or later (https://github.com/zitadel/zitadel/releases/tag/v4.15.2), which introduces a unified HTTPClient.DenyList enforced at the network dialer layer, blocking all RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local including cloud metadata endpoints (169.254.0.0/16), carrier-grade NAT (100.64.0.0/10), and full IPv6 equivalents. The patch also disables HTTPS-to-HTTP downgrade redirects by default (AllowHTTPSDowngrade: false) and caps redirects at 5. Note that no v3.x backport has been released - the vendor cites extensive code refactoring requirements; v3.x users must upgrade to v4.15.2 or apply infrastructure-level controls. For organizations that cannot immediately upgrade, the vendor recommends implementing strict egress firewall rules or reverse proxy policies at the infrastructure layer to prevent Zitadel from initiating outbound connections to RFC1918 addresses, loopback (127.0.0.0/8), and cloud metadata endpoints (169.254.169.254). Trade-off: network-level egress controls must be maintained separately from Zitadel configuration and may require adjustment as internal topology changes. These controls do not protect against DNS rebinding unless the firewall also enforces destination IP restrictions post-resolution.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today