CVE-2026-22589: Spree Commerce Auth Bypass Vulnerability

CVE-2026-22589 Overview

CVE-2026-22589 is an Insecure Direct Object Reference (IDOR) vulnerability in Spree, an open source e-commerce solution built with Ruby on Rails. This unauthenticated vulnerability allows attackers to access guest address information without supplying valid credentials or session cookies. The flaw exists in versions prior to 4.10.2, 5.0.7, 5.1.9, and 5.2.5, and stems from improper authorization checks in the address management functionality.

Critical Impact
Unauthenticated attackers can access sensitive customer address information including names, shipping addresses, and contact details without any authentication, potentially affecting all guest checkout orders in affected Spree installations.

Affected Products

Spree versions prior to 4.10.2
Spree versions prior to 5.0.7
Spree versions prior to 5.1.9
Spree versions prior to 5.2.5

Discovery Timeline

2026-01-10 - CVE-2026-22589 published to NVD
2026-01-13 - Last updated in NVD database

Technical Details for CVE-2026-22589

Vulnerability Analysis

This vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key), which occurs when a web application uses user-controlled identifiers to access resources without properly verifying the user's authorization to access those resources.

The vulnerability exists in Spree's ability model and addresses controller. The original implementation granted address management permissions based solely on matching user_id without verifying that the user object was actually persisted (authenticated). This allowed unauthenticated guest users to potentially access address records by manipulating object references, as the authorization check would pass for non-persisted user objects with a nil user_id.

Root Cause

The root cause lies in the ability authorization logic in core/app/models/spree/ability.rb. The original code allowed address management permissions with the condition can :manage, ::Spree::Address, user_id: user.id without checking if the user was actually authenticated and persisted. For guest users with nil user_id, this could match address records that also had nil user_id values, effectively bypassing authentication requirements.

Additionally, the AddressesController lacked a before_action :require_user filter, allowing unauthenticated requests to reach the address management endpoints.

Attack Vector

This vulnerability is exploitable over the network without requiring any authentication or user interaction. An attacker can directly access address management API endpoints without providing valid session cookies or credentials. By enumerating or guessing address object identifiers, an unauthenticated attacker could retrieve guest customer address information including personal details such as names, street addresses, cities, postal codes, and phone numbers.

ruby

# Patched ability.rb - Adds persistence check for address management
can :update, ::Spree::Order do |order, token|
  !order.completed? && (order.user == user || order.token && token == order.token)
end
-      can :manage, ::Spree::Address, user_id: user.id
+      # Address management - only for persisted users with matching user_id
+      can :manage, ::Spree::Address, user_id: user.id if user.persisted?
can [:read, :destroy], ::Spree::CreditCard, user_id: user.id
can :read, ::Spree::Product
can :read, ::Spree::ProductProperty

Source: GitHub Commit

ruby

# Patched addresses_controller.rb - Requires authenticated user
module Spree
  class AddressesController < Spree::StoreController
    helper Spree::AddressesHelper

+    before_action :require_user
    load_and_authorize_resource class: Spree::Address

    def create

Source: GitHub Commit

Detection Methods for CVE-2026-22589

Indicators of Compromise

Unusual access patterns to /addresses or /api/addresses endpoints from unauthenticated sessions
High volume of address lookup requests with sequential or enumerated address IDs
Access to address endpoints without corresponding session cookies or authentication tokens
Server logs showing 200 responses to address endpoints for requests without valid user sessions

Detection Strategies

Implement web application firewall (WAF) rules to detect enumeration patterns against address-related endpoints
Monitor application logs for unauthenticated requests to the AddressesController endpoints
Deploy anomaly detection to identify unusual patterns of address data access
Review access logs for requests to /spree/addresses/* paths without corresponding authenticated sessions

Monitoring Recommendations

Enable detailed logging for all address management operations including the requesting user's authentication status
Set up alerts for bulk address retrieval attempts or sequential ID access patterns
Monitor for geographic anomalies in address access requests that may indicate data harvesting
Track API rate limiting triggers on address-related endpoints

How to Mitigate CVE-2026-22589

Immediate Actions Required

Upgrade Spree to patched versions 4.10.2, 5.0.7, 5.1.9, or 5.2.5 immediately
Review access logs for any evidence of exploitation prior to patching
Conduct an audit of address data that may have been accessed without authorization
Notify affected customers if evidence of data exposure is discovered

Patch Information

The Spree development team has released security patches in versions 4.10.2, 5.0.7, 5.1.9, and 5.2.5. The fix involves two key changes: adding a user.persisted? check to the ability model to ensure only authenticated users can manage addresses, and adding a before_action :require_user filter to the AddressesController to enforce authentication at the controller level.

For detailed patch information, refer to the GitHub Security Advisory and the following commit references:

Workarounds

If immediate patching is not possible, implement a custom before_action filter to enforce authentication on the AddressesController
Use a reverse proxy or WAF to block unauthenticated requests to address management endpoints
Consider temporarily disabling guest checkout functionality until the patch can be applied
Implement additional application-level access controls to validate user authorization for address operations

bash

# Temporary nginx configuration to block unauthenticated address access
# Add to your Spree application's nginx server block
location ~ ^/addresses {
    # Require authentication cookie presence (adjust cookie name as needed)
    if ($cookie_spree_guest_token = "") {
        return 403;
    }
    proxy_pass http://spree_backend;
}