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 has happened, how to tell if it affects you, what to do today, and what to do if your store is on a version that doesn't get 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. PHP 8.1 and earlier no longer get official updates: for 7.4, 8.0 and 8.1, PHP has provided a minimal fix that has to be compiled by hand, and some extended support providers include it in their packages. And each PrestaShop version only works with certain PHP versions:

• PrestaShop 1.6: works with PHP 5.6 to 7.1. No fix.
• PrestaShop 1.7: PHP 7.4 at most. No official update; only on 7.4 can the minimal fix be compiled by hand.
• PrestaShop 8: PHP 8.1 at most. No official update; the minimal fix for 8.1 also has to be compiled by hand.
• PrestaShop 9: works with PHP 8.1 to 8.4. On PHP 8.2 or later, it gets the update; if it's on 8.1, upgrading PHP is all it takes.

In other words: if your store isn't on PrestaShop 9, there is no official update to install, because your PrestaShop version can't run on a PHP that has it. That leaves the minimal fix, which is a job for a developer and won't cover you against the next vulnerability either.

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 on 1.6, 1.7 or 8, ask your hosting provider whether they apply the fix to your PHP version, ask your developer for the emergency measures described below, and set a date for the upgrade to PrestaShop 9. It's the only way to get back onto a PHP that receives patches.

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 store can't get the fix?

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, not a permanent solution. The next time a PHP vulnerability comes out —and more will— your store will be in exactly the same position, because PHP 8.1 and earlier no longer get updates.

Is it worth upgrading PrestaShop now?

It's the question that always gets put off because the store works. PHP2Shell is what happens when it gets put off for too long: you don't choose the day the problem arrives, and the fix is out of your reach.

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 what you want is to stop having to keep an eye on warnings like this, that's exactly what a maintenance plan covers: someone who updates PHP, PrestaShop and modules for you and warns you before the problem reaches your 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 branches with the minimal fix as source code, linked from its advisory; they are not official releases. PHP's partial mitigations, in php.ini, in the PHP-FPM pool (php_admin_value) or in the server configuration, never with ini_set() or .user.ini, then restart 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 packages from the Remi repository (common on RHEL, AlmaLinux or Rocky), Sansec warned that the update wasn't arriving the same day: check the installed version with php -v. With Cloudflare, restrict the origin's port 443 to its IP ranges; otherwise the attack goes straight to the server's IP.

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