Critical PHP vulnerabilities (php2shell): what PrestaShop merchants need to know

On October 21, 2026, the PHP Security Team released updates fixing two critical vulnerabilities in PHP itself, both rated CVSS 9.2. This is a PHP vulnerability, not a PrestaShop vulnerability. Because PrestaShop runs on PHP, virtually every PrestaShop store is concerned, as are most PHP websites (WordPress, Magento, Drupal and many more).

PrestaShop is open source software installed on the hosting of your choice, and we do not have access to your server. The fix is a PHP update, applied by whoever manages your server: usually your hosting provider. This article explains what to check and what to ask.

! In short Make sure your store's server runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later), or a patched package from your Linux distribution or hosting provider. Contact your hosting provider today and ask for written confirmation. Updating PrestaShop or your modules will not fix this vulnerability.

1. Understanding the vulnerability

On October 20, the PHP project gave advance notice of a security release. The fixes were published on October 21 at 14:00 UTC, with an official security advisory.

The two vulnerabilities, nicknamed php2shell by the researchers who reported them (Calif.io, Wiz, OpenAl and Quarkslab), are:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): when PHP runs out of memory, it can be interrupted while internal request data is only partially initialized. The cleanup that follows may then treat that incomplete data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): some internal state belonging to a request can survive after its memory has been freed. A later request handled by the same PHP worker may then use that stale state.

In plain words, both are memory-handling flaws in the PHP engine. With specially crafted HTTP requests, an attacker could crash PHP, expose sensitive data or, in the worst case, run their own code on the server without any authentication.

All PHP installations serving web requests are at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php.

2. A PHP vulnerability, not a PrestaShop vulnerability

These vulnerabilities are not in PrestaShop, nor in any PrestaShop module. They are in the PHP runtime that executes PrestaShop, like it executes WordPress, Magento, Drupal or Laravel applications.

This has three consequences:

1. Updating PrestaShop or your modules will not fix this. There is no PrestaShop patch to install. The only complete fix is updating PHP on the server.
2. The attack can happen before PrestaShop code runs. Security measures in PrestaShop or in modules cannot block it. Protection has to come from the PHP update, and in the meantime from the server or network layer.
3. Every PrestaShop version is concerned, from 1.6 to 9, since they all run on PHP.

Because these flaws can be exploited remotely and without authentication, we consider the PHP update a top priority for every merchant.

3. Steps to follow

Check your PHP version

In your Back Office, go to Advanced Parameters > Information. The PHP version is listed under Server information. Then compare it with the fixed versions:

Linux distributions often backport security fixes without changing the version number. A Debian or Ubuntu package may still show an older 8.2.x version while including the fix. A lower version does not automatically mean you are vulnerable, but you should check with whoever manages your server.

Contact your hosting provider

On shared hosting, managed hosting or a PrestaShop-specialized host, PHP is managed for you. Linux distributions and long-term support vendors received the patches in advance, so most serious hosting providers are already rolling out updates.

Ask them one simple question: "Has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP version running my store?" Ask for a written confirmation. A ready-to-send message is available in section 7.

If you manage your own server

If you or your agency manage the server (VPS, dedicated server, cloud instance, containers):

• Install the updated PHP packages from your Linux distribution, or from the official PHP releases, as soon as possible.
• Restart every PHP process after the update (PHP-FPM pools, Apache, LiteSpeed, FrankenPHP workers). An update that is installed but not loaded does not protect you.
• If you use the volunteer-maintained rpms.remirepo.net repository: the PHP project announced it would not have updates on October 21, and recommends switching to distribution packages or building from source.
• If your store runs in Docker, rebuild your images on the updated base image and redeploy.
• After the update, check that your store works: Back Office login, add to cart, test order.

If you are not comfortable updating PHP on a production server, you can find a specialized agency or freelancer on the PrestaShop Experts portal.

Watch for signs of compromise

• Unknown or recently modified .php files in your store's folders.
• Administrator accounts you did not create in the Back Office.
• Unexpected redirects, altered content or a modified payment page.
• If in doubt, contact your hosting provider immediately.

4. Special case: PHP 8.1 or older

PHP 8.1 and older no longer receive official updates from the PHP project. This is common in the PrestaShop ecosystem, because PrestaShop 1.7 and 8 do not support PHP 8.2 or later:

Sources: PrestaShop 9 requirements, PrestaShop 8 requirements, PrestaShop 1.7 requirements.

If this applies to you:

• Ask your hosting provider whether your PHP version has been patched. Many Linux distributions and LTS vendors ship patched packages for the versions they still support. The PHP project also published minimal backports for PHP 7.4, PHP 8.0 and PHP 8.1.
• If no patch is available yet, apply the interim measures in section 5.
• Plan an upgrade to PrestaShop 9, which runs on maintained PHP versions. A major upgrade means checking your theme and modules for compatibility: a PrestaShop Expert can help.

Also note that PHP 8.2 reaches end of life on December 31, 2026. If your store runs PHP 8.2 today, plan a move to a newer PHP version too.

5. If PHP cannot be updated right away

The PHP Security Team is clear: there is no complete mitigation, and updating is the only safe choice. The measures below only reduce exposure while the update is being scheduled. They are meant for hosting providers, technical teams and PrestaShop Experts, and should be tested on a staging environment first.

For CVE-2026-109618 (out-of-memory handling)

• Limit request sizes: set post_max_size to 32M and keep upload_max_filesize below it. PrestaShop uses uploads in the Back Office (product images, CSV imports, module installation), so 32M is the relevant value rather than 8M. Very large imports or module archives may need to be split.
• Enforce request size limits at the web server or reverse proxy level as well.
• The advisory also describes setting memory_limit=-1 through php_admin_value, combined with a container or cgroup memory limit. Do not use RLIMIT_AS or RLIMIT_DATA for this, as they can trigger the vulnerable behavior.

For CVE-2026-109619 (stale state between requests)

• Set session.upload_progress.enabled=0 in php.ini, the PHP-FPM pool or the server configuration, then restart all PHP workers. Do not rely on ini_set() or .user.ini files. This setting has no impact on PrestaShop, which does not use this feature.
• On PHP 8.5, also set fatal_error_backtraces=0 and restart the workers.

Hiding errors (with error_reporting, display_errors or the @ operator) does not help. The official advisory remains the complete and authoritative list.

Checking the configuration

With SSH access, these commands show the PHP version and the settings above:

php -v
php -i | grep -E "session.upload_progress.enabled|post_max_size|upload_max_filesize"

The command line and the web server can use different PHP configurations. The values that count are those applied to the website: check them with your hosting provider, or the version in Advanced Parameters > Information.

Web Application Firewall (WAF)

A WAF filters malicious requests before they reach PHP, which matters here since the attack happens before application code runs. Cloudflare, for example, deployed dedicated WAF rules for php2shell, active by default on free and paid plans since October 21. On a paid plan, check that the managed ruleset runs in block mode.

A WAF is a welcome extra layer, but signature-based protection can be bypassed by reworked payloads. It does not replace the PHP update.

6. Best practices and prevention

A store depends on many layers: the server, PHP, PrestaShop, the theme and every module. A weakness in any of them can put the whole store at risk, even when the layer at fault is not PrestaShop. AI tools now help researchers find vulnerabilities faster, but they also help attackers turn a published fix into a working attack within hours.

• Use a maintained PHP version: an end-of-life version depends on others to backport critical fixes.
• Keep PrestaShop and your modules up to date: recent PrestaShop versions support recent PHP versions.
• Choose partners who patch quickly: check your hosting contract for who applies PHP updates, and how fast.
• Make regular backups: files and database, stored off the server.
• Follow security announcements: PHP, the PrestaShop security advisories, the Friends of Presta security site and your hosting provider.
• Put a maintenance plan in place: a PrestaShop Expert can handle it if you do not have a technical team.

7. When to contact your hosting provider or an expert

Contact your hosting provider today if PHP is managed for you, if your version is older than those listed in section 3, or if you notice suspicious behavior. Contact an agency or a PrestaShop Expert if you manage your own server and need help, or to prepare an upgrade to PrestaShop 9.

You can send your hosting provider this message:

Hello,

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619).

My store runs PHP [your version].

Could you please confirm in writing:

1. Whether the fix has been applied to the PHP version running my store, and when?
2. That all PHP processes have been restarted since?
3. If my PHP version is no longer maintained, whether you provide a patched package, or which interim measures you have applied?

Thank you.

8. Key takeaways

• The vulnerabilities are in PHP, not in PrestaShop: there is no PrestaShop patch, and the fix is a PHP update on the server.
• Check your PHP version in Advanced Parameters > Information and compare it with 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
• Contact your hosting provider today and ask for written confirmation, or update and restart PHP yourself if you manage the server.
• On PHP 8.1 or older: ask for a patched package, apply the interim measures and plan PrestaShop 9.
• Keep a WAF in front of your store if you can, but it does not replace the update.

Sources

• PHP advance notice
• PHP security advisory
• Cloudflare: WAF protection for php2shell
• PrestaShop 9 system requirements
• PrestaShop 8 system requirements
• PrestaShop 1.7 system requirements