CVE-2026-31888: 
PHP vulnerability analysis and mitigation

CVE-2026-31888 is a user enumeration vulnerability in Shopware's Store API login endpoint that allows unauthenticated attackers to determine whether a given email address belongs to a registered customer. The flaw exists in the POST /store-api/account/login endpoint, which returns distinct error codes (CHECKOUT__CUSTOMER_NOT_FOUND vs. CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS) depending on whether the submitted email is registered. Affected versions include Shopware shopware/core and shopware/platform prior to 6.7.8.1 (for the 6.7.x branch) and prior to 6.6.10.15 (for the 6.6.x branch). Disclosed on March 11, 2026, it carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Github Advisory).

The root cause is classified as CWE-204 (Observable Response Discrepancy). In AccountService::getCustomerByLogin(), a call to getCustomerByEmail() throws a CustomerNotFoundException (error code CHECKOUT__CUSTOMER_NOT_FOUND) if the email is not found, while an incorrect password for a valid email throws a BadCredentialsException (error code CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS). The LoginRoute::login() method in the Store API lacks a try/catch block to normalize these exceptions, allowing them to propagate to the global ErrorResponseFactory with distinct, distinguishable JSON error codes — and the "not found" response even echoes the probed email address in the response body. By contrast, the storefront's AuthController::login() already catches both exceptions together and returns a generic error, confirming this Store API exposure is an oversight (GitHub Advisory). No authentication or special privileges are required; exploitation requires only network access and a single HTTP POST request per probed email address.

An unauthenticated attacker can systematically probe the Store API login endpoint to build a verified list of registered customer email addresses, with no integrity or availability impact. This confirmed email list can then be leveraged for targeted phishing campaigns (e.g., fake order confirmations), credential stuffing attacks using breached password databases, or social engineering. For stores dealing in sensitive goods (e.g., medical supplies, adult products), confirming a customer's association with the store constitutes a privacy violation. The email reflection in the CHECKOUT__CUSTOMER_NOT_FOUND response could also be used in reflected content attacks (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is trivially exploitable — it requires only unauthenticated HTTP POST requests and no special tooling. While rate limiting is present on the login route, it is keyed on email and IP address, meaning IP rotation effectively bypasses it for single-probe enumeration. The EPSS score is approximately 0.029–0.055% (17th percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Reconnaissance: Identify Shopware-powered storefronts running versions prior to 6.7.8.1 or 6.6.10.15 using HTTP headers, HTML source clues, or tools like Wappalyzer/Shodan.
2. Prepare email list: Compile a list of candidate email addresses to probe — sourced from breached credential databases, OSINT, or targeted guessing based on the store's customer base.
3. Send enumeration requests: For each candidate email, send an unauthenticated HTTP POST request to the Store API login endpoint:

POST /store-api/account/login
Content-Type: application/json

{"email": "probe@example.com", "password": "dummy_password"}

4. Analyze responses: Inspect the JSON error code in the response:
   • CHECKOUT__CUSTOMER_NOT_FOUND → email is not registered
   • CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS → email is registered
5. Rotate IPs if needed: If rate limiting triggers, rotate source IP addresses (e.g., via proxy pool or VPN) to reset the rate limit counter, since the limiter is keyed on email + IP.
6. Compile valid email list: Aggregate all confirmed registered emails for downstream attacks such as credential stuffing or targeted phishing campaigns (GitHub Advisory).

• Network: High volume of POST /store-api/account/login requests from a single IP or distributed IP range, especially with varied email addresses and a constant dummy password; requests returning HTTP 401 with CHECKOUT__CUSTOMER_NOT_FOUND at scale.
• Logs: Web server or application logs showing sequential or rapid-fire login attempts across many distinct email addresses; repeated 401 responses alternating between CHECKOUT__CUSTOMER_NOT_FOUND and CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS error codes from the same source.
• Behavioral: Enumeration pattern where each email is attempted only once (single-probe per address) rather than repeated attempts against the same email (distinguishes enumeration from brute-force); requests originating from known proxy/VPN/Tor exit node IP ranges.

Shopware has released patched versions addressing this vulnerability: update shopware/core and shopware/platform to 6.7.8.1 (for 6.7.x installations) or 6.6.10.15 (for 6.6.x installations). The fix normalizes both CustomerNotFoundException and BadCredentialsException to return the same generic CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS error code in the Store API LoginRoute, mirroring the existing protection in the storefront controller. As a temporary workaround prior to patching, operators should implement IP-based rate limiting at the WAF or reverse proxy level on POST /store-api/account/login, and monitor for enumeration patterns in access logs. Additionally, consider addressing the related registration endpoint (POST /store-api/account/register), which may also leak email existence via CUSTOMER_EMAIL_NOT_UNIQUE (GitHub Advisory).

The vulnerability was discovered and responsibly disclosed by bugbunny.ai, and published by Shopware maintainer mkraeml on March 11, 2026. The advisory received standard coverage from automated CVE tracking services (CVEFeed, VulDB, CIRCL) shortly after publication, with no notable broader media coverage or significant community debate identified. The advisory itself is notable for its thorough technical write-up, including code-level analysis and multiple remediation options (GitHub Advisory).