CVE-2026-25758: 
Ruby vulnerability analysis and mitigation

CVE-2026-25758 is an Insecure Direct Object Reference (IDOR) vulnerability in Spree Commerce's guest checkout flow that allows unauthenticated attackers to access other guests' personally identifiable information (PII) by manipulating address ID parameters. Disclosed on February 5, 2026, it affects all Spree versions prior to 4.10.3, 5.0.8, 5.1.10, 5.2.7, and 5.3.2. The vulnerability was discovered by the GitHub Security Lab Taskflow Agent and manually verified by GHSL team members. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 7.7 (High) (GitHub Advisory).

The root cause is an incomplete authorization validation in Spree's checkout address assignment logic, classified as CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-284 (Improper Access Control). While nested address attributes (bill_address_attributes[id] and ship_address_attributes[id]) are properly validated through validate_address_ownership, the plain ID parameters bill_address_id and ship_address_id bypass this check entirely. The flaw exists in core/app/models/spree/order/address_book.rb, where the bill_address_id= and ship_address_id= setters check address.user_id == order.user_id — but for guest orders both values are nil, making the comparison nil == nil evaluate to true, effectively bypassing ownership validation. Because Spree address IDs are sequential integers, an attacker can enumerate all guest addresses in the database by simply incrementing the ID parameter (GitHub Advisory).

Successful exploitation allows any unauthenticated guest user to bind arbitrary guest addresses to their own order and subsequently view the full PII of other guests, including names, physical addresses, and phone numbers. The vulnerability affects all guest checkout transactions on unpatched Spree storefronts, exposing customer data at scale through automated enumeration. There is no integrity or availability impact, but the confidentiality breach can affect all guest users who have ever completed or initiated a checkout on the platform (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating exploitation via a simple curl command requiring only a valid session cookie, CSRF token, and order token — all obtainable by any guest user initiating a checkout. No authentication or elevated privileges are required, and the attack is fully network-accessible. The EPSS score is approximately 0.064% (low probability of near-term mass exploitation), and the vulnerability is not currently listed in the CISA KEV catalog. No threat actor attribution or in-the-wild exploitation has been reported (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a Spree-powered storefront running a vulnerable version (< 4.10.3, < 5.0.8, < 5.1.10, < 5.2.7, or < 5.3.2). Confirm it is Spree by inspecting page source or HTTP headers.
2. Establish a guest session: Add a product to the cart and begin the guest checkout process. Collect the order token from the URL, the session cookie (_store_session and token values) from the browser, and the CSRF token from the page source (<meta name="csrf-token">).
3. Identify a target address ID: Since Spree uses sequential integer IDs for addresses, start enumeration from ID 1. Alternatively, note the ID assigned to your own submitted address to infer the range of existing IDs.
4. Send the malicious request: Issue a PATCH request to the checkout address update endpoint, supplying a victim's address ID as the order[ship_address_id] or order[bill_address_id] parameter:

curl -i -X POST \
  -H "x-csrf-token: ${CSRF_TOKEN}" \
  -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" \
  -b "${SESSION_COOKIE}" \
  --data-urlencode "_method=patch" \
  --data-urlencode "authenticity_token=${CSRF_TOKEN}" \
  --data-urlencode "order[ship_address_id]=${VICTIM_ADDRESS_ID}" \
  "http://target-store.com/checkout/${ATTACKER_ORDER_TOKEN}/update/address"

5. View victim PII: Navigate to /checkout/${ATTACKER_ORDER_TOKEN}/delivery in the same browser session. The victim's full name, address, and phone number will be displayed as the shipping address on the attacker's order.
6. Enumerate at scale: Repeat step 4 with incrementing address IDs to harvest PII from all guest addresses stored in the database (GitHub Advisory).

• Network: Repeated PATCH or POST requests to /checkout/<order_token>/update/address or /api/v2/storefront/checkout from the same IP or session, with sequentially incrementing order[ship_address_id] or order[bill_address_id] values.
• Logs: Web server or application logs showing a single guest session submitting many checkout address update requests with different address IDs in rapid succession; HTTP 200 responses to these requests indicating successful binding.
• Application Behavior: Orders in the spree_orders table where ship_address_id or bill_address_id references an address with a different (or null) user_id than the order's user_id, particularly for guest (null user) orders referencing addresses that were previously associated with other guest sessions.

Spree has released patched versions that fix the vulnerability by adding a user_id.present? guard to the bill_address_id= and ship_address_id= setters, ensuring that guest orders (where user_id is nil) can never be assigned an arbitrary address ID. Operators should upgrade to one of the following fixed versions: 4.10.3, 5.0.8, 5.1.10, 5.2.7, or 5.3.2. No configuration-based workaround is available; upgrading is the only remediation. The fix is applied across multiple commits targeting each supported release branch (GitHub Advisory, Patch Commit).

The vulnerability was credited to the GitHub Security Lab Taskflow Agent — an AI-powered security research tool — and manually verified by GHSL researchers @p- (Peter Stöckli) and @m-y-mo (Man Yue Mo), highlighting the growing role of AI in vulnerability discovery. GitHub published a blog post discussing how their open-source AI-powered framework was used to scan for and identify this and other zero-days (GitHub Blog). The case received coverage in security newsletters and was noted as an example of AI-assisted vulnerability research yielding real-world results (TLDR InfoSec).