CVE-2026-32270: Information Disclosure in Craft Commerce Payments Controller

Craft Commerce operates as a primary ecommerce engine for Craft CMS, handling shopping carts, checkout flows, and payment processing. The platform utilizes a dedicated controller, PaymentsController, to manage transaction initiation and order finalization. The actionPay endpoint within this controller processes payment requests from the frontend and enforces critical business logic regarding order state transitions.

A structural vulnerability exists within this endpoint where authorization failures result in the unintended disclosure of sensitive data. The system accurately detects when an unauthorized actor attempts to interact with a finalized, completed order. However, the mechanism responsible for dispatching the rejection message improperly aggregates the full serialized order object into the response body.

This behavior represents a classic instance of Missing Authorization (CWE-862) compounding with Exposure of Sensitive Information to an Unauthorized Actor (CWE-200). Although the primary action (making a payment) is successfully blocked, the secondary action (reading order data) is implicitly permitted. An unauthenticated attacker can exploit this flaw to extract Personally Identifiable Information (PII) associated with arbitrary orders, provided they possess a valid order number.

The root cause stems from an architectural flaw in how the payment controller constructs error responses for failed authorization states. When an HTTP request targets the actionPay endpoint with a specific order identifier, the application queries the database and instantiates the corresponding order object. The system then evaluates the internal state of the order to determine if it represents an active shopping cart or a completed transaction.

For completed orders, Craft Commerce enforces a strict security perimeter. The system requires the requesting user to provide an email address that matches the primary email associated with the finalized order. If the provided email is missing, malformed, or incorrect, the application accurately evaluates this as an authorization failure and denies the payment attempt. The failure state is then delegated to the asFailure response formatting method.

The vulnerability is introduced because the controller explicitly passes the populated order entity to a serialization helper method named cartArray(). The output of this helper is then appended to the data parameter of the error response payload. The original engineering intent was likely to return cart state data to the frontend to facilitate active session recovery. By failing to restrict this serialization behavior for completed orders where the requester is inherently untrusted, the application creates a direct conduit for data leakage.

The vulnerability is localized entirely within src/controllers/PaymentsController.php in the actionPay method. The vulnerable implementation evaluates the order state via !$order->getIsActiveCart() and the authorization state via !$checkPaymentCanBeMade. When both conditions are met, the code constructs an error string and returns it to the client.

if (!$order->getIsActiveCart() && !$checkPaymentCanBeMade) {
    $error = Craft::t('commerce', 'Email required to make payments on a completed order.');
    return $this->asFailure($error, data: [
        $this->_cartVariableName => $this->cartArray($order),
    ]);
}

The fundamental error lies in the execution of $this->cartArray($order). This helper method processes the entire object graph of the order, exposing internal properties and relational database records. The resulting array contains nested dictionaries holding customer emails, complete shipping addresses, billing addresses, and line item specifics. All of this is serialized directly into the JSON response.

The patch applied in versions 4.11.0 and 5.6.0 resolves the issue by eliminating the data parameter from the asFailure return statement. This ensures the endpoint returns only the localized error message string and a generic boolean failure indicator, completely decoupling the sensitive order data from the error handling path.

if (!$order->getIsActiveCart() && !$checkPaymentCanBeMade) {
    $error = Craft::t('commerce', 'Email required to make payments on a completed order.');
    return $this->asFailure($error);
}

Exploitation of CVE-2026-32270 requires no authentication and can be executed via a standard, unauthenticated HTTP request. The attacker must target the commerce/payments/pay route using standard application parameters. The singular prerequisite for a successful attack is possession or knowledge of a valid order number associated with a completed transaction on the target system.

The attacker crafts a request with a number parameter set to the target identifier (e.g., number=ORDER-12345). Crucially, they must intentionally omit the email parameter or provide an arbitrary string. This guarantees the request fails the completed order validation check and forces the execution flow into the vulnerable error handling routine.

POST /index.php?p=commerce/payments/pay HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded
 
number=ORDER-12345

The application evaluates the request, correctly determines authorization is lacking, and responds with a JSON payload. The success field is set to false, and the error field contains the string "Email required to make payments on a completed order.". Alongside these fields, the payload includes the complete order object, finalizing the data exfiltration.

{
  "success": false,
  "error": "Email required to make payments on a completed order.",
  "order": {
    "email": "victim@example.com",
    "shippingAddress": {
      "firstName": "John",
      "lastName": "Doe",
      "address1": "123 Main St",
      "city": "Anytown",
      "zipCode": "12345"
    }
  }
}

The primary impact of this vulnerability is a targeted breach of confidentiality affecting customer Personally Identifiable Information (PII). Extracted data includes full names, registered email addresses, physical shipping locations, billing addresses, and granular purchase histories. Exposure of this information places users at risk for secondary attacks, including highly targeted phishing campaigns, identity theft, and social engineering against the platform's support channels.

The severity and broad applicability of the exploit are strictly constrained by the requirement to possess a valid order number. If the target application utilizes sequential or highly predictable order numbers, an attacker can trivially automate the enumeration of the entire order database. Conversely, if the application generates high-entropy, unpredictable identifiers (such as UUIDv4), the attack surface is significantly reduced, limiting exploitation to instances where an order number has been leaked through secondary channels such as referrer headers or unsecured communications.

The assigned CVSS 4.0 score of 1.7 accurately reflects these strict environmental constraints. The Attack Complexity is Low (AC:L), and no system privileges are required (PR:N). However, the Attack Requirements (AT:P) modifier indicates that specific preconditions—namely, the acquisition of valid order numbers prior to the attack—must be satisfied for successful exploitation. The impact is limited entirely to Confidentiality (VC:L), with no effects on system Integrity or Availability.

System administrators must prioritize upgrading Craft Commerce to a patched release to eliminate the vulnerability. The security flaw is permanently resolved in version 4.11.0 for deployments operating on the 4.x release branch, and version 5.6.0 for deployments utilizing the 5.x release branch. The update process is safely managed via Composer or directly through the Craft CMS administrative control panel.

Organizations incapable of executing immediate patch deployments should implement temporary mitigation controls at the network boundary. Web Application Firewalls (WAF) can be configured to inspect HTTP response bodies originating from the commerce/payments/pay endpoint. If a response contains the exact authorization error string paired with serialized nested JSON objects representing an order, the WAF can be instructed to drop the packet or sanitize the response body.

From a software engineering perspective, developers implementing custom order reference generators must ensure the output utilizes cryptographically secure pseudorandom number generators (CSPRNG). High-entropy order numbers inherently eliminate the risk of automated enumeration attacks. Furthermore, applications should adopt strict Data Transfer Objects (DTOs) rather than passing entire entity models to serialization routines, establishing a robust defense-in-depth posture against accidental data exposure.