PrestaShop 9.2.1 and 8.2.9 fix unauthenticated PHP object injection and further high-severity flaws

What happened

On 9 November 2026 PrestaShop published ten high-severity security advisories. The most serious is GHSA-h2q4-7fp7-m5jp: when the installer folder remains reachable, an unauthenticated attacker can forge the installer session cookie and trigger PHP object injection, achieving remote code execution as the web server user. A related installer flaw, GHSA-8rxw-79mh-gmm5, allows an unauthenticated visitor to re-run the installer, read the live database credentials, overwrite the shop configuration file, or reinstall the database with an attacker-chosen administrator account.

Several flaws concern the Webservice and Admin APIs. GHSA-3f36-4qv4-vfgh lets a shop-restricted Webservice key act on every shop; GHSA-hjwq-7qvv-qxj4 permits a key associated with one shop to read and change customer records, including password hashes, in any shop. GHSA-wrmc-gmx5-9hhc allows attachment path traversal for file read and deletion outside the download directory, reachable by anyone for download. An Admin API client holding api_client_write can grant itself any installed scope (GHSA-p292-3rh4-vm4p), leading to module upload and code execution.

Back-office flaws include stored cross-site scripting through SVG uploads and arbitrary file write through email translations, which can lead to remote code execution. Two race conditions allow duplicate orders from a single cart and bypass cart rule usage limits. PrestaShop has not reported any of these flaws as exploited in the wild, and none were publicly disclosed before the advisories.

Who is affected

PrestaShop 9.0.0 to before 9.2.1 and 8.0.0 to before 8.2.9 are affected by the majority of these advisories. GHSA-p292-3rh4-vm4p affects only 9.0.0 to before 9.2.1. GHSA-8rxw-79mh-gmm5 lists versions before 8.2.9, as well as 9.0.0 to before 9.2.1; since 9.2.0 the installer folder is removed automatically after a successful installation, so exposure is mainly where that removal failed and on 8.x shops where the folder was not deleted by hand.

What to do now

1. Upgrade to the fixed releases: PrestaShop 9.2.1 for shops on the 9.x branch, or PrestaShop 8.2.9 for shops on earlier 8.x versions. GHSA-p292-3rh4-vm4p is fixed only in 9.2.1.
2. Delete the install folder from the server once the shop is installed. If it is still present, do this immediately; it addresses the two unauthenticated installer flaws.
3. Review the Webservice API. Disable it if it is unused. Until upgrading, treat any shop-restricted key as valid for every shop; do not give attachment write permission to untrusted keys; only give customer permissions to fully trusted integrations.
4. Review Admin API clients holding api_client_write. Keep that scope only on clients trusted with every installed scope, and delete unnecessary API clients.
5. Restrict back-office permissions: file manager and logo upload rights should be limited to fully trusted employees; the Translations edit permission should be limited the same way.
6. There is no workaround for the two checkout race conditions; upgrading is the only mitigation.

How to detect it

Check whether the install folder is reachable on your shop; remove it regardless. Review Webservice and Admin API client scopes for keys with more permissions than needed, and audit back-office accounts that can upload files or edit translations. For the email translations path traversal, look for unexpected files in directories writable by the web server user.

Beyond the patch

These advisories show how self-hosted e-commerce can leave more exposed than the storefront: a leftover installer folder, over-permissioned API keys, and race conditions in checkout logic. The most serious flaws are reachable over the network without credentials when an install folder remains, which is exactly the kind of exposure Virtual CISO Services (vCISO) can help you find; Implementation & Assessment Services can test for injection, deserialisation and authentication flaws before they become an advisory. Where any of this has been abused, Managed Detection & Response (MDR) detects the code execution and privilege abuse that follows.