Skip to content

Saleor bug bounty programs

saleor.io Updated

Saleor runs one public program: a Sorona bug bounty paying up to $1,500.

Top reward
$1,500
Sorona
Programs
1
1 pays cash
Targets in scope
13
2 types
Last change
None yet
Tracked since Nov 2026

Where to report

The one public program Saleor runs.

Amounts are the top reward per severity in the currency each program pays. First response is the platform's measured average when it publishes one, else what the policy promises.

What is in scope

13 targets. 6 excluded.

  • https://saleor.io

    Web

  • Authentication and token handling: JWT issuance, refresh tokens, the external authentication plugins and any impersonation feature

    Products and areas

  • Payment orchestration, including the transaction API, payment gateway plugins and the webhook path a gateway uses to report a completed payment

    Products and areas

  • Product, media and file upload handling

    Products and areas

  • Public and private metadata on every object, the mechanism most often used to hang internal data off a customer-visible entity

    Products and areas

  • The anonymous storefront surface, the queries a visitor with no account can reach at all

    Products and areas

  • The app framework and its webhook signing, where a third-party application receives events and holds a token against the API

    Products and areas

  • The checkout flow end to end: line pricing, discounts, vouchers, gift cards, shipping method selection and tax calculation

    Products and areas

  • The GraphQL API in full: every query, every mutation and every subscription, along with the permission check applied to each

    Products and areas

  • The multi-channel model, where one Saleor instance serves several storefronts with separate pricing, availability and currency

    Products and areas

  • The permission model itself, covering staff permission groups, app tokens, the customer and staff boundary and the per-channel restrictions layered on top

    Products and areas

  • 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

    Products and areas

  • The staff dashboard's use of the API, and every operation it performs on a staff user's behalf

    Products and areas

No target matches. Try part of a host name, such as the company name.

Out of scope 6

Don't test these. A program can exclude a host another program covers; the program you report to decides.

  • 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

Recent changes

Reward and scope changes across every Saleor program, newest first.

No changes recorded yet. New targets and reward moves show up here and in the RSS feed.

Recent CVEs

Published vulnerabilities in Saleor products, from the NVD.

Search NVD
  • 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.

  • 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.

  • 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

  • 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

  • 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,

  • 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

  • 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

  • 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

About this page

This page gathers every public program listed under saleor.io: platform programs, self-hosted policies and security.txt contacts. Each program's own policy decides what is in scope and what it pays; check it before you test.

Something wrong or missing? Report a correction.