- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 13
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Replies within 3 days
- As the policy promises.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Response
-
Within 3 days
the policy commits to acknowledging within seventy-two hours
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
13 assets you may test, 6 excluded.
Web 1
- https://spreecommerce.org
Products and areas 12
- Email templates and any other place user-supplied content is rendered on the server
- Parameter handling across the engine, including permitted attributes and anything reaching mass assignment
- Payment method integrations, the payment source records they create and the gateway response handling that decides an order is paid
- Product, taxon, variant and stock administration, and the file uploads attached to them
- Promotions, discount rules, coupon codes and store credit, plus the calculators behind them
- The admin dashboard and the ability definitions that authorise each admin action
- The mounted-engine boundary with the host Rails application, covering routing, session sharing and any authentication the host supplies
- The order state machine and every checkout step, including address, delivery, payment and confirmation
- The policy takes private reports on supported Spree releases, publishing an end-of-life table that defines the window, and it names no component carve-out inside it. The whole engine is in scope
- The Spree API, both the storefront and platform namespaces, plus the OAuth application and token model behind them
- The storefront controllers and views, the anonymous and customer-authenticated surface a shopper reaches
- The user, role and permission model, including guest orders and the order token that authorises access without an account
Out of scope (6)
- Deployment and hosting configuration choices
- Host application code a merchant wrote, including decorators and overrides that change Spree's behaviour
- Payment gateway providers' own systems, which are separate estates
- Releases outside the published support window, which the end-of-life table defines
- Third-party Spree extensions maintained outside the core repository
- Upstream Rails and gem dependency issues, unless Spree's own use of the dependency is what makes the defect reachable
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report privately to the address on the policy page ; the policy commits to acknowledging within seventy-two hours
-
Check the published end-of-life table before filing. The 5.x line is supported to March 2027 and older lines are outside the window
-
If you have a fix, the policy asks for it as a git format-patch series sent privately rather than as a public pull request. A pull request discloses the bug to everyone watching the repository
-
The policy sets out a five-step disclosure process. Follow it rather than improvising a timeline
-
Say whether the defect is in Spree itself or only reachable through a decorator or override the host application added, since most Spree deployments customise the engine heavily
-
There is no reward tier and no payment to negotiate
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-25757 | Spree is an open source e-commerce solution built with Ruby on Rails. Prior to versions 5.0.8, 5.1.10, 5.2.7, and 5.3.2, unauthenticated users can view completed guest orders by Order ID. This issue may lead to disclosure of PII of guest users (including names, addresses and phone numbers). This issue has been patched in versions 5.0.8, 5.1.10, 5.2.7, and 5.3.2. | High 7.7 | 6 Feb 2026 |
| CVE-2026-25758 | Spree is an open source e-commerce solution built with Ruby on Rails. 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. | High 7.7 | 6 Feb 2026 |
| CVE-2026-22589 | Spree is an open source e-commerce solution built with Ruby on Rails. Prior to versions 4.10.2, 5.0.7, 5.1.9, and 5.2.5, an Unauthenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an unauthenticated attacker to access guest address information without supplying valid credentials or session cookies. This issue has been patched in versions 4.10.2, 5.0.7, 5.1. | High 7.5 | 10 Jan 2026 |
| CVE-2026-22588 | Spree is an open source e-commerce solution built with Ruby on Rails. Prior to versions 4.10.2, 5.0.7, 5.1.9, and 5.2.5, an Authenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an authenticated user to retrieve other users’ address information by modifying an existing order. By editing an order they legitimately own and manipulating address identifiers in | Medium 6.5 | 8 Jan 2026 |
| CVE-2011-10026 | Spreecommerce versions prior to 0.50.x contain a remote command execution vulnerability in the API's search functionality. Improper input sanitation allows attackers to inject arbitrary shell commands via the search[instance_eval] parameter, which is dynamically invoked using Ruby’s send method. This flaw enables unauthenticated attackers to execute commands on the server. | Critical 9.3 | 20 Aug 2025 |
| CVE-2011-10019 | Spreecommerce versions prior to 0.60.2 contains a remote command execution vulnerability in its search functionality. The application fails to properly sanitize input passed via the search[send][] parameter, which is dynamically invoked using Ruby’s send method. This allows attackers to execute arbitrary shell commands on the server without authentication. | Critical 10.0 | 13 Aug 2025 |
| CVE-2021-41275 | spree_auth_devise is an open source library which provides authentication and authorization services for use with the Spree storefront framework by using an underlying Devise authentication framework. In affected versions spree_auth_devise is subject to a CSRF vulnerability that allows user account takeover. All applications using any version of the frontend component of spree_auth_devise are affe | Critical 9.3 | 17 Nov 2021 |
| CVE-2020-26223 | Spree is a complete open source e-commerce solution built with Ruby on Rails. In Spree from version 3.7 and before versions 3.7.13, 4.0.5, and 4.1.12, there is an authorization bypass vulnerability. The perpetrator could query the API v2 Order Status endpoint with an empty string passed as an Order token. This is patched in versions 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. Us | High 7.7 | 13 Nov 2020 |
| CVE-2013-1656 | Spree Commerce 1.0.x through 1.3.2 allows remote authenticated administrators to instantiate arbitrary Ruby objects and execute arbitrary commands via the (1) payment_method parameter to core/app/controllers/spree/admin/payment_methods_controller.rb; and the (2) promotion_action parameter to promotion_actions_controller.rb, (3) promotion_rule parameter to promotion_rules_controller.rb, and (4) cal | Medium 4.3 | 8 Mar 2013 |
| CVE-2013-2506 | app/models/spree/user.rb in spree_auth_devise in Spree 1.1.x before 1.1.6, 1.2.x, and 1.3.x does not perform mass assignment safely when updating a user, which allows remote authenticated users to assign arbitrary roles to themselves. | Medium 4.0 | 8 Mar 2013 |
| CVE-2008-7310 | Spree 0.2.0 does not properly restrict the use of a hash to provide values for a model's attributes, which allows remote attackers to set the Order state value and bypass the intended payment step via a modified URL, related to a "mass assignment" vulnerability. | Medium 5.0 | 5 Apr 2012 |
| CVE-2008-7311 | The session cookie store implementation in Spree 0.2.0 uses a hardcoded config.action_controller_session hash value (aka secret key), which makes it easier for remote attackers to bypass cryptographic protection mechanisms by leveraging an application that contains this value within the config/environment.rb file. | Medium 5.0 | 5 Apr 2012 |
| CVE-2010-3978 | Spree 0.11.x before 0.11.2 and 0.30.x before 0.30.0 exchanges data using JavaScript Object Notation (JSON) without a mechanism for validating requests, which allows remote attackers to obtain sensitive information via vectors involving (1) admin/products.json, (2) admin/users.json, or (3) admin/overview/get_report_data, related to a "JSON hijacking" issue. | Medium 5.0 | 17 Nov 2010 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 6 Last 12 months 8 Lifetime Access control 35 % Business logic 25 % Info disclosure 22 % XSS/CSRF 18 % Latest advisories Loading the feed Overview Spree is a Rails commerce platform that has been carrying real storefronts for well over a decade, deployed as a mounted engine inside a merchant's own application rather than as a standalone product. That deployment shape matters: a Spree defect executes in the host application's process, with whatever session and database access the host happens to hold. Six of its eight published advisories landed in the last twelve months. The policy is unusually procedural for a project this size, with a seventy-two hour acknowledgement commitment and a documented patch workflow, and it states plainly that it cannot offer monetary rewards. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy takes private reports on supported Spree releases, publishing an end-of-life table that defines the window, and it names no component carve-out inside it. The whole engine is in scope The storefront controllers and views, the anonymous and customer-authenticated surface a shopper reaches The order state machine and every checkout step, including address, delivery, payment and confirmation Promotions, discount rules, coupon codes and store credit, plus the calculators behind them Payment method integrations, the payment source records they create and the gateway response handling that decides an order is paid The admin dashboard and the ability definitions that authorise each admin action The Spree API, both the storefront and platform namespaces, plus the OAuth application and token model behind them The user, role and permission model, including guest orders and the order token that authorises access without an account Product, taxon, variant and stock administration, and the file uploads attached to them The mounted-engine boundary with the host Rails application, covering routing, session sharing and any authentication the host supplies Parameter handling across the engine, including permitted attributes and anything reaching mass assignment Email templates and any other place user-supplied content is rendered on the server Out of scope Releases outside the published support window, which the end-of-life table defines Third-party Spree extensions maintained outside the core repository Host application code a merchant wrote, including decorators and overrides that change Spree's behaviour Payment gateway providers' own systems, which are separate estates Upstream Rails and gem dependency issues, unless Spree's own use of the dependency is what makes the defect reachable Deployment and hosting configuration choices Most-valued findings Order state machine defects that reach a completed order without a valid payment, the most direct financial bug this product can carry Promotion and discount calculation that drives a total below what the goods are worth, including coupon stacking and store credit reuse The guest order token, which authorises access to an order with no account at all. Anything guessable, reusable or checked inconsistently there exposes customer orders to the open internet Admin ability-check gaps in the dashboard, where a limited admin role reaches an action reserved for a higher one, or a customer session reaches the dashboard at all API endpoints acting on another user's order, address or payment source, on either the storefront or the platform namespace OAuth application and token scope defects in the platform API Mass assignment and permitted-parameter gaps, a persistent class in Rails engines where a request sets an attribute the form never exposed Payment gateway response handling that accepts a forged or replayed confirmation Stored cross-site scripting in a product field, an address or an order note that later renders inside an admin session Anything that crosses the mounted-engine boundary into the host application's session or credentials, since Spree runs in the merchant's own process Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately to [email protected] ; the policy commits to acknowledging within seventy-two hours Check the published end-of-life table before filing. The 5.x line is supported to March 2027 and older lines are outside the window If you have a fix, the policy asks for it as a git format-patch series sent privately rather than as a public pull request. A pull request discloses the bug to everyone watching the repository The policy sets out a five-step disclosure process. Follow it rather than improvising a timeline Say whether the defect is in Spree itself or only reachable through a decorator or override the host application added, since most Spree deployments customise the engine heavily There is no reward tier and no payment to negotiate Disclosure Coordinated privately by email under a documented five-step process, with a seventy-two hour acknowledgement commitment and a published support window that decides which lines receive a backport. Fixes are asked for as private patch series so nothing leaks through a public branch. Time disclosure to the patched gem release across the supported lines, and account for merchants who pin a Spree version inside their own Rails application and upgrade on their own schedule. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability