- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 16
- 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.
- 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 |
- 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://saleor.io
Products and areas 12
- Authentication and token handling: JWT issuance, refresh tokens, the external authentication plugins and any impersonation feature
- Payment orchestration, including the transaction API, payment gateway plugins and the webhook path a gateway uses to report a completed payment
- Product, media and file upload handling
- Public and private metadata on every object, the mechanism most often used to hang internal data off a customer-visible entity
- The anonymous storefront surface, the queries a visitor with no account can reach at all
- The app framework and its webhook signing, where a third-party application receives events and holds a token against the API
- The checkout flow end to end: line pricing, discounts, vouchers, gift cards, shipping method selection and tax calculation
- The GraphQL API in full: every query, every mutation and every subscription, along with the permission check applied to each
- The multi-channel model, where one Saleor instance serves several storefronts with separate pricing, availability and currency
- The permission model itself, covering staff permission groups, app tokens, the customer and staff boundary and the per-channel restrictions layered on top
- The policy takes private reports on Saleor through GitHub or a dedicated address and states no component carve-out beyond its own reporting requirements, so the whole backend is in scope
- The staff dashboard's use of the API, and every operation it performs on a staff user's behalf
Out of scope (6)
- AI-generated submissions without a verified reproduction, which the policy rules out by name
- Deployment configuration, including an instance run with debug enabled or with the dashboard exposed against the documentation's advice
- Payment gateway providers' own systems, which are separate estates
- Storefront code a merchant writes themselves, which is their application rather than Saleor
- Third-party Saleor apps and plugins maintained outside the repository
- Upstream Python and Django dependency issues, unless Saleor'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 through a GitHub private security advisory on saleor/saleor, which is enabled, or by email to the address on the policy page
-
The policy lists what a report must contain. A submission missing those parts gets bounced, so work through the list before sending
-
The policy rejects AI-generated reports explicitly. Send a verified reproduction against a current release, not a model's writeup of a scanner result
-
Give the exact GraphQL operation, the permissions your token held and the channel you operated in. Saleor's authorisation is per-permission and per-channel, so a report without that cannot be reproduced
-
Say whether you reproduced against the open-source Saleor core or against Saleor Cloud, since the hosted service adds surface the repository does not carry
-
There is no reward tier and no payment to negotiate
Not accepted
-
AI-generated submissions without a verified reproduction
-
Upstream Python and Django dependency issues, unless Saleor's own use of the dependency is what makes the defect reachable
-
Deployment configuration, including an instance run with debug enabled or with the dashboard exposed against the documentation's advice
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-39851 | Saleor is an e-commerce platform. From 2.10.0 to before 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118, the requestEmailChange() mutation was revealing the existence of user-provided email addresses in error messages. This vulnerability is fixed in 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118. | Medium 5.3 | 8 Apr 2026 |
| CVE-2026-35401 | Saleor is an e-commerce platform. From 2.0.0 to before 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118, a malicious actor can include many GraphQL mutations or queries in a single API call using aliases or chaining multiple mutations, resulting in resource exhaustion. This vulnerability is fixed in 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118. | High 7.5 | 8 Apr 2026 |
| CVE-2026-35407 | Saleor is an e-commerce platform. From 2.10.0 to before 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118, a business-logic and authorization flaw was found in the account email change workflow, the confirmation flow did not verify that the email change confirmation token was issued for the given authenticated user. As a result, a valid email-change token generated for one account can be replayed while aut | Medium 5.9 | 8 Apr 2026 |
| CVE-2026-33756 | Saleor is an e-commerce platform. From 2.0.0 to before 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118, Saleor supports query batching by submitting multiple GraphQL operations in a single HTTP request as a JSON array but wasn't enforcing any upper limit on the number of operations. This allowed an unauthenticated attacker to send a single HTTP request many operations (bypassing the per query complexity | High 7.5 | 8 Apr 2026 |
| CVE-2026-24136 | Saleor is an e-commerce platform. Versions 3.2.0 through 3.20.109, 3.21.0-a.0 through 3.21.44 and 3.22.0-a.0 through 3.22.28 have a n Insecure Direct Object Reference (IDOR) vulnerability that allows unauthenticated actors to extract sensitive information in plain text. Orders created before Saleor 3.2.0 could have PIIs exfiltrated. The issue has been patched in Saleor versions: 3.22.29, 3.21.45, | High 8.7 | 24 Jan 2026 |
| CVE-2026-22849 | Saleor is an e-commerce platform. Starting in version 3.0.0 and prior to versions 3.20.108, 3.21.43, and 3.22.27, Saleor was allowing users to modify rich text fields with HTML without running any backend HTML cleaners thus allowing malicious actors to perform stored XSS attacks on dashboards and storefronts. Malicious staff members could craft script injections to target other staff members, poss | High 7.2 | 21 Jan 2026 |
| CVE-2026-23499 | Saleor is an e-commerce platform. Starting in version 3.0.0 and prior to versions 3.20.108, 3.21.43, and 3.22.27, Saleor allowed authenticated staff users or Apps to upload arbitrary files, including malicious HTML and SVG files containing Javascript. Depending on the deployment strategy, these files may be served from the same domain as the dashboard without any restrictions leading to the execut | High 8.5 | 21 Jan 2026 |
| CVE-2024-31205 | Saleor is an e-commerce platform. Starting in version 3.10.0 and prior to versions 3.14.64, 3.15.39, 3.16.39, 3.17.35, 3.18.31, and 3.19.19, an attacker may bypass cross-set request forgery (CSRF) validation when calling refresh token mutation with empty string. When a user provides an empty string in `refreshToken` mutation, while the token persists in `JWT_REFRESH_TOKEN_COOKIE_NAME` cookie, appl | Medium 4.2 | 8 Apr 2024 |
| CVE-2024-29888 | Saleor is an e-commerce platform that serves high-volume companies. When using `Pickup: Local stock only` click-and-collect as a delivery method in specific conditions the customer could overwrite the warehouse address with its own, which exposes its address as click-and-collect address. This issue has been patched in versions: `3.14.61`, `3.15.37`, `3.16.34`, `3.17.32`, `3.18.28`, `3.19.15`. | Medium 4.2 | 27 Mar 2024 |
| CVE-2024-29036 | Saleor Storefront is software for building e-commerce experiences. Prior to commit 579241e75a5eb332ccf26e0bcdd54befa33f4783, when any user authenticates in the storefront, anonymous users are able to access their data. The session is leaked through cache and can be accessed by anyone. Users should upgrade to a version that incorporates commit 579241e75a5eb332ccf26e0bcdd54befa33f4783 or later to re | Medium 4.3 | 20 Mar 2024 |
| CVE-2023-3294 | Cross-site Scripting (XSS) - DOM in GitHub repository saleor/react-storefront prior to c29aab226f07ca980cc19787dcef101e11b83ef7. | Medium 6.1 | 16 Jun 2023 |
| CVE-2023-32694 | Saleor Core is a composable, headless commerce API. Saleor's `validate_hmac_signature` function is vulnerable to timing attacks. Malicious users could abuse this vulnerability on Saleor deployments having the Adyen plugin enabled in order to determine the secret key and forge fake events, this could affect the database integrity such as marking an order as paid when it is not. This issue has been | Medium 4.8 | 25 May 2023 |
| CVE-2023-26051 | Saleor is a headless, GraphQL commerce platform delivering personalized shopping experiences. Some internal Python exceptions are not handled properly and thus are returned in API as error messages. Some messages might contain sensitive information like user email address in staff-authenticated requests. | Medium 6.5 | 2 Mar 2023 |
| CVE-2023-26052 | Saleor is a headless, GraphQL commerce platform delivering personalized shopping experiences. Some internal Python exceptions are not handled properly and thus are returned in API as error messages. Some messages might contain sensitive information like infrastructure details in unauthenticated requests. This issue has been patched in versions 3.1.48, 3.7.59, 3.8.0, 3.9.27, 3.10.14 and 3.11.12. | Low 3.7 | 2 Mar 2023 |
| CVE-2022-39275 | Saleor is a headless, GraphQL commerce platform. In affected versions some GraphQL mutations were not properly checking the ID type input which allowed to access database objects that the authenticated user may not be allowed to access. This vulnerability can be used to expose the following information: Estimating database row counts from tables with a sequential primary key or Exposing staff user | Medium 5.3 | 6 Oct 2022 |
| CVE-2022-0932 | Missing Authorization in GitHub repository saleor/saleor prior to 3.1.2. | Medium 6.5 | 11 Mar 2022 |
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 10 Last 12 months 16 Lifetime Access control 38 % Info disclosure 24 % Business logic 22 % Auth/token handling 16 % Latest advisories Loading the feed Overview Saleor is a Python and GraphQL commerce backend used by enterprise retail as the order and checkout engine behind a storefront built separately. Everything reaches it through one GraphQL endpoint, so the authorisation decision for every query and mutation is made in a single layer and a permission gap there is reachable from the open internet. Checkout and payment orchestration run through that same API. The project publishes a dedicated section stating it has no bounty programme and cannot offer monetary rewards for anything reported, and ten of its sixteen published advisories arrived in the last twelve months. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy takes private reports on Saleor through GitHub or a dedicated address and states no component carve-out beyond its own reporting requirements, so the whole backend is in scope The GraphQL API in full: every query, every mutation and every subscription, along with the permission check applied to each The permission model itself, covering staff permission groups, app tokens, the customer and staff boundary and the per-channel restrictions layered on top The checkout flow end to end: line pricing, discounts, vouchers, gift cards, shipping method selection and tax calculation Payment orchestration, including the transaction API, payment gateway plugins and the webhook path a gateway uses to report a completed payment The app framework and its webhook signing, where a third-party application receives events and holds a token against the API Authentication and token handling: JWT issuance, refresh tokens, the external authentication plugins and any impersonation feature The multi-channel model, where one Saleor instance serves several storefronts with separate pricing, availability and currency Public and private metadata on every object, the mechanism most often used to hang internal data off a customer-visible entity Product, media and file upload handling The staff dashboard's use of the API, and every operation it performs on a staff user's behalf The anonymous storefront surface, the queries a visitor with no account can reach at all Out of scope Storefront code a merchant writes themselves, which is their application rather than Saleor Third-party Saleor apps and plugins maintained outside the repository Payment gateway providers' own systems, which are separate estates Upstream Python and Django dependency issues, unless Saleor's own use of the dependency is what makes the defect reachable Deployment configuration, including an instance run with debug enabled or with the dashboard exposed against the documentation's advice AI-generated submissions without a verified reproduction, which the policy rules out by name Most-valued findings Permission checks applied in the resolver rather than uniformly, so one query or mutation returns data a token was never granted. On a single-endpoint API this is the densest class by far and the whole product funnels through it Anything reachable from the anonymous storefront surface that returns staff data, another customer's order or an internal object Private metadata leaking into a customer-visible query, which is the most common way commercial detail escapes on this architecture Checkout total manipulation through vouchers, gift cards, discounts, shipping or tax, where a mutation sequence produces a paid order for less than the goods are worth Payment webhook and transaction API forgery that marks an order paid without a genuine gateway response App token scope defects, where an installed application acts beyond the permissions it was granted Cross-channel access, where a token scoped to one channel reads or writes another channel's pricing, orders or customers JWT and refresh token handling, including signature validation, expiry and any path that issues a staff token to a customer GraphQL-specific abuse that reaches data rather than just load: introspection revealing restricted fields, aliasing and batching around a per-operation check, and deeply nested queries that pull related objects past their permission boundary Unauthorised retrieval of customer records or order history through an unchecked identifier 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 through a GitHub private security advisory on saleor/saleor, which is enabled, or by email to [email protected] The policy lists what a report must contain. A submission missing those parts gets bounced, so work through the list before sending The policy rejects AI-generated reports explicitly. Send a verified reproduction against a current release, not a model's writeup of a scanner result Give the exact GraphQL operation, the permissions your token held and the channel you operated in. Saleor's authorisation is per-permission and per-channel, so a report without that cannot be reproduced Say whether you reproduced against the open-source Saleor core or against Saleor Cloud, since the hosted service adds surface the repository does not carry There is no reward tier and no payment to negotiate Disclosure Coordinated privately through a GitHub advisory or the security address, and published as a GitHub Security Advisory once a fix ships. The policy is well developed for a project this size, with a required-contents list and stated expectations on both sides. No fixed embargo length is published. Time disclosure to the release carrying the fix, and remember that Saleor deployments are usually pinned inside a merchant's own infrastructure, so the exposure window outlasts the advisory. 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