Have a web emergency? We'll fix your site free! →

PHP2Shell: What the Critical PHP Bug Means for WordPress Sites

PHP2Shell is a critical PHP flaw that lets attackers run code on servers. Learn why WordPress updates cannot fix it and what your host should do right now.

Nick Stafford, WP Farm 8 min read
PHP2Shell: What the Critical PHP Bug Means for WordPress Sites Security

Update, October 21, 4:55 PM Eastern: cPanel shipped the fix, and every WP Farm server now runs patched PHP 8.3.36. Details are in What WP Farm Did Today below.

PHP2Shell is the name researchers gave to two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project shipped fixes on October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and its security advisory says the bugs “can allow unauthenticated remote code execution.” Because PHP runs underneath every WordPress site, updating WordPress, themes or plugins does nothing for this one. The fix has to land on the server, and how fast your host installs it matters more than anything you can do inside wp-admin.

This post explains what PHP2Shell is, why governments told organizations to take sites offline, what a good host does while it waits for patched packages, and what WP Farm did today.

What PHP2Shell Is

The two bugs live in the PHP engine, the software that runs WordPress code on the server. According to the PHP project and Help Net Security:

  • CVE-2026-109618 is remote code execution through out of memory corruption. Out of memory handling can interrupt PHP while request data is only partly set up, and cleanup may then treat that broken data as valid.
  • CVE-2026-109619 is remote code execution through stale global state. Internal state from one request can survive after its memory is freed, and a later request on the same worker may use it.

The PHP security team rates both flaws 9.2 on CVSS v4.0, which is in the critical range, as reported by BleepingComputer and Patchstack. Help Net Security reports that “a single unauthenticated request can trigger the attack before any application code runs.” In plain terms, an attacker does not need a login, a vulnerable plugin or a weak password. They need a server running an unpatched PHP build.

The bugs were found with help from AI. The BBC reports that researchers at the security firms Calif and Wiz discovered the flaws using AI made by OpenAI. Both firms published their own write-ups. Calif says it reported the first bug to PHP on August 11, 2026, and Wiz says it found its first bug on August 19 using several AI models, including OpenAI’s GPT-5.6 Sol and Google’s Gemini.

Which PHP versions get a fix

  • Fixed: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released October 21, 2026.
  • No official release: PHP 8.1 and older. The PHP project says these versions “no longer receive updates,” though its security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, per php.net and Help Net Security.

If your site still runs PHP 8.1 or older, you are relying on your host or operating system vendor to backport a fix. Ask your host directly whether it has one.

Why Agencies Told Sites to Go Offline

Details of the flaws leaked before the fix was ready, and national cyber agencies reacted fast. The UK’s National Cyber Security Centre told organizations to find and update every PHP system and said that if mitigation is not possible, “you should consider taking the system offline until it can be fully mitigated,” in its October 21 alert. CERT-EU advised isolating internet facing applications that could not be patched quickly, The Next Web reports. The US NSA said organizations that cannot update right away should take affected systems offline until the issue is mitigated, according to Reuters and the BBC.

Many organizations did exactly that. Reuters reports that Finland’s government IT agency shut down the government’s public web services as a precaution, and that many Dutch organizations followed the lead of the Netherlands’ National Cyber Security Centre, which The Telegraph reports took its own site offline as a precaution. The BBC reports that the Wikimedia Foundation took systems down until they could be patched, that Edinburgh council’s website became inaccessible, and that the online homes of several BBC programmes went offline. The Scotsman notes the council described its outage as essential maintenance and did not confirm a link to the alert.

Reports on active attacks differ. Cloudflare says it observed attack traffic targeting its customers after the leak, and that attackers were changing payloads to try to get past its rules. Other firms, including Huntress and watchTowr, had not confirmed exploitation in the wild when they published, per BleepingComputer and Brandefense. Either way, a working exploit exists and the details are public, so we treat every unpatched PHP server as exposed.

Why PHP2Shell Is a Host Problem for WordPress Sites

WordPress is written in PHP. Every page view, login and checkout passes through the PHP engine before any WordPress code runs. Patchstack states that PHP2Shell “affects all versions of WordPress,” and Calif lists WordPress among the applications where it confirmed pre-authentication code execution in some setups.

That changes who can fix it. A plugin flaw gets fixed when the plugin author ships an update. PHP2Shell gets fixed when whoever runs the server installs a patched PHP build and restarts the PHP workers. Cloudflare’s write-up says updating website code or plugins alone does not fix these flaws, since they are in the PHP runtime. Safeguard makes the same point: WordPress auto-updates will not apply this fix.

On managed and shared hosting, the site owner usually has no way to install PHP packages. You are waiting on your host. So the questions that matter this week are about the host: how quickly it patches, what it does in the meantime, and whether it is still running old PHP versions that will never get an official fix.

What a Good Host Does Before Patches Ship

PHP published source code fixes on October 21. Most hosts do not compile PHP by hand on production servers. They install packages from their operating system or control panel vendor, which have to build, test and release those packages first. Help Net Security notes that Linux distributions and long term support vendors received patches ahead of the public release, while some volunteer package repositories had no update yet at publication. The time between the PHP release and the vendor package is the gap where a host earns its keep.

Here is what we think a responsible host does in that gap:

  • Turn on edge filtering. Cloudflare added emergency rules on October 21 to both its Managed Ruleset and its Free Ruleset, according to the Cloudflare WAF changelog and the Cloudflare blog. Free plans get them automatically. Paid plans should confirm the Managed Ruleset is deployed and set to block.
  • Be honest that filtering is a stopgap. Cloudflare tells customers to patch PHP even with its WAF rules in place. The PHP project says “there are no complete mitigations, updating is the only safe choice,” and Wiz says applying the PHP update “remains the only complete remediation.”
  • Remove PHP versions nobody should be using. Every old PHP build left installed on a server is one more thing to patch, and versions 8.1 and older will not get an official release.
  • Patch the moment packages land. Then restart PHP workers and confirm the running version, since a worker that was never restarted keeps running the old code. Safeguard and Brandefense both advise checking the version the web server actually uses.
  • Watch logs for signs of attack. Wiz suggests looking for unusual multipart requests followed by memory limit errors or repeated HTTP 500 errors, oversized or malformed session cookies, and unexplained worker churn.

What WP Farm Did Today

Here is exactly where we stand as of October 21, 2026.

  • We turned on Cloudflare’s managed WAF rulesets, which include Cloudflare’s new emergency rules for this attack, across the zones we manage.
  • We removed old, unused PHP versions, 5.6 through 8.0, from our servers.
  • Every site we host runs PHP 8.3.
  • cPanel released the fix on October 21 in EasyApache 4 25.91, which ships PHP 8.3.36. The same day it also patched the PHP that runs cPanel itself and its webmail, per the cPanel release notes.
  • We installed both updates, restarted PHP on every server, and confirmed each one now runs PHP 8.3.36. As of 4:55 PM Eastern on October 21, every WP Farm server is patched.

The Cloudflare rules bought time while we waited for the patched package. Now that PHP 8.3.36 is live across our servers, we are keeping those rules on as an extra layer, not as a replacement for patching.

What You Should Do Now

You cannot patch PHP from inside WordPress, but you can confirm where you stand and push your host for answers.

1. Check your PHP version

In wp-admin, go to Tools > Site Health, open the Info tab and expand the Server section. The PHP version entry shows the version your server runs for WordPress. A safe result is 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer. Anything on 8.1 or older needs an urgent conversation with your host.

2. Ask your host when it will patch

Ask three direct questions. When will patched PHP be installed on my server? What protection is in place until then? Are old PHP versions still installed on the server? A host that cannot answer clearly on a day like this is telling you something.

3. Turn on Cloudflare managed rules if you use Cloudflare

If your site sits behind your own Cloudflare account, open the WAF settings for your zone and confirm the managed rules are active. Cloudflare says Free plan customers do not need to take any action, and paid plan customers should confirm the Cloudflare Managed Ruleset is deployed in block mode.

4. Watch for signs of trouble

Odd admin accounts, new PHP files in your uploads folder, or a spike in server errors are all worth a support ticket. Our guide to WordPress site security steps covers the basics, and our post on the Rank Math PRO backdoor walks through what a cleanup looks like when something does get in.

If you want to know how we handle traffic surges and attacks at the edge, our DDoS threat levels post explains how we use Cloudflare across the sites we manage.

PHP2Shell FAQ

Will updating WordPress or my plugins protect me from PHP2Shell?

No. PHP2Shell is a flaw in the PHP engine that runs on the server. Cloudflare and other researchers say updating site code or plugins does not fix it. Your host has to install a patched PHP build.

Is a Cloudflare WAF enough on its own?

No. Cloudflare’s emergency rules block known attack patterns and buy time, and Cloudflare itself tells customers to patch PHP anyway. The PHP project says updating is the only safe choice.

My site runs PHP 8.1. What now?

The PHP project will not release an official fix for 8.1 or older. Ask your host whether it has a vendor backport, and plan a move to a supported version such as 8.3 or 8.4.

Has WP Farm patched its servers?

Yes. cPanel released PHP 8.3.36 on October 21, and as of 4:55 PM Eastern that day every WP Farm server runs it. Cloudflare’s emergency rules stay on as an extra layer.

Talk to Us

If you are unsure how your current host is handling PHP2Shell, run a free WP Farm security test, or contact our support team and we will tell you plainly what we see and what we are doing about it.

Nick Stafford WP Farm Nick founded WP Farm and runs it, along with its sister company SADOS. He has managed WordPress hosting and server infrastructure since 2008, and he writes about WordPress speed, security and hosting from that work.