CVE-2026-105214 in Zitadel
Summary
by MITRE • 10/04/2026
Zitadel before 4.16.2 contains a server-side request forgery vulnerability that allows attackers to make the server request internal resources through organization domain HTTP verification. The challenge fetch uses Go's default http.Get instead of the protected client, so attackers can register domains that redirect to loopback, internal, or cloud metadata addresses to scan ports and map internal networks.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in Zitadel versions prior to 4.16.2 represents a critical server-side request forgery flaw rooted in the improper validation of user-supplied input during domain verification processes. Specifically, when an organization attempts to verify ownership or control over a custom domain within the platform, the system initiates an HTTP GET request to validate the domain's accessibility and configuration. This operational step is essential for ensuring that only legitimate administrators can associate their domains with specific organizational entities, thereby maintaining the integrity of identity management workflows. However, the implementation fails to enforce strict restrictions on the destination addresses targeted by these verification requests, creating a significant attack vector for malicious actors seeking to probe internal network infrastructure.
At the technical core of this vulnerability is the use of Go's default http.Get function rather than a hardened HTTP client with built-in protections against SSRF attacks. In secure implementations, such clients typically include safeguards like URL scheme validation, IP address blacklisting or whitelisting, and redirection following restrictions to prevent requests from reaching internal services, loopback interfaces, or cloud metadata endpoints. By relying on the standard library's default behavior without additional sanitization layers, Zitadel inadvertently allows attackers to craft malicious domain names that resolve to or redirect toward sensitive internal resources. This design oversight effectively turns a routine administrative function into a powerful tool for network reconnaissance and unauthorized access attempts against backend systems that are not directly exposed to the public internet.
The operational impact of this flaw extends beyond simple data exfiltration, as it enables attackers to perform port scanning and internal network mapping from within the trusted environment where Zitadel operates. By registering domains configured with DNS records or HTTP redirects pointing to loopback addresses such as 127.0.0.1, private IP ranges like 192.168.x.x, or cloud metadata endpoints commonly found at addresses like 169.254.169.254 for AWS EC2 instances, adversaries can leverage the server's outbound connections to probe internal services. This capability allows attackers to identify open ports, determine running service versions, and potentially discover misconfigured internal APIs or databases that rely on network-level security controls rather than authentication mechanisms. Such reconnaissance activities significantly lower the barrier for subsequent exploitation attempts against other components within the infrastructure.
This vulnerability aligns with Common Weakness Enumeration category CWE-918, which addresses Server-Side Request Forgery (SSRF), specifically highlighting flaws in server-side input validation that allow attackers to manipulate URL parameters or domain names to target internal resources. Furthermore, from a tactical perspective, this behavior corresponds to the MITRE ATT&CK technique T1560.002, known as Archive via Cloud Infrastructure, and more broadly to reconnaissance activities under T1046 Network Service Discovery. The ability to scan ports and map networks using SSRF is particularly dangerous in cloud-native environments where internal services often communicate over unencrypted channels or trust local network boundaries implicitly. Attackers can use this information to pivot further into the network, potentially leading to credential theft via metadata service exploitation or unauthorized access to sensitive microservices that should remain isolated from external-facing applications.
Mitigation strategies must focus on implementing robust input validation and restricting outbound request capabilities at both the application and infrastructure levels. For organizations running affected versions of Zitadel, upgrading to version 4.16.2 or later is the primary remediation step, as this release addresses the underlying implementation flaw by replacing the default HTTP client with a protected variant that enforces strict URL validation rules. These protections typically include blocking requests to private IP ranges, loopback interfaces, and cloud metadata endpoints while also disabling automatic redirections unless explicitly allowed for trusted domains. Additionally, network-level controls such as egress filtering can provide defense-in-depth by preventing the application server from initiating connections to internal subnets or sensitive external services that do not require internet access. Security teams should also audit existing configurations to ensure no other components rely on similar unvalidated HTTP client patterns and consider implementing Web Application Firewall rules capable of detecting SSRF attempts based on request headers and destination IP reputation data.