CVE-2024-49753: Zitadel Auth Bypass Vulnerability

CVE-2024-49753 Overview

CVE-2024-49753 is a Server-Side Request Forgery (SSRF) vulnerability in Zitadel, an open-source identity infrastructure software. The flaw exists in the URL validation mechanism of Zitadel actions, where the isHostBlocked check designed to prevent requests to localhost (127.0.0.1) can be bypassed through DNS rebinding. An attacker can create a DNS record that resolves to 127.0.0.1, effectively circumventing the intended security measures and enabling actions to send requests to localhost despite the blocklist.

Critical Impact

This vulnerability allows unauthorized access to unsecured internal endpoints, potentially exposing sensitive information or enabling attackers to interact with internal services that were never intended to be publicly accessible.

Affected Products

• Zitadel versions prior to 2.64.1
• Zitadel versions prior to 2.63.6
• Zitadel versions prior to 2.62.8
• Zitadel versions prior to 2.61.4
• Zitadel versions prior to 2.60.4
• Zitadel versions prior to 2.59.5
• Zitadel versions prior to 2.58.7

Discovery Timeline

• 2024-10-25 - CVE-2024-49753 published to NVD
• 2025-08-26 - Last updated in NVD database

Technical Details for CVE-2024-49753

Vulnerability Analysis

This SSRF vulnerability stems from improper input validation in Zitadel's URL handling mechanism within the actions feature. The isHostBlocked function was designed as a security control to prevent server-side requests from targeting localhost and other internal addresses. However, the implementation validates the hostname at the time of URL parsing without accounting for DNS resolution behavior, creating a time-of-check time-of-use (TOCTOU) condition that attackers can exploit.

The vulnerability allows unauthenticated remote attackers to bypass localhost restrictions and access internal services. Since Zitadel is an identity management platform, internal endpoints may contain authentication tokens, user data, configuration information, or administrative interfaces. Successful exploitation could lead to significant confidentiality and integrity impacts, including credential theft, privilege escalation, or further lateral movement within the infrastructure.

Root Cause

The root cause is improper input validation (CWE-20) in the URL validation logic. The isHostBlocked function checks whether the provided URL hostname matches blocked addresses like 127.0.0.1 or localhost. However, this check operates on the hostname string rather than the resolved IP address. An attacker can register a custom domain (e.g., evil.attacker.com) that resolves to 127.0.0.1 in DNS. When Zitadel processes the action, the hostname passes the blocklist check, but the actual HTTP request is made to the loopback address.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker exploits this vulnerability through the following mechanism:

1. The attacker registers a domain under their control (e.g., localhost-bypass.attacker.com)
2. The attacker configures DNS to resolve this domain to 127.0.0.1
3. The attacker creates or modifies a Zitadel action to make HTTP requests to their malicious domain
4. When the action executes, the isHostBlocked check passes because the hostname is not literally localhost or 127.0.0.1
5. The actual HTTP request resolves the domain to 127.0.0.1 and reaches internal services

This DNS rebinding technique bypasses hostname-based blocklists by separating the validation target from the request target through DNS resolution timing.

Detection Methods for CVE-2024-49753

Indicators of Compromise

• Unusual DNS queries from Zitadel servers resolving external domains that point to internal IP addresses
• HTTP requests originating from Zitadel to 127.0.0.1 or other loopback/internal addresses
• Zitadel action configurations containing suspicious external domains
• Unexpected access patterns to internal services from the Zitadel application

Detection Strategies

• Monitor network traffic from Zitadel instances for connections to internal IP ranges, particularly loopback addresses
• Implement DNS logging to detect resolution of external domains to internal IP addresses (DNS rebinding indicators)
• Review Zitadel action configurations for URLs containing unfamiliar or recently registered domains
• Enable audit logging for action creation and modification events within Zitadel

Monitoring Recommendations

• Deploy network-based intrusion detection rules to alert on outbound connections from Zitadel to localhost or RFC 1918 addresses
• Implement DNS sinkholing or filtering to block resolution of external domains to internal addresses
• Configure SIEM alerts for anomalous Zitadel action behavior or unexpected internal service access patterns

How to Mitigate CVE-2024-49753

Immediate Actions Required

• Upgrade Zitadel to a patched version immediately: 2.64.1, 2.63.6, 2.62.8, 2.61.4, 2.60.4, 2.59.5, or 2.58.7
• Review existing Zitadel actions for any suspicious URL configurations that may indicate exploitation attempts
• Audit internal services accessible from the Zitadel host for evidence of unauthorized access
• Consider temporarily disabling Zitadel actions if immediate patching is not possible

Patch Information

Multiple patched versions are available depending on your current release branch. Select the appropriate version for your deployment:

• Version 2.64.x: Upgrade to v2.64.1
• Version 2.63.x: Upgrade to v2.63.6
• Version 2.62.x: Upgrade to v2.62.8
• Version 2.61.x: Upgrade to v2.61.4
• Version 2.60.x: Upgrade to v2.60.4
• Version 2.59.x: Upgrade to v2.59.5
• Version 2.58.x: Upgrade to v2.58.7

For complete details, refer to the GitHub Security Advisory GHSA-6cf5-w9h3-4rqv.

Workarounds

• No vendor-provided workarounds are available for this vulnerability; upgrading is the only remediation
• As a defense-in-depth measure, implement network segmentation to limit what internal services the Zitadel host can reach
• Deploy DNS filtering at the network level to prevent resolution of external domains to internal IP addresses
• Consider running Zitadel in an isolated network environment with restricted access to sensitive internal services