PHP2Shell vulnerability: is your site at risk?

PHP2Shell is a PHP vulnerability, not a WordPress one. It affects PHP itself, the language that runs WordPress on the server, and it lets an attacker run code there remotely, without an account or a password. Think of an apartment building: the flaw is in the lock on the front door, not in the one on your unit. Changing your keys, in other words updating WordPress and its plugins, doesn’t fix it. The fix gets installed on the server, by your host or by whoever manages that server. Checking whether your site is affected takes two minutes, and that’s where to start.

What the PHP2Shell vulnerability lets an attacker do

PHP2Shell covers two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 by the PHP team. A carefully crafted request, sent to any page on the site, can make the server run the attacker’s commands. It all happens when PHP reads the request, before WordPress even starts. A security plugin like Wordfence therefore arrives too late: it only runs after that step.

Once their code runs, attackers can do anything the site can do. Slip spam pages into your site. Hide malware in it that targets your visitors. Read the database, and with it the requests your forms have received. Or enlist the server in a botnet: attempts to install Mirai, a well-known piece of botnet software, have already been reported.

The risk is anything but theoretical. Amazon spotted a first attack attempt four days before the official announcement. On the day of the announcement, Cloudflare saw attempts go from a few tens of thousands in 45 minutes to millions in less than a day. Palo Alto Networks counts more than 22 million exposed installations on the internet. Researchers note that a reliable attack is harder to write than expected, and several observers have seen only scanning, with no confirmed takeover. That’s a reason not to panic, not a reason to wait.

Every PHP version that serves web pages is affected, back to PHP 5.4, however the server runs PHP. The PHP team released four fixed versions:

For PHP 7.4 to 8.1, the PHP team only published fixes you have to compile yourself. Some hosts and Linux distributions have applied them, but those branches get nothing else. Now is the time to move off them.

How to tell if your site is vulnerable

In the WordPress dashboard, open Tools › Site Health, then the Info tab. Expand the Server section: the “PHP version” line gives the full number. Compare it with the table above, down to the last digit: 8.4.26 is vulnerable, 8.4.27 no longer is.

Two traps await anyone who stops there.

The first is in the Status tab of the same page. WordPress shows “Your site is running a recommended version of PHP” even for a vulnerable version. It judges the branch (8.3, 8.4), not the fixes installed. We queried the WordPress.org service that provides this verdict: it considers PHP 8.4.26 secure. Site Health’s green light says nothing about PHP2Shell.

The second affects servers that get PHP from a Linux distribution. Ubuntu, for example, fixes vulnerabilities without changing the displayed number. A patched Ubuntu 24.04 server still shows 8.3.6, while PHP’s fixed version is numbered 8.3.36. The fix lives in the installed package, invisible from WordPress. The same goes for the old PHP versions some hosts maintain themselves. If your number is lower than the one in the table, your site may be vulnerable, or it may not: only your host, or whoever manages the server, can tell.

Without access to WordPress, your host’s control panel also shows the PHP version, but sometimes only the branch, without the last digit. Asking your host is then the only way to be sure.

Fixing the PHP vulnerability through your host

On shared hosting or managed WordPress hosting, you don’t choose the last digit of the version. The control panel lets you pick the branch, 8.3 or 8.4 for example. The fixes within that branch are installed by the host on its servers. It isn’t a button you forgot to click.

So write to support, with a question that can’t be sidestepped: “Do the PHP versions on my account include the fixes for CVE-2026-109618 and CVE-2026-109619? Since when?” Keep the answer in writing. A serious host patched within days of the announcement, and can say so in one sentence. A host that can’t answer this question has already given you its answer. Our article on choosing web hosting will help you find another one.

If your site still runs on PHP 8.1 or older, a fix from your host only buys time: it’s up to you to switch branches, in the control panel, to 8.3 or 8.4. Don’t do it blindly. An old plugin or theme may not keep up and throw an error. Try it first on a copy of the site, as for a major update (we explain how in our article on WordPress updates). If the copy works, switch the live site’s version, then go over your key pages and forms again.

Asking your host the right question, testing on a copy, checking afterwards: if you’d rather someone else took care of it, that’s the kind of follow-up you hand to a WordPress maintenance service.

Fixing it yourself on your server

If your site runs on a cloud server that you manage, you or your developer, nobody will update it for you. On Ubuntu or Debian, two commands are enough, replacing 8.3 with your branch:

sudo apt update
sudo apt install --only-upgrade 'php8.3*'

Then restart PHP. This is the step people forget: as long as PHP’s processes keep running, they keep the old code in memory, and the server stays vulnerable even with the new package installed.

sudo systemctl restart php8.3-fpm

If PHP runs as an Apache module, restart Apache instead (sudo systemctl restart apache2). Then check the version on the web side, in Site Health, not just with php -v: the command line and the site don’t necessarily use the same PHP installation. On Ubuntu, where the number doesn’t change, apt policy php8.3-fpm gives the installed package version, to compare with Ubuntu’s security notice. Debian 12 and 13 received the official versions 8.2.35 and 8.4.27. Ondřej Surý’s repository, widely used to install recent PHP versions, also follows the official numbers.

With Docker, restarting the container changes nothing. You have to pull the fixed image and recreate the container (docker compose pull, then docker compose up -d).

If you can’t update right away, one setting reduces the risk in the meantime. Add it to the php.ini file the website uses, not the command-line one, then restart PHP:

session.upload_progress.enabled = 0

On PHP 8.5, also add fatal_error_backtraces = 0. This setting closes one of the attack paths, not both. The PHP team says so plainly: no setting makes an installation safe, only the update does. The same setting also protects against a third vulnerability, announced two days later (CVE-2026-115560): it only affects unusual configurations and will be fixed in PHP’s next regular release.

Cloudflare, a stopgap in the meantime

If your site goes through Cloudflare, you have one more layer of protection. Cloudflare added rules against PHP2Shell to its firewall a few hours before the official announcement. They apply to every plan, the free plan included, with nothing to turn on. On a paid plan, check that the Managed Ruleset is set to block.

This protection has two limits. It only covers visits that go through Cloudflare: if your server also answers anyone who calls it directly by its IP address, an attacker can go around it. And a firewall recognizes known attacks. Cloudflare has already seen attackers modify their requests to slip past its rules, which it adjusts as it goes. It’s a fence around the house, not a new lock. Our article Cloudflare: what does it do for your website? explains what it protects and what it doesn’t replace.

If your site has already been targeted

An update closes the door. It doesn’t remove someone who may already be inside. If your site ran on a vulnerable version, take the time to look for traces:

• an administrator account you don’t recognize, under Users (filter by role);
• .php files in the wp-content/uploads folder, which should only hold images and documents;
• modified WordPress or plugin files: a Wordfence scan flags them, as do the WP-CLI commands wp core verify-checksums and wp plugin verify-checksums --all;
• in the server’s error logs, bursts of the message “Allowed memory size … exhausted” followed by “Unknown on line 0”, a sign of an attempt.

If you find something, don’t just delete the suspicious file. Update PHP, restore a backup from before the intrusion, then change every password: administrators, database, hosting, plus the security keys in the wp-config.php file. If the database held form submissions, the intrusion is also a confidentiality incident under Quebec’s Law 25, with specific obligations we detail in our article on Law 25.

And if nothing looks wrong, write down the date of your check and your host’s answer. Next time a vulnerability comes out, you’ll already know who to write to and what to ask.