Email us

01606 800 400

Contact

Free Guide to Managing Your
WordPress Website

|

|

PHP2Shell: What the Critical PHP Flaws Mean for Your WordPress Site

Row of servers in a dark data centre, one front panel forced open with blue light showing through the gap

On 21 October the PHP project released emergency fixes for two flaws that let an attacker run their own code on a web server without logging in. The pair has been nicknamed PHP2Shell. Both are rated 9.2 out of 10 for severity, and attack attempts started several hours before the fix was out.

WordPress is written in PHP. If your website runs on WordPress, it runs on PHP, and it stays exposed until whoever manages your server installs the patched version. Updating WordPress, your plugins or your security plugin won’t help. This post explains what PHP2Shell is, how many sites it affects and what to do about it.

What PHP2Shell is

PHP2Shell is two separate bugs in the PHP engine itself:

  • CVE-2026-109618 is in the way PHP handles running out of memory. PHP can be interrupted while a request is only half set up, and the clean-up code then treats the half-built data as valid.
  • CVE-2026-109619 is a “use after free” flaw. Data belonging to one request can survive after its memory has been released, and the next request handled by the same PHP process can pick it up.

An attacker can trigger either one with a specially crafted web request. They need no password, no account and no help from anyone on your end. Researchers at Wiz, Calif and OpenAI found the flaws, used AI models to help build working exploits, and demonstrated the attack against a standard WordPress install.

The attack runs inside PHP before WordPress loads. WordPress security and firewall plugins never see the request, so they can’t block it. Once in, an attacker can do anything your website can do, and usually more: create hidden admin accounts, plant backdoor files, redirect visitors to scam sites, publish spam pages for Google to index, copy your customer database or add a card skimmer to a shop checkout.

How widespread the PHP2Shell problem is

PHP says every installation that serves web pages is at risk, whatever the server setup. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates Apache with mod_php, still common on budget shared hosting, as the highest risk.

  • PHP runs 69.3% of all websites whose server-side language is known, according to W3Techs.
  • WordPress alone powers around 42% of all websites.
  • The vulnerable code goes back to PHP 5.4, released in 2012.
  • Security researcher Silas Cutler estimates more than 1.3 million internet-facing servers could be vulnerable. A Shodan search found more than 1.9 million running PHP. Many of those are shared hosting servers carrying hundreds of websites each.

Some organisations didn’t wait to find out. The Dutch House of Representatives, the Netherlands’ National Cyber Security Centre and the DigiD government login service went offline as a precaution. So did Finnish government services and the HR software company BambooHR. CERT-EU and the UK’s National Cyber Security Centre advised organisations to consider taking sites offline where they couldn’t protect them straight away.

Older PHP versions get no official fix

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release. PHP has published source-code patches for 7.4, 8.0 and 8.1, but only for people who compile PHP themselves. PHP 7.3 and older get nothing.

W3Techs figures suggest close to half of all PHP websites run 8.1 or older. Those sites depend on their host backporting the fix, or on an upgrade to a supported version of PHP.

How it unfolded

All times are UK time.

  • 19 August: the researchers reported the flaws to PHP privately.
  • 20 October: details leaked ahead of the planned release on 22 October, and PHP brought the release forward by a day. A proof-of-concept video was posted by mistake that evening.
  • 21 October, 04:02: Cloudflare switched on firewall rules against the attack for all customers, free plans included.
  • 08:43: Cloudflare saw the first attack attempts.
  • 15:00: PHP released the fixed versions.
  • 15:19: security firm watchTowr reported active exploitation attempts against both flaws.

What to do if you run a WordPress site

  1. Check your PHP version. In WordPress, go to Tools > Site Health, open the Info tab and expand Server. Compare the PHP version with the fixed versions above. Some Linux distributions patch older version numbers without changing them (Ubuntu 24.04 ships PHP 8.3.6 with fixes applied), so a low number isn’t proof you’re exposed. Your host’s confirmation is what counts.
  2. Ask your host a precise question. “Have you installed the PHP fix for CVE-2026-109618 and CVE-2026-109619 on my server?” A reply about firewall protection doesn’t answer it. A firewall lowers the risk. Only the PHP update removes it.
  3. If you manage your own server, install the fixed PHP packages from your Linux distribution or PHP vendor, then restart PHP-FPM, LiteSpeed or Apache. Processes that aren’t restarted keep running the old code. PHP has listed temporary settings changes, such as switching off session upload progress, but says plainly that they don’t make a server safe.
  4. If you’re on PHP 8.1 or older, plan the upgrade now. Take a backup, update your plugins and theme, move to PHP 8.3 or 8.4, then test your key pages and forms. PHP 8.2 reaches end of life on 31 December, so skip it.
  5. Put Cloudflare in front of your site if it isn’t there already. The free plan blocks the known attack patterns. It only protects traffic that passes through Cloudflare, so an attacker who knows your server’s real IP address can go around it.
  6. Check for signs of a break-in. Attacks started hours before the fix, and a patch doesn’t remove anyone already inside. Look for admin users you don’t recognise, plugins you didn’t install, .php files inside wp-content/uploads, and unfamiliar pages in a site:yourdomain.co.uk Google search. If you find anything, restore a clean backup and change every password.

If your host can’t confirm the fix and you can’t patch the server yourself, CERT-EU’s advice is to take the site offline until you can.

WP Support Agency clients: nothing to do

If we look after your site, you don’t need to lift a finger.

Every site we host sits behind Cloudflare, and the firewall rules that block known PHP2Shell attacks were in place on our sites from the early hours of 21 October, before PHP had even published its fix.

We then installed the fixed version of PHP on every server we run as soon as the patched packages were available. We run our own dedicated servers, so we didn’t have to wait in a queue behind thousands of other customers for a shared host to get round to it.

If you have a question about your own site, get in touch and you will speak to someone who knows it.

Not a client yet? Watching for threats like this and patching the server the same day is the routine work our hosting, maintenance and support plans take off your plate. If you don’t know which PHP version your site runs, or whether your host has patched it, request a free website review and we will tell you in plain English.

We covered last month’s WordPress core security fixes in WordPress 7.1.1 and 7.1.2: two security releases in five days. PHP2Shell is a different problem: it sits underneath WordPress, and only the people running your server can fix it.

References

Previous Post