Zitadel EUVD-2026-92107

Requires an authenticated principal with privileges to create/manage an organization and register a custom domain in Zitadel, then initiate the HTTP-based domain verification flow (PR:L). The specific flaw is that the challenge-fetch code path uses Go's default http.Get instead of Zitadel's SSRF-protected HTTP client, so no egress filtering blocks loopback, RFC1918/internal, or link-local cloud metadata (169.254.169.254) targets. The attacker must control DNS/HTTP for a registered domain so verification redirects to the internal target (reflected by AT:P). Limiting factors: exploitation is gated by valid authenticated access and domain-management permissions, impact is confined to server-side reconnaissance (port scanning, network mapping) rather than data modification, and real confidentiality impact depends on whether sensitive internal/metadata services are actually reachable from the Zitadel instance.

This is a genuinely low-priority issue, and the signals are internally consistent rather than conflicting. The CVSS 4.0 base score of 2.3 (Low) matches the description: although the attack vector is network (AV:N) with low complexity (AC:L), exploitation carries an attack requirement (AT:P) and requires authenticated access (PR:L), and the impact is limited to low confidentiality and low integrity (VC:L/VI:L) with no availability or subsequent-system impact (VA:N/SC:N/SI:N/SA:N). The real-world value to an attacker is reconnaissance - port scanning and internal network mapping via the authentication server - not direct compromise, data theft, or RCE. There is no CISA KEV listing and no public exploit code identified at time of analysis, and no EPSS value was provided in the input, so there is no signal of active or probable widespread exploitation. The one caveat worth verifying: cloud metadata endpoints (e.g., 169.254.169.254) can expose credentials, so the practical confidentiality impact could exceed VC:L if the affected instance runs in a cloud environment with an unprotected metadata service - this should be assessed per deployment rather than assumed from the base score alone. Overall: patch in normal cadence; this is not an emergency.

An authenticated user with permission to manage an organization registers a domain and configures it so the HTTP verification challenge resolves or redirects to an internal address such as a loopback service, a private RDS/Redis host, or a cloud metadata endpoint. Because the challenge fetch uses Go's default http.Get rather than the SSRF-protected client, the Zitadel server issues the request on the attacker's behalf, letting them infer open ports and map reachable internal hosts from server-side timing and responses. No public proof-of-concept was identified at time of analysis.