CVE-2026-124916: remote code execution in PrestaShop — debug_cookie_name and debug_cookie_value in Performance settings

If you run a PrestaShop store, there is a big difference between running older software and being exposed to a particular vulnerability. CVE-2026-124916 concerns debug_cookie_name and debug_cookie_value in Performance settings. Here is what was reported, which technical conditions matter and how to fix the issue without turning a maintenance task into a production incident.

What happened?

An employee with Performance permissions could inject PHP into generated configuration through debug-cookie fields.

The issue was reported in functionality associated with the PrestaShop application. Whether the entry point is reachable, the required privileges and local configuration can significantly change exposure.

The technical details: how this vulnerability works

Server-side code execution is different from browser-side JavaScript. The problem is that the PHP process can be made to interpret instructions under an attacker's influence. Depending on the vulnerability, the path may involve an executable upload, unsafe deserialization, dynamic evaluation, imported archives or generated configuration files.

Execution normally happens under the PHP-FPM or Apache account, not automatically as root. That can still expose configuration secrets, shop files, sessions and database access. Least privilege and isolation reduce the blast radius, but patching remains essential.

The debug_cookie_name and debug_cookie_value fields from the Performance page were written to a PHP configuration file without proper neutralization. An employee allowed to change performance settings could therefore execute server-side PHP, escalating far beyond their intended permissions. This affects PrestaShop 9 and was fixed in 9.2.1. Restrict access to Performance settings until the update is deployed.

What is the real impact?

Under the relevant conditions, the issue may allow access to application files and data and execution under the PHP process account. That does not establish that a store has been compromised, nor does it mean every installation is exploitable in the same way. Severity in practice depends on versions, configuration, authentication requirements and server privileges.

Also distinguish a vulnerability in the PrestaShop core from a vulnerability in a third-party module. The presence of a vulnerable extension is not implied merely by using PrestaShop.

Which versions are affected?

• Component: debug_cookie_name and debug_cookie_value in Performance settings
• Reported affected versions: 9.0 before 9.2.1
• Fixed version: 9.2.1
• Advisory publication: 2026-11-09

Treat this as an initial assessment. Custom overrides, local patches and modified distributions mean the back-office version number might not describe every file currently deployed.

How do you fix CVE-2026-124916?

1. Inventory the installation. Record the PrestaShop version, module version where applicable and PHP environment. Confirm whether debug_cookie_name and debug_cookie_value in Performance settings is present.
2. Check affected versions. The record lists 9.0 before 9.2.1. Verify these details against the maintainer's notice because configuration requirements can narrow exposure.
3. Create a full backup. Include files, database and configuration, and test the change in staging whenever possible.
4. Apply the remediation. The documented patched version is 9.2.1. If you run a newer branch, verify that its release includes the fix and that any involved modules are also current.
5. Regression-test critical workflows. Check login, cart, checkout, customer area, back office, email and store integrations.
6. Review prior exposure. A successful patch does not by itself establish whether the issue was previously exploited.

How can I check for exploitation attempts?

Review HTTP and PHP logs, file changes and unusual processes during the exposure window. Compare modules/, themes/ and upload directories with a known-clean deployment. Preserve evidence before deleting suspected files if a compromise is plausible.

Cloudflare or another WAF may reduce some exploit attempts, but it does not patch vulnerable application code.

Developer review checklist

Start code review at the affected component above. Trace input from HTTP (Tools::getValue(), AJAX handlers, uploads or headers) into the sensitive operation and confirm server-side validation at that boundary. Also check custom overrides and in-house modules so the same unsafe pattern is not reintroduced after installing the official patch.

Want someone to handle the update?

A safe remediation is more than clicking an update button. Dependencies need reviewing, rollback must be possible, the right patch must be deployed and key business flows should continue working.

Would you like me to review and fix this vulnerability in your PrestaShop store? I can inspect your versions and modules, assess exposure, apply the appropriate security changes and regression-test key workflows. Get in touch and we can handle it calmly, without unnecessary alarm.

Editorial note: this article summarizes publicly available information and does not prove your shop was exploited. Whenever a patched version could not be verified, that limitation is explicitly stated.