CVE-2026-105214

Executive Summary

Zitadel before version 4.16.2 is affected by a server-side request forgery (SSRF) vulnerability in the organization domain HTTP verification flow, tracked as CVE-2026-105214. The challenge fetch mechanism relies on Go's default http.Get instead of a protected HTTP client, allowing a remote, unauthenticated attacker to register an organization domain that redirects requests toward loopback, internal RFC1918, or cloud metadata endpoints. Successful exploitation enables internal port scanning, service enumeration, and internal network mapping, potentially exposing sensitive cloud metadata such as instance credentials.

Technical Analysis

CWE-918 (Server-Side Request Forgery) arises when the server processes a user-supplied URL and fetches it without applying destination validation, allow-list enforcement, or network egress controls. Per the NVD description, the vulnerability is located within Zitadel's organization domain HTTP verification function. When an administrator adds a domain to an organization, Zitadel performs HTTP verification by fetching a challenge from a URL derived from that domain.

The root cause is explicitly stated: the challenge fetch uses Go's default http.Get rather than a protected client. Go's default http.Get inherits the process default transport and performs no destination filtering — it will freely issue requests to loopback addresses (127.0.0.0/8, ::1), private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local addresses (169.254.0.0/16), and cloud instance metadata endpoints (for example 169.254.169.254). A protected client typically enforces scheme allow-listing, host/IP block-listing, DNS rebinding defenses, redirect caps, and egress restrictions. Because these controls are absent on this code path, attacker-controlled domains can be resolved or redirected to arbitrary internal destinations.

Two properties of the flaw amplify its impact. First, the request is server-initiated, so it originates from inside Zitadel's trust boundary — any internal firewall rules that permit egress from the Zitadel host apply. Second, because domain verification involves redirection (the attacker controls DNS and HTTP responses), the SSRF can bypass naive string-based validation that only checks the initially submitted hostname. Since Zitadel is a public-facing identity provider, this vulnerable path is reachable by parties able to influence the domain verification request, making the attack surface internet-exposed.

The provided intelligence does not include a CVSS score (NVD reports N/A), EPSS is unscored, no public proof-of-concept or Nuclei template is available, and CISA KEV status is NO. No patch evidence exists from any tracked source (0/4), though the description names 4.16.2 as the version in which the issue is addressed.

Exploitation Scenarios

No public PoC is available; the following chain is inferred from the vulnerability class (CWE-918) and the specific mechanism described in the NVD entry.

1. Reconnaissance / target identification. The attacker identifies a Zitadel deployment (e.g., via Shodan using http.title:"Zitadel" or http.html:"zitadel") and confirms that self-service organization domain onboarding or an administrative domain-verification workflow is exposed. The attacker registers a domain they fully control (DNS and HTTP server).

2. Triggering the flaw. The attacker submits the controlled domain through the organization domain verification feature. Zitadel's verification logic constructs a challenge fetch URL from that domain. Critically, the fetch is performed with Go's default http.Get instead of the protected client, so no destination allow-list or private-IP block is applied.

3. Payload / execution. The attacker configures their DNS record or HTTP redirect chain so the verification request is routed to an internal address rather than the attacker's public host. This includes loopback (127.0.0.1), internal service addresses, and cloud metadata endpoints such as 169.254.169.254. Because the request is issued by the Zitadel server, it traverses the trusted internal network path. The attacker observes the response (status code, body, timing) returned or reflected through the verification result.

4. Post-exploitation impact. By iterating over ports and internal hosts via the redirect target, the attacker performs internal port scanning and network mapping to discover reachable services not exposed to the internet. If a cloud metadata endpoint is reachable, the attacker may retrieve instance metadata and potentially credentials, enabling lateral movement and privilege escalation. The verification responses can also confirm or deny the existence of internal hosts and services, aiding follow-on targeting.

Impact Assessment

This is a network-reachable, unauthenticated SSRF against a public-facing identity provider. Although CVSS is reported as N/A by NVD, applying the standard vector for this class yields confidentiality-focused impact against the internal network rather than direct compromise of application integrity: the attacker manipulates server requests rather than data, but the internal visibility gained frequently becomes a precursor to credential theft and lateral movement. Affected systems are any Zitadel deployment before 4.16.2 that exposes the organization domain verification flow. Blast radius is determined by Zitadel's network position: deployments co-located with internal services or running in cloud environments with reachable metadata endpoints face the greatest risk. Impact includes internal network reconnaissance, service enumeration, exposure of cloud instance metadata, and potential credential compromise, with secondary availability/performance impact from forced request volume.

Detection Guidance

Sigma Rule

title: Zitadel Organization Domain Verification SSRF Attempt
id: 7c2b1a94-0f3e-4a6b-9d12-zitadelssrf
status: experimental
description: Detects organization domain verification requests resolving to loopback, private, or cloud metadata addresses indicative of CVE-2026-105214 SSRF.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-105214
author: valtersit.com
logsource:
  product: zitadel
  service: domain_verification
detection:
  keywords_domain:
    - '127.0.0.1'
    - 'localhost'
    - '169.254.169.254'
    - 'metadata.google.internal'
    - '10.'
    - '192.168.'
    - '172.16.'
    - '172.17.'
    - '172.18.'
  condition: keywords_domain
falsepositives:
  - Legitimate internal test domains registered by administrators
level: high

YARA Rule

rule CVE_2026_105214_Zitadel_SSRF_Indicators
{
    meta:
        description = "Detects indicators of Zitadel SSRF domain verification abuse (CVE-2026-105214)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-105214"
        date = "2026-01-01"
    strings:
        $meta = "169.254.169.254" ascii wide nocase
        $loopback = "127.0.0.1" ascii wide
        $gcp = "metadata.google.internal" ascii wide nocase
        $verify = "domain" ascii wide nocase
        $httpget = "http.Get" ascii wide
    condition:
        (uint16(0) == 0x5A4D or true) and
        (any of ($meta, $loopback, $gcp))
}

Suricata IDS Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2026-105214 Zitadel SSRF Domain Verification to Internal/Metadata Address"; flow:established,to_server; http.method; content:"GET"; content:"169.254.169.254"; http_uri; content:"Zitadel"; http_header; reference:cve,2026-105214; classtype:attempted-recon; sid:2026105214; rev:1;)

Elastic Detection

sequence by user.name
  [process where event.action == "start" and process.name : "zitadel"]
  [network where
     destination.ip in ("127.0.0.1","169.254.169.254") or
     cidr_match(destination.ip, "10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","169.254.0.0/16")]

Splunk SPL Query

index=zitadel sourcetype=zitadel:http OR sourcetype=zitadel:events
| search ("domain" AND ("verify" OR "verification" OR "challenge"))
| rex field=_raw "(?<target_ip>(?:127\.0\.0\.1|169\.254\.169\.254|10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+|172\.(?:1[6-9]|2\d|3[01])\.\d+\.\d+))"
| where isnotnull(target_ip) OR match(_raw,"(?i)metadata\.google\.internal|localhost")
| table _time, host, src_ip, target_ip, _raw
| sort - _time

Wazuh OSSEC Rule

<group name="zitadel,ssrf,">
  <rule id="105214" level="12">
    <decoded_as>json</decoded_as>
    <field name="message">\.*(domain|verify|verification)</field>
    <regex>169\.254\.169\.254|127\.0\.0\.1|10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+|172\.(1[6-9]|2\d|3[01])\.\d+\.\d+|metadata\.google\.internal|localhost</regex>
    <description>CVE-2026-105214: Zitadel SSRF via organization domain HTTP verification targeting internal or metadata address</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf,recon,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations. Restrict the Zitadel server's outbound network egress so it cannot reach loopback, RFC1918 ranges, or link-local/metadata addresses (169.254.0.0/16) using host firewall or egress proxy rules. Disable or restrict cloud instance metadata access (e.g., enforce IMDSv2 with hop-limit 1 on AWS, block the metadata IP via firewall on other providers). Where the domain verification feature is not required, disable or restrict it to trusted administrators only. Monitor for verification attempts targeting internal-resolved domains.

2. Patch/upgrade steps. Upgrade Zitadel to 4.16.2 or later, which the NVD description indicates addresses the flaw through use of the protected HTTP client for challenge fetches. Coordinate upgrade through standard change control; verify the version post-upgrade. Since no vendor advisory is present in the data, confirm the exact fix in the release notes for 4.16.2.

3. Long-term hardening. Enforce destination validation for all server-side fetches: scheme allow-listing, private-IP block-listing, DNS rebinding protection, redirect caps, and strict timeouts via a centralized protected HTTP client. Adopt egress filtering as defense-in-depth for all public-facing services. Conduct code review to identify other http.Get usage that bypasses the protected client. Deploy internal monitoring for SSRF indicators (internal 200/302 responses from server-initiated requests) and maintain network segmentation to limit blast radius.

References

• NVD — CVE-2026-105214: https://nvd.nist.gov/vuln/detail/CVE-2026-105214
• CWE-918: Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• OWASP — Server-Side Request Forgery Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
• Zitadel project documentation and release notes: https://github.com/zitadel/zitadel/releases

No public proof-of-concept, exploit code, or threat actor campaign has been observed at the time of writing. CISA KEV status: NO. No exploit-in-the-wild evidence is available.