On 9 November 2026 PrestaShop published two security releases on the same day: 9.2.1 closes eighteen security advisories, 8.2.9 closes fifteen. Both are fix-only releases with no new features.
Some of the fixes stop an attacker from running code on the server without logging in. Others cost money directly: one cart could turn into two orders, and a voucher could be redeemed past its usage limit. This article goes through what each fix prevents, which branch is affected, and what to do when upgrading has to wait.
Not a technical readerThe short version: what happened, and what to do
PrestaShop fixed a set of flaws that let outsiders reach the back office, customer data or the server itself. The fixes ship in two new versions: 9.2.1 for the 9 branch and 8.2.9 for the 8.2 branch.
The fixes arrive with a shop upgrade. The upgrade itself is short, but the theme and the modules have to be tested afterwards, so it is usually done by whoever maintains the shop.
What to do: ask the person maintaining the shop which version is running and when the fixes go live. With nobody maintaining it, the text below can be forwarded as it is.
Questions for whoever maintains the shop
Which PrestaShop version is running on the shop? Is the security release of 9 November 2026 (9.2.1 or 8.2.9) installed, and if not, when will it be? If upgrading is not possible right now, what interim fix is there? Does the shop use webservice keys, and if so, which shops is each key allowed on?
What do 9.2.1 and 8.2.9 fix?
9.2.1 closes eighteen advisories, 8.2.9 closes fifteen. Most fixes landed in both branches. Three are specific to the 9 branch, because they concern its Admin API and its debug-mode setting.
| Fix | What it allowed | Severity | Branch |
|---|---|---|---|
| Admin API: granting yourself any scope GHSA-p292-3rh4-vm4p | an API client with api_client_write could grant itself any scope, which leads to code execution | 8.8 | 9 only |
| SVG upload in the file manager and the logo uploader GHSA-99cp-c6mm-p7h5 | code embedded in an uploaded SVG ran inside the back office (stored XSS) | 8.7 | 8 and 9 |
| Attachments: escaping the download folder GHSA-wrmc-gmx5-9hhc | files outside the folder could be read and deleted | 8.5 | 8 and 9 |
| Installer: object injection in the session cookie GHSA-h2q4-7fp7-m5jp | code execution on the server without any login | 8.1 | 8 and 9 |
| Installer re-run GHSA-8rxw-79mh-gmm5 | the configuration of an already installed shop could be overwritten | 8.1 | 8 and 9 |
| Webservice: taking over another shop's customer CVE-2026-71519 | a key issued for one shop reached a customer record of another | 8.1 | 8 and 9 |
Webservice: id_shop=allCVE-2026-71531 | a key read data beyond the shops it was allowed on | 8.1 | 8 and 9 |
| Debug-mode cookie fields GHSA-95f5-jc9c-gg3q | an employee holding only the Performance permission could run PHP code | 7.2 | 9 only |
| Translations page, theme and module import, email translations GHSA-fxq4-2mc8-99pr, GHSA-7q68-ch46-pxmc, GHSA-95w6-v2wq-cv8w, GHSA-5p6p-mx64-96jf | a logged-in administrator could write files outside the target folder, which leads to code execution | 7.2 | 8 and 9 |
| Two orders from one cart GHSA-2676-hc74-gg7v | a race condition turned the same cart into two orders | 7.5 | 8 and 9 |
| Voucher limit bypass GHSA-r246-6gw4-pj3p | a voucher could be redeemed beyond its usage limit | 7.5 | 8 and 9 |
| Admin API disable had no effect GHSA-6c2j-pgwm-95m9 | disabling an API client and revoking its access token did not take hold | 7.1 | 9 only |
| Customization file download GHSA-fg9q-mm4c-h5xc | a file uploaded by a customer could be fetched with the order reference, without logging in | 5.9 | 8 and 9 |
| Password reset token GHSA-g6p7-cx52-hcrj | the token was predictable and allowed an account takeover | 4.8 | 8 and 9 |
Severity is the CVSS score from PrestaShop's own advisories, on a 0-10 scale. Both releases also update the psgdpr module to 1.4.4 and the newsletter module to 3.0.1.
Which fixes affect orders and revenue?
Two of the fixes are not about break-ins at all, they are about how checkout behaves. One of them stops the same cart from becoming two orders under a race condition. In practice that means an order invoiced twice and shipped twice, with stock levels and invoice numbering drifting apart.
The other concerns voucher usage limits: during a race condition in order validation, a voucher could be redeemed past the number of uses set for it. A generous, single-use voucher could therefore be used many times over.
If duplicate orders or an unexpectedly popular voucher have shown up before, the order history is worth reviewing even before the upgrade: the fix prevents new cases, it does not undo the orders already created.
What should multistore setups watch for?
Two fixes target installations that serve several shops from one codebase. Both concern the webservice API, the interface external systems such as invoicing or warehouse software use to reach the shop.
CVE-2026-71519 describes a key issued for one shop reaching a customer record belonging to another, because the shop check was missing at record level. CVE-2026-71531 allowed a request carrying id_shop=all or id_shop_group to step outside the set of shops the key was granted.
Where one installation serves several brands or several countries and external partners hold keys, the keys themselves are worth reviewing after the upgrade: which shops each key covers, and which resources it can reach.
What if upgrading has to wait?
An upgrade touches the theme and the modules, so on many shops it cannot be done the same day. 8.2.9 belongs to the 8.2 branch; no release appeared for the 8.0 and 8.1 branches on that day, nor for older 1.7 shops.
In that case the fixes can be carried into the running version: the affected files are changed to match the fixed ones and the rest of the shop stays as it is. This is what the PrestaShop security fixes module does, taking a backup first so every fix can be rolled back. Which flaws apply to a given shop is what the PrestaShop security scan module reports.
The lasting answer is still an upgrade to a supported branch, because that is where the next fix arrives on its own.
What to do now
- Check the version in the back office under Advanced Parameters > Information. 9.2.1 on the 9 branch, 8.2.9 on 8.2.
- Upgrade after a test run. The release is fix-only, but the theme and the modules deserve a trial on a copy first.
- Review back-office accounts: who can reach the Performance page and the translations page, and whether any employee account is no longer in use. Several of the fixed flaws assume a logged-in user.
- Review webservice keys: which shops each key covers and whether anyone still uses it.
- If the upgrade has to wait, carry the fixes into the running version, with a backup.
Frequently asked questions
[faq]
Q: How do I find out which PrestaShop version is running?
A: In the back office, under Advanced Parameters > Information. The fixed releases are 9.2.1 on the 9 branch and 8.2.9 on 8.2.
Q: Is updating the modules enough?
A: No. Almost every fix is in PrestaShop's own code; the release additionally updates two modules (psgdpr 1.4.4, newsletter 3.0.1).
Q: How urgent is this?
A: Two of the most severe fixes close flaws that work without logging in, and the advisories are public, so the upgrade should not slip by weeks. The advisories do not report any exploitation.
Q: What about shops on 8.0, 8.1 or 1.7?
A: No release appeared for those branches on that day. The fixes can be carried into the running version instead, with an upgrade to a supported branch as the longer-term plan.
Q: The installation serves several brands. Is anything different?
A: Yes. After the upgrade the webservice keys are worth reviewing, because two of the fixes exist precisely to keep a key inside its own shop.
Sources: PrestaShop 9.2.1 release notes, PrestaShop 8.2.9 release notes, PrestaShop security advisories
