ZITADEL CVE-2025-67494

Exploitation requires the ZITADEL instance to be running the Login UI (V2) on an affected version (v4.0.0-rc.1 through 4.7.0) and to be reachable by the attacker; the server must accept and trust the x-zitadel-forward-host header, which per the advisory is the default behavior for all deployments including self-hosted single-instance setups. No authentication (PR:N), user interaction (UI:N), or special configuration is needed on the target. The primary limiting factor is a fronting reverse proxy that strips or overwrites x-zitadel-forward-host (and related forwarded headers) before passing requests to ZITADEL - the vendor's documented workaround - which neutralizes the attack; deployments not exposing the V2 Login UI are likewise not affected.

This is a genuine high-priority issue rather than a CVSS-inflated one, though not an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, 8.6) is internally consistent with the description: an unauthenticated (PR:N), network-reachable (AV:N), low-complexity (AC:L) full-read SSRF whose scope changes (S:C) because the vulnerable ZITADEL server is coerced into reaching other systems, with high confidentiality impact (C:H) and no integrity or availability impact. The signals are not fully aligned, however: EPSS is only 0.44% (37th percentile), there is NO CISA KEV listing, and no public exploit was identified in the provided data - so despite the high base score, there is no evidence of active or imminent widespread exploitation yet. The counterweight is that this is a CWE-918 full-read SSRF in an identity/authentication product, where successful exploitation can reach internal services, cloud metadata endpoints, and segmented networks, which is high-value and typically draws attacker attention once a PoC appears. Net: treat as a prompt-patch item (identity infrastructure, unauthenticated, trivial to trigger) but the current real-world exploitation probability is low and the fix is a straightforward patch upgrade.

An unauthenticated attacker sends an HTTP request to an internet-exposed ZITADEL Login UI (V2) with a crafted x-zitadel-forward-host header pointing at an internal address (for example a cloud metadata endpoint or an internal admin service). The server trusts the header as its service-URL fallback, issues the outbound request, and returns the upstream response to the attacker, allowing data exfiltration from internal services and bypass of network-segmentation controls. No public exploit was identified in the provided data, but the GitHub advisory describes the exact header and trigger, so weaponization effort would be minimal.