ZITADEL Actions V2 Server-Side Request Forgery (SSRF)

ZITADEL Actions V2 is a feature introduced to allow developers to customize authentication flows and trigger external logic via webhooks. These actions are executed by the ZITADEL server, which issues HTTP requests to user-defined URLs. CVE-2026-27945 is a Server-Side Request Forgery (SSRF) vulnerability residing in the HTTP client implementation used to execute these webhooks.

The core issue is the absence of destination validation. Prior to version 4.11.1, the execution engine would accept any syntactically valid URL and attempt to establish a connection. This behavior allows an attacker with the actions configuration privilege to direct the ZITADEL server to initiate connections to arbitrary hosts, including localhost (127.0.0.1), link-local addresses, and private network ranges (RFC 1918).

While the CVSS score is low (2.1) due to the high privilege requirement (PR:H) and specific configuration needs (AT:P), the architectural flaw represents a significant risk in multi-tenant environments or scenarios where an administrator account is compromised. An attacker can pivot from the ZITADEL instance to the internal network, potentially accessing unauthenticated management interfaces or cloud metadata services.

The vulnerability stems from the direct usage of a standard Go http.Client without a restrictive RoundTripper or pre-flight validation logic. In the vulnerable versions (ZITADEL >= 2.59.0, < 4.11.1), the Action execution logic takes the user-supplied target URL and passes it to the transport layer for execution.

CWE-918 (Server-Side Request Forgery) occurs here because the application processes a user-supplied URL and uses it to perform a request to an unexpected destination. The specific failure was the lack of a 'guard rails' mechanism to inspect the resolved IP address of the target hostname before establishing the TCP connection.

Furthermore, the default behavior of many HTTP clients, including Go's net/http, is to follow HTTP redirects. Even if a naive check validated the initial URL (e.g., ensuring the string does not start with localhost), an attacker could bypass this by pointing the Action to an external server attacker.com, which responds with a 302 Found redirecting to http://127.0.0.1:8080.

The remediation for CVE-2026-27945 involved implementing a custom transport layer that intercepts the request flow to validate the destination against a deny-list.

Vulnerable Logic (Conceptual): In the unpatched version, the execution flow was direct:

// Simplified representation of the vulnerable flow
func ExecuteWebhook(targetURL string, payload []byte) (*http.Response, error) {
    client := &http.Client{Timeout: 5 * time.Second}
    // No validation of targetURL host/IP
    req, _ := http.NewRequest("POST", targetURL, bytes.NewBuffer(payload))
    return client.Do(req)
}

Patched Logic (Commit b2532e9666): The fix introduces a DenyList mechanism and applies it within the RoundTrip method. This ensures that validation occurs immediately before the connection is attempted.

// internal/actions/http_module.go (Patched)
 
func (t *Transport) RoundTrip(req *http.Request) (*http.Response, error) {
    // 1. Extract Hostname
    host := req.URL.Hostname()
 
    // 2. Validate Hostname against DenyList (e.g., "localhost")
    if t.denyList.IsBlocked(host) {
        return nil, fmt.Errorf("target host %s is blocked", host)
    }
 
    // 3. Resolve IP addresses
    ips, err := net.LookupIP(host)
    if err != nil {
        return nil, err
    }
 
    // 4. Validate resolved IPs against DenyList (e.g., 127.0.0.1)
    for _, ip := range ips {
        if t.denyList.IsIPBlocked(ip) {
            return nil, fmt.Errorf("target IP %s is blocked", ip.String())
        }
    }
 
    // 5. Proceed with request if safe
    return t.next.RoundTrip(req)
}

> [!NOTE] > While the patch adds necessary validation, it relies on net.LookupIP before the actual RoundTrip. If the underlying transport performs a second DNS resolution (common in Go's DefaultTransport), this code path remains theoretically vulnerable to DNS Rebinding (TOCTOU) attacks, where the DNS server returns a safe IP during the check and a malicious IP during the connection.

To exploit this vulnerability, an attacker must have a role allowing the configuration of ZITADEL Actions (e.g., IAM_OWNER or ORG_OWNER).

Scenario 1: Internal Port Scanning

1. Setup: The attacker defines a new Action triggered by a common event (e.g., Flow: Login).
2. Configuration: The Action script is set to send a webhook to http://localhost:$PORT.
3. Iteration: The attacker updates the port number (80, 443, 22, 5432) and triggers the flow.
4. Observation: By observing the execution logs or error messages (e.g., Connection refused vs. Timeout vs. Bad Request), the attacker infers which ports are listening on the ZITADEL server.

Scenario 2: Cloud Metadata Exfiltration If ZITADEL is hosted on AWS, GCP, or Azure, the attacker targets the link-local metadata service.

// Malicious Action Configuration
let url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/";
// Triggers the SSRF
let response = http.fetch(url, { method: "GET" });

If the ZITADEL instance has not disabled HTTP access to the metadata service, this request could return temporary credentials associated with the instance role.

The impact of CVE-2026-27945 is constrained by the privileges required to exploit it. It is not an unauthenticated remote code execution vulnerability; it is a post-authentication lateral movement vector.

Confidentiality: Low to Medium. An attacker can map the internal network and potentially read data from internal services that rely solely on network location for authentication (e.g., Redis without password, Actuator endpoints).

Integrity: Low. If internal services allow state-changing operations via GET requests or unauthenticated POST requests (REST APIs), the attacker could modify internal system states.

Availability: None. The vulnerability does not directly allow for denial of service against the ZITADEL instance itself, though it could be used to harass internal services.

EPSS & CVSS: The EPSS score (0.00034) reflects the low probability of mass exploitation due to the high-privilege requirement. The CVSS 4.0 score of 2.1 is derived primarily from the limitation that the attacker is already a high-level administrator.

The primary remediation is to upgrade ZITADEL to version 4.11.1 or later. This version introduces the denylist package which blocks access to loopback and unspecified addresses by default.

Configuration Required for Full Protection: The default patch only blocks loopback addresses (127.0.0.0/8, ::1). It does not automatically block private network ranges (RFC 1918). Administrators must explicitly configure the ZITADEL_EXECUTIONS_DENYLIST environment variable or configuration file to include these ranges if ZITADEL is deployed in a sensitive internal network.

Recommended Deny List for Private Networks:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 169.254.169.254/32 (Cloud Metadata)

Defense in Depth: Regardless of the patch status, infrastructure-level controls should be applied:

1. Kubernetes NetworkPolicies: Restrict egress traffic from the ZITADEL namespace to allow connections only to known external endpoints (e.g., SMTP, SMS providers).
2. Service Mesh / Sidecars: Use Istio or Linkerd to enforce an allow-list for egress traffic, preventing the application from connecting to arbitrary IPs even if the application-level check is bypassed.