CVE-2025-54391

Executive Summary

CVE-2025-54391 is a critical authentication bypass vulnerability in Zimbra Collaboration (ZCS) that allows an attacker with valid user credentials to completely bypass Two-Factor Authentication (2FA). The flaw resides in the EnableTwoFactorAuthRequest SOAP endpoint, where the server fails to enforce a valid 2FA token or proof of access to an existing 2FA method before allowing the configuration of an additional 2FA method. This enables an attacker to register their own authenticator app or email-based 2FA, effectively neutralizing the account’s 2FA protection and gaining persistent unauthorized access.

The vulnerability has a CVSS score of 0.0 in the NVD data, but based on the technical description, a more realistic score is 8.8 (High) due to the low attack complexity, required low privileges, and high impact on confidentiality, integrity, and availability. No public exploit code or proof-of-concept is currently available, but the attack vector is straightforward for any attacker with valid credentials.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a server-side authentication logic flaw in the Zimbra Collaboration Suite (ZCS) Java-based backend.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The SOAP endpoint is accessible over the network.
• Attack Complexity (AC): Low (L) – No special conditions or race conditions required.
• Privileges Required (PR): Low (L) – Attacker needs valid user credentials (username/password).
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component is the same as the impacted component.
• Confidentiality (C): High (H) – Full access to all user data.
• Integrity (I): High (H) – Attacker can modify account settings and data.
• Availability (A): High (H) – Attacker can lock out the legitimate user by changing 2FA methods.

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Base Score: 8.8 (High)

Threat Level: Critical – Immediate patching and mitigation required.

Deep Dive & Mechanics

The vulnerability is rooted in the EnableTwoFactorAuthRequest SOAP endpoint. In a properly secured implementation, when a user requests to add a new 2FA method (e.g., a new authenticator app), the server must verify that the request is accompanied by a valid 2FA token from an already-configured method. This ensures that only the legitimate user can modify their 2FA settings.

In CVE-2025-54391, the server fails to perform this verification. The endpoint accepts the request and registers the new 2FA method without requiring the existing token. The attacker only needs to provide valid username/password credentials (which they may have obtained via phishing, credential stuffing, or other means) and then call the SOAP endpoint with the new 2FA method details.

Attack Flow:

1. Attacker obtains valid credentials for a target Zimbra account (e.g., via phishing).
2. Attacker logs in to the Zimbra web client or directly calls the SOAP API.
3. Attacker sends a crafted EnableTwoFactorAuthRequest SOAP request to register a new authenticator app or email-based 2FA method.
4. The server accepts the request without requiring the existing 2FA token.
5. Attacker now has full control over the account, including the ability to log in with their own 2FA method.
6. The legitimate user may be locked out if the attacker removes or changes the original 2FA method.

Root Cause: Missing server-side validation of the existing 2FA token during the addition of a new 2FA method.

Vulnerable vs. Patched Code

Since no official patch or source code is available, the following is a conceptual comparison based on the vulnerability description.

Vulnerable Code (Conceptual Java):

public class TwoFactorAuthService {
    public void enableTwoFactorAuth(EnableTwoFactorAuthRequest request, AuthToken authToken) {
        // Only checks if user is authenticated via password
        if (!isValidUser(authToken)) {
            throw new AuthenticationException("Invalid credentials");
        }
        // Missing: Check if user already has 2FA configured and require a valid token
        // Directly registers the new method
        registerTwoFactorMethod(request.getUserId(), request.getNewMethod());
    }
}

Patched Code (Conceptual Java):

public class TwoFactorAuthService {
    public void enableTwoFactorAuth(EnableTwoFactorAuthRequest request, AuthToken authToken) {
        if (!isValidUser(authToken)) {
            throw new AuthenticationException("Invalid credentials");
        }
        // New: If user already has 2FA, require a valid token from an existing method
        if (userHasTwoFactorEnabled(request.getUserId())) {
            if (!validateTwoFactorToken(request.getUserId(), request.getExistingToken())) {
                throw new AuthenticationException("Invalid 2FA token");
            }
        }
        registerTwoFactorMethod(request.getUserId(), request.getNewMethod());
    }
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Valid credentials for a Zimbra account (username and password).
• Network access to the Zimbra SOAP endpoint (typically /service/soap).

Exploitation Steps:

1. Obtain a valid auth token by logging in with the compromised credentials.
2. Craft a SOAP request to EnableTwoFactorAuthRequest with the new 2FA method details.
3. Send the request to the Zimbra server.

Example SOAP Request (Conceptual):

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <context xmlns="urn:zimbra">
      <authToken>VALID_AUTH_TOKEN</authToken>
    </context>
  </soap:Header>
  <soap:Body>
    <EnableTwoFactorAuthRequest xmlns="urn:zimbraAccount">
      <method type="app">
        <name>AttackerApp</name>
        <secret>ATTACKER_SECRET</secret>
      </method>
    </EnableTwoFactorAuthRequest>
  </soap:Body>
</soap:Envelope>

Expected Outcome: The server registers the new 2FA method without requiring the existing token. The attacker can now log in using their own 2FA method.

Blue Team (Detection & Defense)

Detection:

• Monitor SOAP API logs for EnableTwoFactorAuthRequest calls that are not preceded by a successful 2FA verification.
• Alert on multiple 2FA method registrations for the same user within a short time window.
• Look for login attempts from unusual IP addresses followed by 2FA configuration changes.

Defense:

• Immediately apply any available patches from Zimbra.
• If patching is not possible, implement a WAF rule to block EnableTwoFactorAuthRequest requests that do not include a valid 2FA token.
• Enforce strict session management and require re-authentication for sensitive operations.
• Monitor for credential stuffing attacks and implement account lockout policies.

Indicators of Compromise (IOCs)

• Network IOCs:
  • SOAP requests to /service/soap with EnableTwoFactorAuthRequest body.
  • Unusual IP addresses making 2FA configuration changes.
• Log IOCs:
  • Log entries showing EnableTwoFactorAuthRequest without a preceding 2FA verification.
  • Multiple 2FA method registrations for the same user in a short period.
• Account IOCs:
  • User accounts with unexpected 2FA methods (e.g., unknown authenticator app names).
  • User accounts where 2FA was enabled without user action.

Detection Engineering

YARA Rule

rule Detect_Zimbra_2FA_Bypass_Attempt {
    meta:
        description = "Detects SOAP requests attempting to bypass 2FA in Zimbra Collaboration"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-54391"
    strings:
        $soap_action = "EnableTwoFactorAuthRequest"
        $method_app = "<method type=\"app\">"
        $method_email = "<method type=\"email\">"
    condition:
        $soap_action and ($method_app or $method_email)
}

Sigma Rule

title: Zimbra 2FA Bypass via EnableTwoFactorAuthRequest
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects SOAP API calls to EnableTwoFactorAuthRequest that may indicate a 2FA bypass attempt.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-54391
logsource:
    category: webserver
    product: zimbra
detection:
    selection:
        cs-uri-query|contains: "EnableTwoFactorAuthRequest"
    condition: selection
falsepositives:
    - Legitimate 2FA configuration changes by authorized users
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-54391 Zimbra 2FA Bypass Attempt"; flow:to_server; content:"EnableTwoFactorAuthRequest"; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Apply any official patch from Zimbra as soon as it becomes available. Monitor Zimbra’s security advisories.
2. Workaround: If patching is not possible, implement a WAF rule to block EnableTwoFactorAuthRequest requests that do not include a valid 2FA token.
3. Monitor: Enable detailed logging for SOAP API calls and monitor for suspicious 2FA configuration changes.
4. Credential Hygiene: Enforce strong password policies and implement multi-factor authentication for all accounts.

Long-Term Mitigations:

• Conduct a security audit of all SOAP endpoints to ensure proper authentication and authorization checks.
• Implement rate limiting on sensitive API endpoints.
• Use a Web Application Firewall (WAF) to detect and block exploitation attempts.
• Educate users about phishing attacks that may lead to credential compromise.

Valters IT