CVE-2026-31888: Observable Response Discrepancy in Shopware Store API

Shopware provides a Store API to facilitate headless commerce operations, including authentication through the /store-api/account/login endpoint. This endpoint accepts standard JSON payloads containing an email address and a password. Due to insufficient normalization of error handling, the API exposes the existence or non-existence of customer accounts to unauthenticated requesters.

The vulnerability is classified as an Observable Response Discrepancy (CWE-204). The API returns distinct error codes based on whether the queried email address exists in the underlying database. This allows an attacker to bypass intended privacy controls and systematically map out the user base by submitting lists of candidate email addresses and evaluating the HTTP responses.

Account enumeration serves as a critical reconnaissance step in broader attack chains. By verifying which email addresses correspond to valid accounts, an attacker can highly target subsequent credential stuffing, password spraying, or spear-phishing campaigns. The impact is limited to information disclosure (CVSS Confidentiality: Low), but the lack of authentication or user interaction requirements increases the overall risk profile.

The root cause of this vulnerability lies in the inconsistent exception handling within the Store API's login routing logic. The AccountService::getCustomerByLogin method is responsible for validating the provided credentials against the user database. When authentication fails, this method differentiates the failure modes by throwing distinct PHP exceptions.

If the provided email address does not match any existing records in the database, the method throws a CustomerNotFoundException. The API framework subsequently catches this exception and translates it into a specific JSON error response with the code CHECKOUT__CUSTOMER_NOT_FOUND. Additionally, this error payload echoes the queried email address back to the client in the response details.

Conversely, if the email address exists but the provided password is incorrect, the method throws a BadCredentialsException. This translates into an API response with the code CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS. By failing to catch and normalize these exceptions into a generic authentication failure message at the controller boundary, the application leaks the internal database state directly to the client.

Exploitation requires sending standard HTTP POST requests to the vulnerable /store-api/account/login endpoint. The attacker does not need any prior authentication or specific network positioning. The requests require a JSON body containing the target email and a generic password string.

POST /store-api/account/login HTTP/1.1
Host: vulnerable-shopware.local
Content-Type: application/json
 
{
  "email": "target@example.com",
  "password": "InvalidPassword123!"
}

The attacker observes the resultant JSON response body. An invalid account yields a 400 or 401 status with the error code CHECKOUT__CUSTOMER_NOT_FOUND. A valid account yields a response with the error code CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS. The attacker scripts this process to iterate over thousands of candidate addresses, classifying them based purely on string matching within the returned error codes.

Even if the explicit error codes are unified, the underlying authentication logic may introduce an Information Exposure Through Environmental Side-Channels (CWE-208). In a typical vulnerable implementation, the application first queries the database for the user record. If the record is absent, the execution flow terminates immediately.

If the record exists, the application proceeds to verify the provided password against the stored hash. Shopware utilizes modern, computationally intensive hashing algorithms (such as Argon2 or BCrypt) to secure stored credentials. The execution of functions like password_verify() requires measurable CPU time (often tens to hundreds of milliseconds, depending on the work factor).

This creates a measurable timing discrepancy. Requests targeting non-existent users return significantly faster than requests targeting valid users. An attacker measuring the response latency over a network can statistically differentiate between valid and invalid accounts, effectively performing user enumeration even when the HTTP response body and status codes are perfectly uniform.

Complete remediation of this vulnerability requires changes to both the error handling logic and the cryptographic timing execution paths. The immediate patch involves intercepting the CustomerNotFoundException at the LoginRoute boundary. Instead of passing this exception to the response formatter, the application must re-throw it as a generic BadCredentialsException to ensure the final output is indistinguishable from a standard failed login.

To address the timing side-channel, the authentication service must enforce a constant-time execution flow. This is achieved by computing a "dummy" hash comparison when the user is not found in the database. The system executes password_verify() against a hardcoded, static hash using the provided password, ensuring the CPU spends an equivalent amount of time processing the request regardless of whether the account exists.

Administrators who cannot apply the patches immediately should implement stringent rate limiting on the /store-api/account/login endpoint. Configuring Web Application Firewalls (WAF) or API gateways to track failed authentication attempts by IP address and strictly throttle bulk requests will severely degrade the efficacy of enumeration and subsequent brute-force attacks.