CVE-2026-30777: MFA Bypass in EC-CUBE Administrative Interface

EC-CUBE represents a significant portion of the e-commerce market in Japan. Its administrative interface is protected by a Multi-Factor Authentication (MFA) mechanism designed to prevent unauthorized access even if primary credentials are compromised. However, CVE-2026-30777 reveals a logical flaw in how the application enforces these checks.

The vulnerability exists within the TwoFactorAuthListener, a middleware component responsible for intercepting requests and verifying MFA status. Due to an overly permissive configuration in the listener's exclusion list, specific administrative routes were exempted from MFA enforcement globally. This oversight creates a direct path for attackers to circumvent the security control entirely.

While the attacker requires valid primary credentials (username and password) to exploit this flaw, the vulnerability negates the specific security control (MFA) intended to mitigate credential theft. Consequently, an attacker who has obtained credentials via phishing or reuse can achieve full administrative access despite the presence of 2FA.

The vulnerability is classified as CWE-288: Authentication Bypass Using an Alternate Path or Channel. The root cause lies in the static configuration of the ROUTE_EXCLUDE array within src/Eccube/EventListener/TwoFactorAuthListener.php.

The application defines a list of routes that must be accessible without passing an MFA check, such as the login page itself or the MFA code entry page. Crucially, the route admin_two_factor_auth_set—which handles the generation and registration of new TOTP secrets—was included in this exclusion list unconditionally.

The developers likely intended this exclusion to allow users to set up MFA for the first time. However, the logic failed to verify whether the user already had MFA configured. As a result, the application processes requests to the setup endpoint from any authenticated user, regardless of whether they have completed the MFA challenge for the current session.

The patch addresses the vulnerability by removing the unconditional exclusion and implementing a conditional check based on the user's state. Below is an analysis of the changes in TwoFactorAuthListener.php.

Vulnerable Code

In the pre-patch version, the setup route was hardcoded into the global exclusion list:

// src/Eccube/EventListener/TwoFactorAuthListener.php
 
// The 'admin_two_factor_auth_set' route is globally excluded from MFA checks
public const ROUTE_EXCLUDE = [
    'admin_two_factor_auth',
    'admin_two_factor_auth_set' // VULNERABILITY: Unconditional exclusion
];

Patched Code

The fix introduces a distinction between routes that are always excluded and routes that are only excluded when MFA is not yet configured:

// src/Eccube/EventListener/TwoFactorAuthListener.php
 
public const ROUTE_EXCLUDE = ['admin_two_factor_auth'];
 
// New constant for conditional exclusion
public const ROUTE_EXCLUDE_WHEN_NOT_CONFIGURED = ['admin_two_factor_auth_set'];
 
public function onKernelController(ControllerEvent $event)
{
    // ... [snip] ...
    
    // Check if the current route is in the conditional exclusion list
    if (in_array($route, self::ROUTE_EXCLUDE_WHEN_NOT_CONFIGURED)) {
        // Only allow bypass if the user DOES NOT have a key set
        if ($Member instanceof Member && !$Member->getTwoFactorAuthKey()) {
            return;
        }
    }
    
    // Proceed with standard MFA enforcement
    // ...
}

Additionally, the controller TwoFactorAuthController.php was updated to redirect users away from the setup page if they already possess an active key, providing defense-in-depth.

Exploiting this vulnerability requires the attacker to possess valid administrative credentials. The attack flow bypasses the standard authentication workflow by manually manipulating the URL structure.

Attack Sequence

1. Authentication: The attacker logs in to the admin panel using a stolen ID and password.
2. Interception: The application redirects the attacker to admin_two_factor_auth, prompting for a TOTP code.
3. Bypass: Instead of entering the code, the attacker modifies the browser URL to https://[target]/admin/setting/system/two_factor_auth/set.
4. Overwrite: Due to the route exclusion, the application renders the MFA setup page. The attacker scans the new QR code or copies the secret key into their own authenticator app.
5. Access: The attacker submits the new token. The server updates the database with the attacker's key and grants full session access.

The impact of this vulnerability is high within the context of the affected application, though the CVSS score is moderated by the requirement for initial privileges (the password).

• Confidentiality (High): An attacker can access all customer data, order history, and PII stored in the e-commerce system.
• Integrity (High): The attacker can modify product prices, inject malicious JavaScript (e.g., credit card skimmers) into the storefront, or alter order statuses.
• Availability (Low/None): While the attacker could delete data, the primary risk is unauthorized control rather than denial of service.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N (Base 4.9). Note that while confidentiality and availability are marked Low/None in the vector relative to the vulnerability mechanism (bypass), the result of gaining admin access implies total system compromise. The CVSS v4.0 assessment elevates this to a Base Score of 6.9, reflecting the severity more accurately.

The primary remediation is to apply the official patches provided by EC-CUBE. The fix logic is robust, introducing state-aware checks that prevent the setup route from being accessed if an MFA key is already present.

Affected Versions & Fixes

• EC-CUBE 4.3 Series: Update to 4.3.1-p1 or later.
• EC-CUBE 4.2 Series: Update to 4.2.3-p2 or later.
• EC-CUBE 4.1 Series: Update to 4.1.2-p5 or later.

Temporary Workarounds

If immediate patching is not feasible, administrators can mitigate the risk by restricting access to the administrative path (/admin) to trusted IP addresses via web server configuration (Apache .htaccess or Nginx allow/deny directives). This reduces the attack surface by requiring network-level access in addition to stolen credentials.