PrestaShop Debug Mode Flaw Let Back-Office Accounts Inject PHP Into Config Files

CERT/CC published vulnerability note VU#385711 on November 9, 2026, for a PHP code injection flaw in PrestaShop's Debug mode, a back-office convenience meant to help developers diagnose problems. According to a dev.to write-up of the advisory, values entered through the administrative interface can become executable source code that the application loads on later requests. PrestaShop 9.2.1 fixes the issue, and the vendor advisory tracks it as CVE-2026-124916.

How the injection works

Under the Debug mode screen in the Performance section of the back office, an administrator can set a debug cookie name and value. As dev.to explains, PrestaShop embeds both values in a PHP expression and saves the result as a define() statement in config/defines.inc.php or config/defines_custom.inc.php.

The design assumes the two inputs behave as inert strings. The advisory found that the application fails to escape them as PHP source, so a crafted value can terminate the intended string literal and append a PHP statement of the attacker's choosing. Because the modified configuration file is read during initialization, the injected statement slots into the normal request lifecycle of every subsequent request.

What an attacker needs

The flaw is not exploitable by anonymous visitors. Per the advisory as summarized by dev.to, exploitation requires:

• An authenticated back-office account with permission to change Debug mode settings.
• Write access for the PHP process to the configuration file. Root access is not needed.
• CSRF protection offers no defense here: it blocks requests forged through another administrator's browser, not an attacker who already holds an account with the required permission.

What the injected code can reach

Once written, the extra statement runs with the PHP process's privileges, which typically extend to database credentials, application secrets, customer records, uploaded files and writable application code. An attacker could also disrupt checkout or other store operations.

The advisory does not equate PHP code execution with root access, and administrators should not assume otherwise. Whether operating system commands can be executed depends on the PHP configuration and enabled functions; the immediate boundary remains the web application account.

dev.to highlights two reasons this is more than a routine settings bug. An account intended only for store operations can inherit configuration-capable permissions by accident, and shops commonly leave Debug mode switched on after troubleshooting, leaving a development convenience permanently exposed inside the production back office.

Remediation

PrestaShop 9.2.1 addresses the flaw. Administrators should inventory their running version and upgrade affected installations to 9.2.1 or later.

Where an immediate upgrade is not possible, dev.to recommends limiting who can change Performance and Debug mode settings to a small group of trusted administrators, restricting back-office access by network policy where feasible, and, tested carefully first because it may block legitimate configuration changes, removing the PHP process's write access to config/defines.inc.php and config/defines_custom.inc.php.

Administrators should also inspect those files for stray PHP statements near the debug cookie definitions and diff them against a known-good deployment. If any account with configuration rights may have been compromised, application secrets should be rotated, because injected code could have read environment values and application files. dev.to additionally suggests recording the installed version, exposed administration addresses and the set of accounts able to change Performance settings.

Why it matters

The flaw collapses the distance between a back-office settings screen and arbitrary PHP execution, without any memory-corruption exploit — just a permission shops may hand out casually and an unsanitized string written into a file the application later includes. It is also a textbook case of a recurring anti-pattern: treating configuration values as data when they are ultimately emitted as code. Even if exploitation stops at the PHP process boundary, that boundary holds the store's database credentials, customer data and source code. Shops running older versions should treat the 9.2.1 upgrade and a Debug mode permissions audit as one task.