CVE-2026-94462: Broken Access Control in Spree Store API v3 Cart Association

The vulnerability exists in Spree open-source e-commerce solution versions 5.4.x (prior to 5.4.4) and 5.5.x (prior to 5.5.4). It resides specifically in the Spree::Api::V3::Store::CartsController#associate controller action. This endpoint is designated for linking a guest cart to an authenticated customer account.

Under default conditions, guest carts are assigned sequential database identifiers. The system obfuscates these identifiers externally using the Sqids library. The resulting strings, known as prefixed IDs, are reversible and lack cryptographic security, which enables users to predict valid cart identifiers.

An authenticated customer can submit an association request for a victim guest cart using its predicted prefixed ID. Because the application logic does not verify ownership of the guest cart during lookup, the server updates the cart owner to the attacker. Consequently, the attacker receives the complete serialized details of the target cart, including the victim guest's personally identifiable information.

The root cause of CVE-2026-94462 is a failure to enforce authorization checks during the cart association process. The application utilizes the Sqids encoding standard to generate public identifiers. Because Sqids is a non-cryptographic, salt-free algorithm, any authenticated client can decode their own cart's ID and systematically compute sequential database identifiers for other carts.

The lookup process in the vulnerable controller handles the query by matching the ID against inactive or unowned carts. Specifically, the database query filters for carts belonging to the current store where the user attribute is null. This logic is intended to match any guest cart.

However, the application accepts the user-controlled key as the sole authorization credential. The controller lacks a check to verify if the requesting client actually initialized or possessed the target guest cart. This omission permits any logged-in user to claim any unauthenticated session cart stored in the database.

The vulnerable implementation of find_cart_for_association did not validate whether the client possessed the corresponding guest token. The system only checked whether the cart belonged to the store and was unassociated. The following code snippet demonstrates the vulnerable controller logic:

# Vulnerable Controller Logic
def associate
  @cart = find_cart_for_association
 
  # The association service executes without verifying the client's token
  result = Spree.cart_associate_service.call(guest_order: @cart, user: current_user, guest_only: true)
 
  if result.success?
    render_serialized_payload(200) { serialize_order(result.value) }
  else
    render_error_payload(result.error)
  end
end
 
private
 
def find_cart_for_association
  # This query retrieves any guest cart matching the provided prefix ID
  current_store.carts.where(user: [nil, current_user]).find_by_prefix_id!(params[:id])
end

The remediation introduces explicit authorization and token verification steps. The patched controller verifies that the request includes the cryptographically secure token associated with the cart. Below is the updated code implementing the security control:

# Patched Controller Logic
def associate
  @cart = find_cart_for_association
  # Enforces update authorization and token possession
  authorize!(:update, @cart, cart_token)
  require_cart_token!
 
  result = Spree.cart_associate_service.call(guest_order: @cart, user: current_user, guest_only: true)
 
  if result.success?
    render_serialized_payload(200) { serialize_order(result.value) }
  else
    render_error_payload(result.error)
  end
end
 
private
 
def require_cart_token!
  # Compares request header x-spree-token with the database-stored cart token
  valid = cart_token.present? && cart_token == @cart.token
 
  raise CanCan::AccessDenied.new(nil, :update, @cart) unless valid
end

Exploitation of this vulnerability requires a valid registered account on the target Spree platform. The attacker first registers or logs in to obtain a valid JSON Web Token (JWT) or session cookie. This token is used to authenticate requests to the Store API.

The attacker then estimates valid guest cart identifiers. Because Spree uses sequential integers encoded via Sqids, the attacker decodes their own cart's prefixed ID to find the active range of database integers. The attacker then encodes adjacent integer values to generate target identifiers.

Finally, the attacker issues a PATCH request to the associate endpoint. This request targets the calculated guest cart identifier but omits the x-spree-token header. The server processes the request, reassigns the cart, and responds with the full cart payload. This payload contains the victim's name, billing address, shipping address, and phone number.

The primary consequence of this vulnerability is the unauthorized disclosure of sensitive customer information. If a guest user has initiated the checkout process, their personal details are stored temporarily in the cart object. This data includes full names, email addresses, phone numbers, and physical addresses.

Additionally, the exploitation causes disruption of the checkout flow. When the attacker associates the guest cart with their own account, the cart's association changes. The victim guest is no longer able to complete their order, as their active session loses access to the hijacked cart.

The vulnerability is rated with a CVSS v3.1 base score of 7.1. The impact on confidentiality is high due to the exposure of raw PII. The impact on integrity is low because the attacker can alter database relationships but cannot modify other server configurations.

To resolve CVE-2026-94462, administrators must upgrade their Spree installations. The vulnerability is addressed in versions 5.4.4 and 5.5.4. These versions implement strict token verification before allowing any cart association.

For organizations unable to immediately upgrade, a temporary mitigation can be implemented using a Web Application Firewall (WAF). Rules should be configured to inspect traffic to /api/v3/store/carts/*/associate. If the PATCH request does not contain the x-spree-token header, the WAF should drop the connection or return a 403 Forbidden response.

Detection can also be performed via log analysis. Security operations teams should monitor application access logs for multiple sequential PATCH requests to the associate endpoint from a single IP address or user account. A high frequency of such requests targeting distinct cart identifiers suggests automated scanning.