### 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](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) * **3.x**: Update to $\ge$[v4.15.2](https://github.com/zitadel/zitadel/releases/tag/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]](mailto:[email protected]) ### Credits Thanks to everyone who reported this or a part of the vulnerability: * [cwanglab](https://github.com/cwanglab) * [wooseokdotkim](https://github.com/wooseokdotkim) * [ffulbtech](https://github.com/ffulbtech) * [0xBassia](https://github.com/0xBassia) * [5ud0](https://github.com/5ud0er) from Tarmo Technologies * [alanturing881](https://github.com/alanturing881) * [dungNHVhust](https://github.com/dungNHVhust) and [sondt99](https://github.com/sondt99) * [oduoke567](https://github.com/oduoke567) * [DavidCarliez](https://github.com/DavidCarliez) * [eddieran](https://github.com/eddieran) * [tikket1](https://github.com/tikket1) * [Wernerina](https://github.com/wernerina) * [morimori-dev](https://github.com/morimori-dev) * [vamsik2k5](https://github.com/vamsik2k5)
### 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](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) * **3.x**: Update to $\ge$[v4.15.2](https://github.com/zitadel/zitadel/releases/tag/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]](mailto:[email protected]) ### Credits Thanks to everyone who reported this or a part of the vulnerability: * [cwanglab](https://github.com/cwanglab) * [wooseokdotkim](https://github.com/wooseokdotkim) * [ffulbtech](https://github.com/ffulbtech) * [0xBassia](https://github.com/0xBassia) * [5ud0](https://github.com/5ud0er) from Tarmo Technologies * [alanturing881](https://github.com/alanturing881) * [dungNHVhust](https://github.com/dungNHVhust) and [sondt99](https://github.com/sondt99) * [oduoke567](https://github.com/oduoke567) * [DavidCarliez](https://github.com/DavidCarliez) * [eddieran](https://github.com/eddieran) * [tikket1](https://github.com/tikket1) * [Wernerina](https://github.com/wernerina) * [morimori-dev](https://github.com/morimori-dev) * [vamsik2k5](https://github.com/vamsik2k5)
Update github.com/zitadel/zitadel to 1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanZITADEL: Server-Side Request Forgery (SSRF) and Denylist Bypass in Outgoing HTTP Components affects github.com/zitadel/zitadel (go). Severity is low. ### 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](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) * **3.x**: Update to $\ge$[v4.15.2](https://github.com/zitadel/zitadel/releases/tag/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]](mailto:[email protected]) ### Credits Thanks to everyone who reported this or a part of the vulnerability: * [cwanglab](https://github.com/cwanglab) * [wooseokdotkim](https://github.com/wooseokdotkim) * [ffulbtech](https://github.com/ffulbtech) * [0xBassia](https://github.com/0xBassia) * [5ud0](https://github.com/5ud0er) from Tarmo Technologies * [alanturing881](https://github.com/alanturing881) * [dungNHVhust](https://github.com/dungNHVhust) and [sondt99](https://github.com/sondt99) * [oduoke567](https://github.com/oduoke567) * [DavidCarliez](https://github.com/DavidCarliez) * [eddieran](https://github.com/eddieran) * [tikket1](https://github.com/tikket1) * [Wernerina](https://github.com/wernerina) * [morimori-dev](https://github.com/morimori-dev) * [vamsik2k5](https://github.com/vamsik2k5)
AI coding agents often install or upgrade packages automatically in go. A low 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/zitadel/zitadelgo | <1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 | 1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 |
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/zitadel/zitadel to 1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanZITADEL: Server-Side Request Forgery (SSRF) and Denylist Bypass in Outgoing HTTP Components affects github.com/zitadel/zitadel (go). Severity is low. ### 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](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) * **3.x**: Update to $\ge$[v4.15.2](https://github.com/zitadel/zitadel/releases/tag/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]](mailto:[email protected]) ### Credits Thanks to everyone who reported this or a part of the vulnerability: * [cwanglab](https://github.com/cwanglab) * [wooseokdotkim](https://github.com/wooseokdotkim) * [ffulbtech](https://github.com/ffulbtech) * [0xBassia](https://github.com/0xBassia) * [5ud0](https://github.com/5ud0er) from Tarmo Technologies * [alanturing881](https://github.com/alanturing881) * [dungNHVhust](https://github.com/dungNHVhust) and [sondt99](https://github.com/sondt99) * [oduoke567](https://github.com/oduoke567) * [DavidCarliez](https://github.com/DavidCarliez) * [eddieran](https://github.com/eddieran) * [tikket1](https://github.com/tikket1) * [Wernerina](https://github.com/wernerina) * [morimori-dev](https://github.com/morimori-dev) * [vamsik2k5](https://github.com/vamsik2k5)
AI coding agents often install or upgrade packages automatically in go. A low 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/zitadel/zitadelgo | <1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 | 1.80.0-v2.20.0.20260615133614-8e82ec1cb9a2 |
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