Spree Security Update Addresses 1 Vulnerability
Tech GuruQuick Answer
Spree CVE-2026-94462 lets an authenticated customer associate another shopper's guest cart with their own account because the Store API v3 backend does not verify possession of that cart. The disclosed address exposure requires an unassociated guest cart that already contains checkout addresses and a store not using login_required mode. Update the affected backend branch to a supported release containing the 5.4.4 or 5.5.4 fix.
Confirm Scope And Apply The Supported Fix
What to do now: identify the deployed spree_api version, guest-checkout configuration and cart-association endpoint. Schedule the backend update and review unexpected cart ownership/email changes without exposing shopper addresses in diagnostic reports.
Source recheck: October 2, 2026 UTC. The linked project advisories were checked for this revision; deployment applicability and successful remediation still require local evidence. Recheck the supported release before changing production.
Scope And Authority
| Product scope | Spree packages and release streams identified in the project advisories |
|---|---|
| Advisory | GHSA-4825-p4xm-pcf2 |
| CVE | CVE-2026-94462 |
| Authoritative release date | 2026-07-20 UTC (project advisory dates, not database ingestion) |
| Authority revision date | 2026-09-21 UTC (project advisory dates, not database ingestion) |
| Affected versions | spree_api >= 5.4.0, < 5.4.4; spree_api >= 5.5.0, < 5.5.4 |
| Fixed version | spree_api 5.4.4; spree_api 5.5.4 |
| CVSS base score | 7.1 (CVSS v3) |
| CVSS severity | High |
| Exploitation status | Not stated by the authority; no exploitation claim is inferred. |
What Changed
The endpoint checks that the caller is signed in but omits the cart-token authorization used by neighboring actions. A cart identifier is not proof of possession. Successful misuse can expose stored checkout addresses, reassign the guest cart and overwrite its email. The project says its official storefront already supplies a cart token, so replacing that frontend alone does not fix the missing backend check.
What To Validate Now
- Inventory. Record backend gem versions, Store API v3 consumers, guest-checkout settings and custom cart-association integrations.
- Establish applicability. Compare each deployment with the authority's affected-version statement: spree_api >= 5.4.0, < 5.4.4; spree_api >= 5.5.0, < 5.5.4 Do not infer applicability from product family or severity alone.
- Remediate. Apply spree_api 5.4.4; spree_api 5.5.4 through the supported vendor or project channel, following the current advisory and change-control requirements.
- Validate. In staging, use two synthetic shoppers and disposable carts to confirm that a signed-in user cannot claim another guest cart without its possession token. Verify that a legitimate guest-to-account checkout still works; never enumerate real customer carts.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
Use the exact supported release stream and repository. Test dependencies, clusters, integrations, and rollback before broad deployment; a CVSS rating or reachable feature is not evidence of exploitation.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
