PHP shipped its emergency patch on Wednesday, and some attackers appear to have gotten there first. Details of two critical flaws leaked a day earlier, Cloudflare reported attack attempts hours before the fix landed, and PHP pulled its release date forward. The bugs go by PHP2Shell. They matter well beyond developers, because PHP powers a large share of the web, WordPress included. If you have a website, the PHP2Shell patches probably concern you.
What PHP2Shell is

Two vulnerabilities make up PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on a web server without logging in, and PHP’s own advisory scores each one 9.2 on the CVSS v4.0 scale. Most security stories involve a plugin or an app. This one lives in the engine underneath them, which is why the fixes come from PHP itself.
Early reports don’t quite agree on how the bugs work. PHP says the first one is about memory running out partway through a request, which leaves some internal data half-built. The second, per PHP, lets leftover state from one request bleed into the next. One outside write-up describes the first bug as a memory leak that can spill passwords and API keys. PHP doesn’t use that description, so treat it with some caution.
PHP says Apache’s mod_php is the riskiest setup. One unauthenticated request can trigger the attack before your own code gets a chance to run. Other setups aren’t off the hook, either. BleepingComputer lists PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed as affected.
How it leaked and when attacks began
The timeline is the unsettling part of PHP2Shell. Sansec says researchers at Calif found the code-execution paths on August 1 and started telling PHP on August 11. Wiz followed with its own report on August 24. Then, on October 20, details leaked publicly and watchTowr confirmed the flaws were real. PHP responded with an advance notice and a release set for 14:00 UTC on October 21.
Attackers may have gotten there first. Sansec says Cloudflare spotted early attempts at 07:43 UTC on Wednesday, roughly six hours before the patch. Help Net Security reports something earlier still: Amazon’s MadPot honeypot logged an attempt on October 17, four days before disclosure, from an address tied to a commercial anonymization service. Amazon suspects a threat actor, and nobody has explained how that actor would have had details so soon. watchTowr and Huntress, for their part, saw nothing earlier in the week.
Which versions to update

The fixed builds are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, plus the 8.6.0 release candidate. PHP’s advice is blunt: there’s no complete workaround, and updating is the only safe choice. Here’s the catch. PHP 8.1 and older get nothing from the project anymore, though it did put out minimal source backports for 7.4, 8.0, and 8.1. Some Linux distributions and long-term support vendors ship their own patched builds too.
Old servers are the bigger concern. Sansec says the vulnerable code dates to PHP 5.4, from 2012. On October 20, Mallory counted about 884,000 internet-facing hosts whose banners claimed PHP 8.1 or older, The Hacker News reports. That’s roughly 59% of hosts that reported a version. Banners are blunt, though. Plenty of servers hide their version, and a banner doesn’t prove anything is vulnerable. VirusTotal’s estimate runs far higher: more than 5.1 million exposed PHP hosts, per BleepingComputer.
What PHP2Shell means for WordPress and other sites
A site can be fully up to date and still be exposed. Sansec says researchers showed unauthenticated code execution against WordPress, Drupal, Joomla, Magento, and several other well-known PHP applications. Updating a plugin won’t help, since the problem sits underneath all of them.
A small shop on shared hosting is in a different spot from a company running its own servers. The shop waits on its host’s patch calendar. The company owns the problem outright. The first move is the same for both, and it takes one email: which PHP version is my site running, and when was it last updated?
Managed WordPress hosts usually patch PHP on their own schedule, so ask whether the fixed version is live. Running your own server? Update PHP through your distribution’s packages or build from source, then restart every PHP worker. WordPress shows the PHP version under Site Health, so a quick check is easy.
When patching has to wait
PHP lists stopgaps for anyone who can’t update right away, like turning off upload progress tracking and capping request sizes. It also warns that none of them make a server safe. The UK’s National Cyber Security Centre told organizations to update at once or take affected systems offline until they can. Cloudflare has pushed temporary firewall rules to all customers, free plans included. Think of those as a delay. They only cover attack patterns known so far.
Suspect a server was hit before the update? Isolate it, keep the logs, and look for new files in the web root, scheduled jobs you don’t recognize, and accounts you didn’t create. Credentials sitting in server memory could be exposed in a worst case, so rotating passwords and keys after patching is reasonable. Our guide to setting up passkeys covers one way to blunt a stolen password, and our piece on the Ivanti Connect Secure vulnerability shows how quickly attackers move once a flaw is public.
What to watch next
Three things to watch. Whether major hosts and Linux distributions confirm patched packages are live, since some repositories lagged on release day. Whether the Cybersecurity and Infrastructure Security Agency lists either flaw as exploited. And whether PHP2Shell scanning turns into mass compromises of sites on older PHP. Sansec expects mass exploitation now that the patch and write-ups are public. That’s a forecast, not something observed.
Editor’s take
This is less about one bug than about how many sites run unsupported PHP. A leak, a one-request attack, and attempts underway before the patch is the worst version of a familiar story. If your host can’t tell you which PHP version you run today, fix that this week. The next flaw like PHP2Shell will find the same old servers.








