CVE-2026-22589
Unauthenticated IDOR in Spree E-commerce Exposes Guest Addresses
Publication date: 2026-01-10
Last updated on: 2026-01-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| spree | spree | to 5.2.5 (exc) |
| spree | spree_core | to 4.10.2 (exc) |
| spree | spree_storefront | to 4.10.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability can cause privacy violations by exposing personally identifiable information (PII) of guest users without authorization, which may lead to non-compliance with data protection regulations such as GDPR. Unauthorized access to personal data can result in regulatory penalties, legal consequences, and damage to the organization's reputation. Therefore, this vulnerability poses a risk to compliance with common privacy and data protection standards. [1]
Can you explain this vulnerability to me?
CVE-2026-22589 is a high-severity Unauthenticated Insecure Direct Object Reference (IDOR) vulnerability in the Spree e-commerce platform. It allows unauthenticated attackers to access guest users' address information without valid credentials or session cookies by manipulating address object identifiers in requests. The vulnerability exists because the authorization logic incorrectly grants guest users permission to manage addresses due to a faulty check in the CanCanCan Ability class. This lets attackers enumerate and view personally identifiable information (PII) such as full names, physical addresses, and phone numbers of guest users by sending requests to the address edit endpoint. Registered user addresses are not affected. The issue was fixed by restricting address management permissions only to authenticated, persisted users whose user_id matches the address's user_id. [1]
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized disclosure of personally identifiable information (PII) of guest users, including full names, physical addresses, and phone numbers. An attacker can access this sensitive data without authentication, potentially leading to privacy violations, identity theft, or targeted attacks. It also undermines user trust in the platform's security. The vulnerability does not affect registered users' addresses but exposes guest user data to unauthorized access. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to access the address edit endpoint (/addresses/{addressId}/edit) without authentication, using arbitrary address IDs to see if guest address information is accessible. For example, you can use curl commands to send GET requests to this endpoint with different address IDs and check if personally identifiable information (PII) is returned without valid credentials or session cookies. Example command: curl -i -X GET https://your-spree-site.com/addresses/123/edit -L -v If the response returns guest address details without authentication, the system is vulnerable. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Spree to one of the patched versions: 4.10.2, 5.0.7, 5.1.9, or 5.2.5. These versions include fixes that restrict address management permissions to authenticated, persisted users only, preventing guest users from accessing or managing guest addresses. Additionally, ensure that the authorization logic enforces that only users with persisted accounts and matching user_id can manage addresses, and that the address controller requires authentication before allowing access to address management endpoints. If upgrading immediately is not possible, restrict access to the /addresses/{addressId}/edit endpoint to authenticated users only via web server or application firewall rules as a temporary measure. [2, 3, 4, 5]