News · · 6 min read
PrestaShop 9.2.1 and 8.2.9: what the 18 security fixes mean for your store
PrestaShop 9.2.1 and 8.2.9 fix 18 security issues, 15 rated high. Which version to move to, what to do if you cannot update today, and what we hit updating.
On 9 November 2026 PrestaShop released 9.2.1 and 8.2.9. Both are security releases: together they fix 18 issues, and PrestaShop rates 15 of them high. Several lead to code running on the server, and a few can be used by someone who has no account in the store at all.
In short: update. A 9.x store goes to 9.2.1 and an 8.x store goes to 8.2.9. A 1.7 store gets no fix. If you cannot update this week, first check that the install folder is gone from your server. That one step closes the two worst issues.
What was fixed, in three groups
All details below come from PrestaShop's security advisories on GitHub. Each one lists the affected versions as 8.0 to 8.2.8 and 9.0 to 9.2.0, except three that exist only in PrestaShop 9.
Anyone on the internet, no account needed
| Issue | Who is exposed |
|---|---|
| Code execution through a forged installer cookie | Stores where the install folder is still on the server |
| The installer can be run again on a live store: read the database password, overwrite the configuration or reinstall with the attacker's own admin account | Same: stores with the install folder still there |
| Several orders from one cart with a zero total, by sending the confirmation at the same moment | Stores that accept free orders, for example with a 100% voucher |
| A single-use or limited voucher redeemed several times by checking out in parallel | Stores with vouchers that have a usage limit |
| A file another customer uploaded to personalise a product (often a photo or a document) can be downloaded with the order reference | Stores with product customisation by file upload |
| The password reset token could be calculated | Needs the customer's id and secret key, so it is hard to use on its own |
The two installer issues are the most serious. Since 9.2.0 PrestaShop deletes the install folder after a successful installation. On PrestaShop 8 you had to delete it by hand, so the advisory names 8.x stores where nobody did, and 9.x stores where the automatic removal failed. Open https://your-store/install/ in a browser. If you get anything other than a "not found" page, delete the folder today.
API keys and integrations
| Issue | Versions |
|---|---|
| A Webservice key limited to one shop of a multistore could read and change customers of every shop, including taking over their accounts | 8 and 9 |
| The same key could also reach every shop's data by asking for "all shops" or a shop group | 8 and 9 |
| A Webservice key that may write attachments could point a file at the shop configuration, which anyone could then download | 8 and 9 |
| An Admin API client allowed to manage API clients could give itself any permission, up to installing a module | 9 only |
| Disabling an Admin API client did not stop it: its tokens kept working | 9 only |
These need a key or client that someone already has, such as an old integration, a former agency or a leaked file. A store that does not use the Webservice or the Admin API is not exposed to this group.
Back-office staff with limited rights
Seven issues let an employee do more than their profile allows, mostly run code on the server:
- importing a theme from a URL;
- importing a theme or module archive built to write outside its folder;
- the module parameter of the back-office translations page;
- saving email translations;
- the debug mode cookie fields on the Performance page (9 only);
- SVG files uploaded through the file manager or as the logo, which run a script when an administrator opens them;
- an employee who may only create orders could change existing ones.
This matters most for stores where agencies, freelancers or several staff members have back-office accounts. A store run by one person who is the only administrator is far less exposed to this group.
Which version to move to
| Your store | Move to | Notes |
|---|---|---|
| 9.0.x, 9.1.x, 9.2.0 | 9.2.1 | There is no 9.1.6 or 9.0.x fix. Even from 9.1 the way is 9.2.1. |
| 8.0.x to 8.2.8 | 8.2.9 | Officially still on PHP up to 8.1. |
| 1.7 or older | Upgrade | 1.7 gets no fixes at all. See PrestaShop 1.7 end of life and Upgrading to PrestaShop 9. |
PrestaShop names 8.0 as the first affected version for most issues because 1.7 is no longer looked at. The installer re-run issue is listed for every version before 8.2.9. A 1.7 store that still has its install folder should delete it now, whatever its upgrade plans.
Not sure which version a store runs? The version check tells you from the outside in a few seconds.
If you cannot update today
- Delete the
installfolder and check that/install/returns "not found". This closes the two unauthenticated code execution issues. - Turn off the Webservice (Advanced Parameters > Webservice) if nothing uses it. If something does, delete the keys you do not recognise and keep only the permissions each key needs.
- On PrestaShop 9, delete Admin API clients you do not use. Disabling one is not enough until you update.
- Review employee profiles. Only people you would trust with the server should be allowed to import themes or modules, edit translations, change the Performance page or upload files.
- Watch free orders and limited vouchers. There is no workaround for the two checkout race conditions. Until you update, check new orders for duplicates and vouchers used more often than allowed.
What we ran into updating our own store
We updated our live PrestaShop 9 demo from 9.1.5 to 9.2.1 the day after the release, with the official Update Assistant (version 7.6.6) from the command line. The update itself replaced about 37,000 files and took around a quarter of an hour. Three things are worth knowing before you start:
- Check the module list before you click. Update Assistant reads each module's declared compatibility from PrestaShop Addons. A module whose listing still says "up to 9.1.5" is marked incompatible with 9.2.1, even if it works fine. If the option to uninstall incompatible modules is on, it is uninstalled, and its settings and data go with it. We turned the option off, and the module kept working on 9.2.1.
- Shared hosting often disables
exec()andsystem(). From the command line, Update Assistant uses them to chain its steps and to warm up the cache. On such a server the database step stopped withCall to undefined function ... exec(), after the files had already been replaced, and the shop answered with an error 500 until we finished the step by hand. On hosting like this, run the update from the back office instead, or ask your host before you start. - Core files you edited are overwritten. We keep a short script that puts our few changes back after every update. Without a list like that, small fixes made years ago disappear without anyone noticing.
Make a full backup of the files and the database first, and keep it until you have tested the checkout. If the update breaks something, our list of common PrestaShop 9 upgrade errors covers the usual causes.
Check a store in a few seconds
Our free PrestaShop security check already knows these 18 advisories. It reads the PrestaShop version where the store shows it, lists the modules with published advisories, and says what to update.
Or hand it over: we update the store on a copy first, test the checkout, the payment and the emails, and switch over when everything works, for a fixed price agreed before any work. Ask for a price.