CVE-2026-31888: Shopware Information Disclosure Flaw

CVE-2026-31888 Overview

Shopware, an open commerce platform, contains a customer account enumeration vulnerability in the Store API login endpoint. Prior to versions 6.7.8.1 and 6.6.10.15, the Store API login endpoint (POST /store-api/account/login) returns different error codes depending on whether the submitted email address belongs to a registered customer (CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS) or is unknown (CHECKOUT__CUSTOMER_NOT_FOUND). The "not found" response also echoes the probed email address back to the attacker. This allows an unauthenticated attacker to enumerate valid customer accounts.

Critical Impact

Attackers can enumerate valid customer email addresses through the Store API, enabling targeted phishing campaigns, credential stuffing attacks, and privacy violations for e-commerce customers.

Affected Products

• Shopware versions prior to 6.7.8.1
• Shopware versions prior to 6.6.10.15
• Shopware Store API login endpoint (/store-api/account/login)

Discovery Timeline

• 2026-03-11 - CVE CVE-2026-31888 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-31888

Vulnerability Analysis

This vulnerability is classified under CWE-204 (Observable Response Discrepancy), which occurs when an application returns distinguishable responses that reveal sensitive information about the system's internal state. In the case of Shopware's Store API, the login endpoint exhibits inconsistent error handling behavior compared to the storefront login controller.

When a login attempt is made via the Store API, the system responds with CHECKOUT__CUSTOMER_NOT_FOUND if the email address does not exist in the database, and CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS if the account exists but the password is incorrect. This differential response pattern allows attackers to systematically probe the API to build a list of valid customer email addresses.

The vulnerability is particularly concerning because the storefront login controller correctly unifies both error paths, indicating that the developers were aware of the enumeration risk but failed to apply consistent defenses across all authentication endpoints. This inconsistency suggests a gap in the security review process for API endpoints.

Root Cause

The root cause of this vulnerability is inconsistent error handling between the Store API and the storefront login controller. While the storefront correctly returns a unified error message regardless of whether the email exists, the Store API maintains separate error codes that disclose account existence. Additionally, the "not found" response echoes the probed email address, providing confirmation to attackers that their enumeration attempt was processed.

Attack Vector

An unauthenticated attacker can exploit this vulnerability remotely over the network by sending HTTP POST requests to the /store-api/account/login endpoint with various email addresses. The attack requires no user interaction and has low complexity—attackers simply need to automate requests and analyze the error codes returned.

The attacker can use the following methodology to enumerate accounts:

1. Compile a list of potential email addresses (from data breaches, social engineering, or dictionary generation)
2. Send login requests to the Store API endpoint with each email and any password
3. Analyze the response error codes to differentiate between existing and non-existing accounts
4. Build a validated list of customer email addresses for further attacks

This enumeration data can subsequently be used for credential stuffing attacks, targeted phishing campaigns, or sold to malicious actors.

Detection Methods for CVE-2026-31888

Indicators of Compromise

• Unusually high volume of failed login attempts to /store-api/account/login from single IP addresses or IP ranges
• Sequential or automated login attempts with varying email addresses but consistent password patterns
• Responses containing CHECKOUT__CUSTOMER_NOT_FOUND error codes in high frequency
• Login attempts from IP addresses associated with known malicious infrastructure

Detection Strategies

• Implement rate limiting detection rules for the Store API login endpoint to identify enumeration attempts
• Monitor for patterns of rapid successive login failures with different email addresses from the same source
• Create alerts for unusual geographic distribution of login attempts that may indicate automated enumeration
• Deploy web application firewall (WAF) rules to detect and block automated enumeration behavior

Monitoring Recommendations

• Enable detailed logging for all Store API authentication endpoints including request metadata
• Implement real-time alerting for login attempt thresholds exceeding normal baseline activity
• Monitor response code distributions for the login endpoint to detect enumeration patterns
• Track and correlate failed login attempts across both Store API and storefront endpoints

How to Mitigate CVE-2026-31888

Immediate Actions Required

• Upgrade Shopware to version 6.7.8.1 or 6.6.10.15 immediately
• Review access logs for evidence of past enumeration attempts against the Store API login endpoint
• Implement rate limiting on the /store-api/account/login endpoint if not already in place
• Consider implementing CAPTCHA or progressive delays after failed login attempts

Patch Information

Shopware has released security patches in versions 6.7.8.1 and 6.6.10.15 that address this vulnerability by unifying the error response for both existing and non-existing accounts, preventing attackers from distinguishing between the two scenarios. For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• Implement a web application firewall (WAF) rule to return consistent error responses for all login failures
• Deploy rate limiting on the Store API login endpoint to slow down enumeration attempts
• Consider temporarily disabling the Store API login endpoint if not required for business operations
• Implement IP-based blocking for sources exhibiting enumeration behavior

# Example: Rate limiting configuration for nginx
# Add to server block for Shopware API endpoint

location /store-api/account/login {
    limit_req zone=login_limit burst=5 nodelay;
    limit_req_status 429;
    proxy_pass http://shopware_backend;
}

# Define the rate limit zone in http block
# limit_req_zone $binary_remote_addr zone=login_limit:10m rate=10r/m;