On 21 October 2026 the PHP project shipped emergency patches for the two flaws now known as the PHP2Shell vulnerability. Within a week, government websites in several countries had been deliberately taken offline, a US government-affiliated network had been breached, and hosting companies had spent two nights pushing updates across entire fleets of servers.
Here is what actually broke, who moved first, and how to check your own site in about two minutes.
What the flaw lets an attacker do
CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0, allow unauthenticated remote code execution. An attacker needs no login and no interaction from anyone. On a vulnerable server, a crafted request can run code before your application does.
CISA’s advisory lists the affected configurations as essentially every PHP installation serving web requests: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the highest risk of those.
How much of the internet was exposed
Palo Alto Networks’ Cortex Xpanse counted over 22.6 million exposed instances potentially vulnerable. Read that carefully: exposed and potentially vulnerable is not the same as compromised, and we have not seen a credible count of actual breaches.
The reason the number is so large is simply what PHP is. W3Techs puts it at around 75% of websites whose server-side language can be identified. Other outlets covering this story quoted 69% and 70%, so treat the exact share as approximate — but the order of magnitude is the point. WordPress, Laravel, Drupal, Joomla and most of the shared hosting industry all sit on top of it.
What actually broke
Governments pulled their own sites down
The most visible damage was self-inflicted, and deliberately so. Rather than gamble on being patched in time, government teams took public services offline while they updated.
Reporting describes precautionary shutdowns in France, Denmark, Finland and the Netherlands — including the Dutch cyber security agency’s own site. Coverage also pointed to roughly three dozen UK government services unavailable and four partially unavailable during security upgrades, with Germany and Belgium mentioned in some accounts. Wikipedia was reported offline in some regions during the scramble.
Those outages were not attacks. They were a judgement that a few hours of downtime beats an unknown number of hours of compromise.
A real breach, with AI in the toolkit
Researchers at Dream and Unit 42 described a campaign that rooted around 25 PAN-OS firewall and management servers across the US, Japan, Taiwan and South Korea, and moved against Active Directory inside a US government-affiliated network. They attributed it to a suspected China-nexus actor. One report says 24 servers rather than 25.
The attackers’ infrastructure reportedly included Anthropic’s Claude Code, FOFA API keys and an AI-driven offensive platform called aiscan — which is what the “AI-assisted attack” headlines were referring to.
Note the irony worth keeping in view: the compromised machines were firewalls. Security appliances run PHP too.
One report that was withdrawn
Unit 42 published a report on 23 October linking an intrusion to PHP2Shell, then retracted it after being unable to confirm that the initial access came from these CVEs. If you read something alarming in the first few days of this story, it is worth checking whether it still stands.
The response, in order
- 20 October, evening — details leak via a Hacker News post, later removed. The PHP security team pushes an advance notice to php.announce the same evening.
- 21 October — the PHP2Shell patch ships: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus minimal source backports for the end-of-life 7.4, 8.0 and 8.1 branches. CISA issues its alert the same day.
- 21 October — cPanel ships EasyApache 4 release 25.91, covering PHP 8.2 to 8.5 with backports for 7.4, 8.0 and 8.1. PHP 7.3 and older get nothing.
- 22 October, 03:34 UTC — Hostinger reports finishing its cPanel fleet. It had already disabled upload progress on its LiteSpeed, PHP Selector and cPanel PHP-FPM setups and on phpMyAdmin, and put ModSecurity rules into deny mode as an interim measure.
- 26 October — CISA adds both CVEs to its Known Exploited Vulnerabilities catalog, confirming exploitation in the wild.
- 27 October — researchers report successful exploits; the NSA advises organizations to patch immediately or take affected systems offline until they can.
Who moved fastest
Credit where it is due, because the gap between providers was real.
- The PHP security team went from public leak to shipped patches in roughly a day, and supported three branches they had no obligation to support.
- Control panels — cPanel, Plesk and DirectAdmin all shipped. cPanel and Plesk also produced builds for the end-of-life 7.4, 8.0 and 8.1 branches.
- Hosts reported complete by late October included Hostinger, Cloudways, DreamHost, Flywheel and OVHcloud.
- Hosts still rolling out at that point included Liquid Web; Bluehost said most of its fleet was done with mitigations on the rest; InMotion had dedicated servers finished and VPS in progress.
- Cloudflare deployed WAF rules against known exploit methods for free and paid plans alike — while reporting that attackers were already changing payloads to get around them, and still telling people to patch.
- AWS addressed it in Elastic Beanstalk, WorkMail, Amazon Linux and Lightsail, but stated plainly that it cannot patch running Lightsail or EC2 instances. Those customers had to update PHP themselves or rebuild.
- TuxCare produced patches reaching back as far as PHP 5.2 for organizations stuck on ancient branches.
One detail from CloudLinux puts the whole mess in perspective: PHP fixed four versions, while hosting servers in the real world run about sixteen. That gap — between what upstream supports and what is actually deployed — is the thing that turns a patched bug into a long tail of vulnerable sites.
Check your own site in two minutes
You do not need to understand the exploit to apply the PHP2Shell patch. You need to know one number: your PHP version.
Patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or newer on those branches.
- On WordPress: go to Tools → Site Health → Info → Server and read the PHP version.
- On any host with a control panel: look for a PHP version or PHP selector screen.
- From a shell: run
php -v.
Then compare against the list. If your branch is 8.3, you want 8.3.36 or higher. If you are on 8.1 or older, that branch is past end of life — you are relying on a backport from your host or vendor, and the right move is to plan an upgrade rather than hope.
Two things worth knowing if you are on shared hosting. First, your host almost certainly patched this for you without asking — most of the industry did it within 48 hours. Second, a control panel sometimes lets you select an older PHP version per site, so a patched server can still be running an unpatched branch for your account. Check the version your site reports, not the one the server has available.
On mitigations: several hosts disabled session upload progress as an interim measure, and you will find configuration workarounds posted around the web. The PHP team’s own position was that no mitigation is complete and updating is the only safe fix. Treat workarounds as something to do while you patch, not instead of it.
If you think you were hit
Patching closes the door. It does not undo anything that happened while the door was open. If your site was on a vulnerable version and exposed during that window, patching alone is not a clean bill of health.
- Look for files you did not create, especially PHP files in upload directories.
- Check for admin accounts nobody recognizes.
- Check scheduled tasks and cron jobs.
- Rotate database passwords, API keys and admin passwords.
- If anything looks wrong, restore from a backup taken before 20 October rather than trying to clean in place.
For most small sites the realistic answer is that nothing happened: the automated scanning that followed this disclosure was broad, but the confirmed targeted attacks were aimed at infrastructure, not at a local business’s brochure site. That is a reason to check calmly, not a reason to skip checking.
The part worth remembering
The flaw sat in PHP for about fourteen years before anyone found it, and it was found with AI assistance. We told that side of the story — including what the people involved did that no model did — in how an AI found a 14-year-old bug in PHP.
The operational lesson is duller and more useful: the sites that sailed through were the ones on a supported PHP branch with a host that patches quickly. Not the ones with the cleverest security plugin. Staying on a current version is unglamorous, invisible work, and it is most of what protected people here.
Sources
Drawn from CISA, the UK NCSC, Unit 42, Help Net Security, BleepingComputer, SecurityWeek and CloudLinux. Provider patch status came from third-party trackers dated between 22 and 28 October 2026 and may have changed since — check your own host’s status page before relying on it.