### Summary A Server-Side Request Forgery (SSRF) vulnerability was discovered in Zitadel affecting: - **Organization Domain HTTP Verification:** Verifies organization domain ownership by fetching a challenge token from an organization-controlled domain over HTTPS. Organization domain HTTP verification was not routed through the protected HTTP client introduced in [GHSA-29jh-8cfq-rr8x](https://github.com/zitadel/zitadel/security/advisories/GHSA-29jh-8cfq-rr8x). Instead, the challenge fetch used Go's default `http.Get`, bypassing the internal denylist and related hardening (DNS rebinding protection before dial, redirect denylist checks, HTTPS-to-HTTP downgrade prevention, redirect limits, timeout, and max response body size). Because an attacker can supply an organization-controlled domain—including one that redirects to 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 HTTP redirects, an attacker could access restricted internal endpoints even when the initial challenge URL appears to target a public domain. 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 a specific challenge token in the response (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.16.1` (including RC versions) - **3.x**: `3.0.0` through `3.4.13` (including RC versions) ### Patches The vulnerability has been addressed in the latest releases. The patch resolves the issue by routing organization domain HTTP verification through the configured protected HTTP client and securely validating target URLs against the 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 the affected component was 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.16.2](https://github.com/zitadel/zitadel/releases/tag/v4.16.2) - **3.x**: Update to $\ge$ [v4.16.2](https://github.com/zitadel/zitadel/releases/tag/v4.16.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 [Ibrahim Hashimov — AuditCode Research](https://github.com/IbrahimMrpl) and Bertie and [kanywst](https://github.com/kanywst) for reporting this vulnerability.