PrestaShop 9.2.1 Fixes Back-Office PHP Code Injection
Tech GuruQuick Answer
Investigate PrestaShop 9.0.0 through 9.2.0. Upgrade to 9.2.1, review Performance-page permissions and configuration changes, and validate storefront and back-office operation.
Confirm Scope And Apply The Supported Remediation
What to do now: Record PrestaShop version, shop instances, employee profiles with Performance permissions, PHP service identity and configuration-file ownership. Match the project range of 9.0.0 or later before 9.2.1. Performance permission is the relevant privilege; the issue does not require permission to install modules or edit employees. Upgrade to PrestaShop 9.2.1. Until the update is deployed, restrict Performance-page permissions to profiles already trusted to execute code on the server, as the project recommends. Verify the installed version, review debug configuration and authorized employee profiles, and test storefront, back-office sign-in and required performance settings. Retain the change record and relevant access/configuration evidence.
Last verified: 2026-11-09 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | PrestaShop back-office Performance debug settings |
|---|---|
| Advisory | GHSA-95f5-jc9c-gg3q / VU#385711 |
| CVE | CVE-2026-124916 |
| Authoritative release date | November 9, 2026; the project provides a calendar publication date. CERT/CC published its corresponding note on the same date. |
| Authority revision date | CERT/CC last revised November 9, 2026. The project page supplies the affected and fixed versions; no separate project revision time is stated. |
| Affected versions | PrestaShop 9.0.0 and later, before 9.2.1. The attack requires a back-office employee with Performance-page permissions; the vulnerable settings write into an executable PHP configuration file. |
| Fixed version | PrestaShop 9.2.1 |
| CVSS base score | 7.2 (CVSS v3.1) |
| CVSS severity | High |
| Exploitation status | Neither retained first-party notice confirms exploitation.; no exploitation claim is inferred. |
What Changed
PrestaShop fixed unescaped debug-cookie name and value fields that could place PHP code in a shop configuration file. An employee with Performance permissions could execute code as the web server user or break both storefront and back-office availability. CERT/CC identifies this issue as CVE-2026-124916.
What To Validate Now
- Inventory. Record PrestaShop version, shop instances, employee profiles with Performance permissions, PHP service identity and configuration-file ownership.
- Establish applicability. Match the project range of 9.0.0 or later before 9.2.1. Performance permission is the relevant privilege; the issue does not require permission to install modules or edit employees.
- Remediate. Upgrade to PrestaShop 9.2.1. Until the update is deployed, restrict Performance-page permissions to profiles already trusted to execute code on the server, as the project recommends.
- Validate. Verify the installed version, review debug configuration and authorized employee profiles, and test storefront, back-office sign-in and required performance settings. Retain the change record and relevant access/configuration evidence.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
Malformed settings can interrupt both public and administrative service. Preserve configuration evidence before repair, keep a tested recovery path and coordinate deployment with the shop owner. A fixed version alone does not establish that earlier unauthorized changes were removed.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
