PHP2Shell: the PHP vulnerability putting PrestaShop stores at risk

On 20 October, a warning went out that put half the internet on edge: two serious vulnerabilities in PHP, the language your PrestaShop store runs on, that let a stranger take over the server without a username or password. They go by the name PHP2Shell. PHP released the fix on 21 October, and what you need to do depends on just one thing: the PHP version your store runs on.

Here it is without the jargon: what happened, how to tell if it affects you, what to do today and how to find out whether your host has already applied the fix.

What is PHP2Shell, and why is it so serious?

PHP is the engine underneath PrestaShop, WordPress, Magento and most online stores and websites in the world. The two vulnerabilities, registered as CVE-2026-109618 and CVE-2026-109619, have a severity score of 9.2 out of 10. In practice, anyone who knows how to exploit them can run whatever they like on your server: leave a back door, steal your customers' data or plant a fake captcha in your store like the one in ClickFix.

What sets this apart from other warnings is that the attack doesn't go through PrestaShop or any module. It happens in PHP, before your store even gets to read the visit. However well looked after your store is, if the server's PHP is vulnerable, so is the store.

And the details leaked early. The security firm Sansec reports that a screenshot of a ready-made attack tool appeared alongside the warning, and it expected mass attacks as soon as the fix was published. According to the same source, Cloudflare had already seen the first attempts and put rules in place to stop them.

Does it affect my PrestaShop store?

Most likely, yes. In its security advisory, PHP considers any installation that serves web pages to be at risk, however the server runs it, with the highest risk on Apache servers using mod_php, where a working attack that needs no username or password has already been demonstrated. Sansec talks about any server running PHP 5.4 or later, which in practice means every PrestaShop store online today.

The question that really matters is a different one: do you get the fix? PHP has fixed it in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For the old versions, which no longer have official support, PHP published the patch without a new release, and within a day or two the control panels and systems hosting companies use turned it into a normal update: cPanel and CloudLinux, from PHP 5.2 up to 8.1; DirectAdmin, Ubuntu, Red Hat, AlmaLinux and the Remi repository, for the 7.4 to 8.1 versions they still maintain. And each PrestaShop version only works with certain PHP versions:

• PrestaShop 1.6: works with PHP 5.6 to 7.1. There's a patch if your host uses cPanel or CloudLinux; elsewhere, only through paid extended support such as TuxCare or Zend.
• PrestaShop 1.7: PHP 7.4 at most. A patched 7.4 already exists on almost every control panel: your host just has to install it.
• PrestaShop 8: PHP 8.1 at most. Same as 1.7: a patched 8.1 already exists, and it's down to your host to install it.
• PrestaShop 9: works with PHP 8.1 to 8.4. On PHP 8.2 or later, it gets the official update; if it's on 8.1, upgrading PHP is all it takes.

In other words: almost any store can be running a PHP without this flaw today. But if yours isn't PrestaShop 9, it depends on your host having installed the patch, and since the version number doesn't change, you can't tell at a glance: you have to ask them. It's also an emergency patch: PHP 8.1 and earlier have no official support, so with the next flaw you'll again depend on someone fixing it on their own.

How to check which version you have

Log in to your store's back office and open Advanced Parameters → Information. There you'll see the PrestaShop version and, a little further down, the PHP version. With those two numbers you know which case you're in.

What to do today, in order

1. Check your two versions, PrestaShop and PHP, as explained above.
2. Make a full backup, files and database, and keep it off the server. If something goes wrong, it's the only thing that lets you go back.
3. If your store is on PrestaShop 9, ask your hosting provider to update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later, or do it yourself from the hosting control panel if it lets you choose the version. If you're on PHP 8.1, take the chance to move to 8.3 or 8.4.
4. If you use Cloudflare, check that the cloud next to your domain is orange: that way traffic goes through its rules before it reaches your server. It's of little use if your server's address is known and accepts visits from anyone, so ask your developer to lock it down to Cloudflare only.
5. If your store is 1.6, 1.7 or 8, ask your host whether they've already installed the PHP2Shell patch for your PHP version. If they haven't, ask your developer for the emergency measures we describe below. And put a date on the upgrade to PrestaShop 9: it's how you get back to a PHP with official support.

Putting the store into maintenance mode from the back office won't protect you this time: PHP reads the visit before PrestaShop decides to show the maintenance page.

What if my host doesn't have the patch?

PHP suggests some server settings that close off some of the attack's paths, and warns that they don't make the store secure: only the update does that. Sansec adds another emergency measure: blocking on the server the type of request that carries files uploaded to a website. It comes at a cost: while it's in place, nobody can upload files to your store. Not you with photos for a new product, and not your customers with an attachment on the contact form. The store keeps selling as normal.

It buys you a few days; it isn't a way to stay. Either your host installs the patch or you move to one that has it. And the next time a PHP flaw comes out —and they will— your store will depend on that again, because PHP 8.1 and earlier no longer have official support.

Which PHP each PrestaShop version supports, and how long it gets patches, is in one table in which PHP version PrestaShop needs.

Is it worth upgrading PrestaShop now?

It's the question that always gets postponed because the store works. PHP2Shell is what happens when it's postponed too long: you don't choose the day the problem arrives, and whether the fix reaches you depends on others.

Moving to PrestaShop 9 puts you on a PHP that gets patches for years. It's done without closing your store, you keep your products, customers, orders and Google rankings, and a small store costs from €690. We explain it all in upgrading PrestaShop 1.7 or 1.6 to 9, and on our PrestaShop 1.6 and 1.7 to 9 migration page.

And if you would rather not keep an eye on warnings like this, that is what PrestaShop maintenance is for: we watch your shop, keep its modules up to date and, if it runs on a BK Modules server, PHP too, so a warning like this does not catch you off guard.

Need help today?

If you don't know which case you're in, if your hosting provider isn't answering, or if your store is on 1.6, 1.7 or 8 and you want to move on, tell us your PrestaShop and PHP versions. We'll tell you what to do today and, if needed, give you a fixed price for moving to PrestaShop 9.

I want to upgrade my store

For your technical team

Fixed versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For 7.4, 8.0 and 8.1, PHP publishes the minimal fix as source code, linked from its advisory, with no new release. Patched packages keep the version number, so php -v can't tell them apart: check the package revision (rpm -q, dpkg -l). Fixed revisions: cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. The partial measures PHP gives go in php.ini, in the PHP-FPM pool (php_admin_value) or in the server configuration, never with ini_set() or .user.ini, and restarting every process:

; CVE-2026-109618
memory_limit = -1
post_max_size = 32M   ; 8M if no files are uploaded
; CVE-2026-109619
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0

PHP asks you not to replace memory_limit with system limits (RLIMIT_AS, RLIMIT_DATA). Sansec's measure, blocking multipart/form-data (it breaks all file uploads, back office included), in Apache:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

In Nginx:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

With Cloudflare, restrict the origin's port 443 to its IP ranges; otherwise the attack goes straight to the server's IP.