CVE-2025-31124

Executive Summary

CVE-2025-31124 is a medium-severity information disclosure vulnerability in ZITADEL, an open-source identity infrastructure platform. The flaw resides in the username normalization logic when the "Ignoring unknown usernames" security setting is enabled. This setting is designed to prevent username enumeration by always showing the password prompt and returning a generic "Username or Password invalid" error for non-existent users. However, due to a normalization discrepancy, the system inadvertently reveals whether a username exists, bypassing the intended protection. An attacker can exploit this by observing subtle differences in the login flow response (e.g., timing, error messages, or redirect behavior) after username normalization. The vulnerability has a CVSS score of 5.3 (Medium) and affects multiple ZITADEL versions prior to the patched releases. No public exploit code or proof-of-concept is currently available, but the attack vector is straightforward and requires no authentication.

Supply Chain & Package Security

ZITADEL is distributed as a Go binary and Docker image. The vulnerability exists in the core authentication logic, not in a third-party dependency. However, organizations using ZITADEL as a managed service or self-hosted deployment should verify their version and apply patches immediately. The fix involves correcting the normalization process to ensure consistent behavior for both existing and non-existing usernames.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network (AV:N) – exploitable remotely.
• Attack Complexity: Low (AC:L) – no special conditions required.
• Privileges Required: None (PR:N) – unauthenticated attacker.
• User Interaction: None (UI:N) – no victim action needed.
• Scope: Unchanged (S:U) – impact confined to the vulnerable component.
• Confidentiality Impact: Low (C:L) – only username existence is leaked.
• Integrity Impact: None (I:N) – no data modification.
• Availability Impact: None (A:N) – no service disruption.

Threat Level: Medium. While the vulnerability only leaks a boolean (username exists or not), it can be chained with other attacks (e.g., credential stuffing, targeted phishing) to increase the overall risk. The low EPSS score (0.0%) suggests no active exploitation in the wild, but the simplicity of the attack makes it a potential target for automated scanners.

Deep Dive & Mechanics

The vulnerability arises from a logic flaw in the username normalization process during the login flow. ZITADEL’s "Ignoring unknown usernames" setting is intended to prevent attackers from distinguishing between valid and invalid usernames. When enabled, the system should:

1. Accept the username input.
2. Normalize it (e.g., lowercase, trim whitespace, apply Unicode normalization).
3. Check if the normalized username exists in the database.
4. If not, still show the password prompt and return a generic error.

However, the bug causes the normalization to be applied inconsistently. Specifically, the system normalizes the username before checking the "Ignoring unknown usernames" setting, but the normalization result is used in a subsequent step that leaks information. For example, if the normalization changes the username (e.g., converting "User@Example.com" to "user@example.com"), the system may behave differently for existing vs. non-existing users:

• For an existing user, the normalized username matches the stored value, and the login proceeds to the password prompt.
• For a non-existing user, the normalization may trigger a different code path (e.g., a redirect or a different error message) because the system attempts to look up the original (non-normalized) username in some internal cache or session.

This discrepancy allows an attacker to send crafted usernames (e.g., with Unicode homoglyphs, extra spaces, or case variations) and observe the response to determine if the normalized version corresponds to a real user.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

func loginHandler(username, password string) {
    normalizedUsername := normalize(username) // e.g., strings.ToLower(username)
    if ignoringUnknownUsernames {
        user, err := db.FindUserByUsername(normalizedUsername)
        if err != nil {
            // Show generic error but still use normalizedUsername in session
            session.Set("username", normalizedUsername)
            return genericError()
        }
        // Proceed with password check
    } else {
        // Direct lookup
    }
}

Patched Code (Conceptual):

func loginHandler(username, password string) {
    normalizedUsername := normalize(username)
    if ignoringUnknownUsernames {
        // Always use the normalized username for consistency
        user, err := db.FindUserByUsername(normalizedUsername)
        if err != nil {
            // Do not store any username in session
            return genericError()
        }
        // Proceed with password check
    } else {
        // Direct lookup
    }
}

The fix ensures that the normalized username is used consistently in all code paths, and no session data is set for non-existing users.

Exploitation & Lab Setup

Red Team

Objective: Enumerate valid usernames on a ZITADEL instance with "Ignoring unknown usernames" enabled.

Prerequisites:

• Target ZITADEL instance (e.g., https://auth.example.com).
• A list of potential usernames (e.g., from OSINT or common patterns).

Steps:

1. Craft Username Variants: For each candidate username, create multiple normalized variants (e.g., User@Example.com, user@example.com, user@example.com with trailing space, usér@example.com with Unicode).
2. Send Login Requests: Use a tool like curl or a custom script to send POST requests to the login endpoint (e.g., /login).

   curl -X POST https://auth.example.com/login \
     -d "username=User@Example.com&password=test123"
   

3. Analyze Responses: Compare the response for each variant. Look for differences in:
   • HTTP status code (e.g., 200 vs. 302).
   • Response body (e.g., error message text, presence of a CSRF token).
   • Response headers (e.g., Set-Cookie, Location).
   • Response time (timing attack).
4. Identify Valid Usernames: If a variant triggers a different response than the baseline (e.g., a redirect to a password prompt vs. a generic error), the normalized username likely exists.

Example Script (Python):

import requests

target = "https://auth.example.com/login"
usernames = ["admin@example.com", "Admin@Example.com", "admin@example.com "]
for u in usernames:
    r = requests.post(target, data={"username": u, "password": "invalid"})
    print(f"{u}: {r.status_code} - {len(r.text)} bytes")

Blue Team

Detection:

• Monitor for multiple login attempts with varying username case/encoding from the same IP.
• Alert on unusual patterns in login error responses (e.g., different error messages for different usernames).
• Use WAF rules to block requests with excessive Unicode or whitespace variations.

Mitigation:

• Apply the patch immediately.
• If patching is delayed, disable the "Ignoring unknown usernames" setting temporarily.
• Implement rate limiting on login endpoints.
• Enable logging of normalized usernames for forensic analysis.

Indicators of Compromise (IOCs)

• Network:
  • Multiple POST requests to /login with varying username case/encoding.
  • Unusual HTTP response codes (e.g., 302 redirect for some usernames, 200 for others).
• Logs:
  • Repeated login failures with different username variants from the same source IP.
  • Log entries showing normalizedUsername differing from input username.
• System:
  • Unusual CPU/memory spikes on authentication servers due to normalization overhead.

Detection Engineering

YARA Rule

rule CVE_2025_31124_Username_Enumeration {
    meta:
        description = "Detects attempts to exploit CVE-2025-31124 via username normalization"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-31124"
    strings:
        $login_endpoint = "/login" ascii wide nocase
        $username_param = "username=" ascii wide nocase
        $normalized_variant = /username=[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/ ascii wide
    condition:
        $login_endpoint and $username_param and #normalized_variant > 5
}

Sigma Rule

title: CVE-2025-31124 Username Enumeration Attempt
id: 8f3c4d5e-6a7b-8c9d-0e1f-2a3b4c5d6e7f
status: experimental
description: Detects multiple login attempts with varying username case/encoding
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: zitadel
detection:
    selection:
        event: login_failure
        username|re: '.*[A-Z].*@.*'  # Contains uppercase
    condition: selection | count() by src_ip > 10 within 5m
falsepositives:
    - Legitimate users with case-sensitive email clients
level: medium

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"CVE-2025-31124 - ZITADEL Username Enumeration Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/login"; http_uri;
    content:"username="; http_client_body;
    pcre:"/username=[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/";
    threshold: type both, track by_src, count 10, seconds 300;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

1. Immediate Patch: Upgrade ZITADEL to one of the fixed versions: 2.71.6, 2.70.8, 2.69.9, 2.68.9, 2.67.13, 2.66.16, 2.65.7, 2.64.6, or 2.63.9.
2. Workaround: If patching is not immediately possible, disable the "Ignoring unknown usernames" setting in the ZITADEL configuration.
3. Monitoring: Enable detailed logging for login attempts and monitor for anomalous patterns.
4. Rate Limiting: Implement strict rate limiting on authentication endpoints to slow down enumeration attempts.
5. WAF Rules: Deploy web application firewall rules to block requests with excessive Unicode or whitespace variations in the username field.
6. User Education: Advise users to use complex, unique usernames to reduce the impact of enumeration.

Valters IT – Securing digital identities, one patch at a time.