PrestaShop

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 Separately, for a merged upstream patch : up to $15,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. PrestaShop sits in Tier 1, where a secure-by-design memory-safety change can carry a 2x multiplier until the end of 2026; the figure here is the un-multiplied one. Patches must be between one and twelve months old, the maintainers hold a veto, the panel may split the award with them, and it is rate-limited to three submissions a month. Sanctions and territory exclusions apply. CVE history 5 Last 12 months 56 Lifetime Injection 28 % XSS 24 % Access control 24 % Info disclosure 19 % Latest advisories Loading the feed Overview PrestaShop is an open-source e-commerce platform running hundreds of thousands of shops. Everything a storefront touches runs through this code: customer accounts and addresses, order records and the back office a merchant signs into. Injection, cross-site scripting and access-control defects together make up more than three quarters of its recorded history, and a defect here reaches every shop that takes the next release. Google names the repository by URL in the Patch Rewards Tier 1 scope table under 'Popular CMS platforms', alongside WordPress and Magento. The project itself pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to the PrestaShop security team at [email protected] , and the boundary is the core repository Google names by URL in the Tier 1 scope row, github.com/PrestaShop/PrestaShop. Third-party modules and themes belong to their own authors The customer-facing storefront in full, covering every request parameter it accepts, every page it renders and the customer account and address handling behind them The merchant back office in full, including administrator authentication, session handling and every controller behind them The database access layer and anything that composes a query from storefront or back-office request data The template layer and its escaping, wherever untrusted content reaches a rendered page in either interface Order records, customer data and shop configuration, and every path that reads, exports or exposes them Systematic removal of error-prone patterns across the code that handles untrusted request data, and contextual auto-escaping in the template layer, both named qualifying-patch categories on this program Out of scope A vulnerability report on its own where the patch money is concerned: that rail pays only on a change merged upstream that then survives a month without reverts One-liner patches that fix non-exploitable crashes, and denial of service by resource exhaustion, which the rules exclude by name Patches the PrestaShop maintainers decline, since Google explicitly declines to second-guess a maintainer's decision Patches older than twelve months or newer than one month at the moment of submission, and anything past three submissions per person per month Third-party modules and themes, which are not the repository named in the Tier 1 scope row and are maintained by their own authors Configuration mistakes in somebody else's PrestaShop deployment rather than a defect in the shipped code Most-valued findings Injection that reaches the shop database or the host from an unauthenticated storefront request, the largest single class in the recorded history at 28 percent and the one that puts customer and order data directly at risk A structural fix that closes a whole family of injection sites at once rather than a single call site. The panel's top band is reserved for changes that almost certainly prevent major vulnerabilities rather than for point fixes Authorization bypass that reaches the back office, which turns an anonymous shop visitor into a merchant administrator on every installation. Access-control defects are 24 percent of the record Stored cross-site scripting in the merchant back office, where the payload executes with an administrator's session rather than a customer's. Cross-site scripting is 24 percent of the record Information disclosure that exposes order records, customer data or shop configuration to a party that was never meant to see it, 19 percent of the record Contextual auto-escaping across the template layer, a named qualifying-patch category that removes an entire XSS class instead of one instance of it 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. Send a detailed, reproducible report; if we can't reproduce it, it isn't eligible Give the PrestaShop security team room to ship a fix before any public writeup One vulnerability per report unless a chain is needed to show the real impact Findings that live in a third-party module or theme belong with that author, not in the repository Google names in the Tier 1 scope row If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month; that is a separate pathway with its own rules, its own one-to-twelve-month age window and a cap of three submissions a month Disclosure Coordinated with the PrestaShop security team at [email protected] . Routing works here: the Patch Rewards rules contain no confidentiality, embargo or third-party clause, only sanctions and territory limits, and the patch money is claimed on a change that is already public by the time you claim it. Hold the detail until the project has shipped a fix. 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