The 21 October 2026 PHP vulnerability: is your PrestaShop store exposed?

Yes, every PrestaShop store is concerned, because the flaw is in PHP itself, not in PrestaShop. On 21 October 2026, the PHP project fixed two critical vulnerabilities, nicknamed PHP2Shell, that allow remote code execution without authentication. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Yet according to PrestaShop's official documentation, only PrestaShop 9 runs on those PHP branches. A store on 1.6, 1.7 or 8 cannot get an officially patched PHP release.

What does the PHP2Shell vulnerability allow?

The two flaws are CVE-2026-109618 and CVE-2026-109619, and the PHP project rates each 9.2 out of 10 (CVSS v4.0). The first comes from out-of-memory handling, which can interrupt PHP while it is preparing a request; the second from internal state that outlives the memory holding it. In both cases, PHP's security advisory describes remote code execution by an unauthenticated attacker.

In practice, someone with no account on your store can make it run their own instructions. For a store, that means access to the files and the database, so to customer accounts and orders, and the ability to change pages, the payment page included.

The PHP project states that every PHP installation serving web pages is exposed, whatever the setup: PHP-FPM, Apache with mod_php, where the risk is highest, php-cgi, FrankenPHP or LiteSpeed. Updating PrestaShop or its modules changes nothing: the interpreter is the problem.

Is the vulnerability already being exploited?

Sources don't all say the same thing, and that should be stated plainly. Details leaked before the planned date, which led the PHP project to announce the fix on 20 October and publish it the next day. The security company watchTowr says it has observed exploitation attempts since 21 October on its attacker traps. According to the same source, the US agency CISA had not yet added these flaws to its catalog of exploited vulnerabilities on 22 October, and the Canadian Centre for Cyber Security reports a public proof of concept, with no active exploitation seen on its side.

Public agencies are taking no chances. The UK's National Cyber Security Centre (NCSC) asks organizations to update, and, if neither the update nor the temporary settings can be applied quickly, to consider taking the site offline until it is fixed. The Canadian Centre for Cyber Security issued an alert on 21 October recommending that updates be applied without delay.

Which PrestaShop versions can run a patched PHP?

Each PrestaShop version only accepts a range of PHP versions. Cross-checking PrestaShop's compatibility tables with PHP's advisory and watchTowr's notes gives this:

For PHP 7.3 and older, PHP 5 included, watchTowr confirms they are affected and that no fix exists. For PHP 7.4, 8.0 and 8.1, the PHP project no longer publishes releases, but it has pushed minimal fixes to its source code. Applying them means recompiling PHP, which is a job for a host or a Linux distribution that maintains those old branches, not for a merchant.

The PrestaShop 8 case is the one that surprises most. Version 8 looks recent, but it stops at PHP 8.1, which the PHP project no longer maintains. It ends up in the same position as 1.7.8: protected only if the host has applied a fix on its side.

What should you do this week?

Check your PHP version. In the PrestaShop back office, the Advanced Parameters > Information page shows the server's PHP version. Note it down with your PrestaShop version, and find your row in the table.

Write to your host. Ask whether your PHP version has received the fix for CVE-2026-109618 and CVE-2026-109619, and on what date. On shared hosting, the host runs PHP, and its answer decides everything else. A vague answer is not a yes.

If you are on PrestaShop 9, move to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 depending on your version, then restart PHP. The PHP project is clear: updating is the only safe choice.

If the update can't happen right away, PHP's advisory lists temporary settings for your host or whoever manages the server to apply: memory_limit, post_max_size, and above all session.upload_progress.enabled=0, which also covers a third flaw announced on 23 October, CVE-2026-115560. PHP says it itself: these settings don't make an installation safe, they reduce the risk in the meantime.

Keep an eye on the store. The same Information page lists the files changed since the original installation: take a look. An unknown PHP file in the site's folders, an administrator account you didn't create, a modified payment page: those are signs of an intrusion. At the slightest doubt, the NCSC's advice applies, and a store closed for a few hours costs less than a customer database out in the wild.

Should you rebuild your store after PHP2Shell?

If your store isn't on 9, yes, you should plan it. PHP2Shell shows in black and white what running on a PHP version nobody maintains anymore means: the day the flaw comes out, there is no fix to install. A 1.6 runs on a PHP abandoned since December 2019, a 1.7.8 on a PHP abandoned since November 2022, an 8 on a PHP 8.1 that gets no new releases. That will hold for the next flaw too.

And the clock is ticking for everyone: PHP 8.2 stops receiving fixes on 31 December 2026. A PrestaShop 9 store running on PHP 8.2 will therefore have a PHP update to plan within two months as well.

The path depends on where you start. From 1.6, the official upgrade module requires two steps, from 1.6 to 1.7, then from 1.7 to 9; modules and theme need checking at each step, and so do the URLs to protect so you don't lose your rankings. From 8, the jump is shorter. Either way, it takes weeks to prepare, not days, which is why it pays to start the inventory now, while your host keeps the store afloat. The version-by-version detail is in our article on 1.6: maintain or rebuild.

Not sure where your store stands, or what moving to 9 would cost? Write to us with the store's address, its PrestaShop version and its PHP version: we'll reply with an upgrade plan and its scope.

FAQ

Has PrestaShop released a fix for PHP2Shell? No, and it isn't PrestaShop's job: the flaw is in PHP, not in PrestaShop. Updating PrestaShop or its modules doesn't fix it. Only updating PHP, or a fix applied by the host, protects the store.

Is my PrestaShop 1.6 store vulnerable to PHP2Shell? Yes. 1.6.1 accepts no PHP newer than 7.1, and no PHP version from 7.3 down has a fix, according to watchTowr. Protection depends entirely on your host, and the only lasting way out is migration.

Is PrestaShop 8 safe? Not by default. PrestaShop 8.0 to 8.2 stop at PHP 8.1, which the PHP project no longer maintains; there is only a minimal fix in the source code, for the host to apply. You need PrestaShop 9 to run an officially patched PHP version.

How do I know whether my host has patched PHP? Ask in writing whether your PHP version includes the fixes for CVE-2026-109618 and CVE-2026-109619. The version shown in Advanced Parameters > Information should be at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12; below that, only the host can confirm that a fix was backported.

Should I close my store? Not necessarily. The UK's NCSC advises considering taking it offline only if the update and the temporary settings can't be applied quickly. If your host confirms the fix, the store can stay open.