Critical PHP vulnerabilities: what happened, and how we protected our clients
Boudino de Jong (Head of Innovation & AI at Profound), Karim Sawda (Tech Lead), Chris Gil (Senior Developer) & Derek Sjak-Shie (Senior Developer)•7 min read•October 21, 2026
By Boudino de Jong, Head of Innovation & AI at Profound, with Karim Sawda (Tech Lead), Chris Gil (Senior Developer) and Derek Sjak-Shie (Senior Developer) | 21 October 2026
On 20 October, news of two critical vulnerabilities in PHP began circulating before the people responsible had planned to announce them. Details leaked that day, ahead of the coordinated disclosure. By the next afternoon, hospitals, government portals, broadcasters and charities across Europe had taken websites offline as a precaution. This is what happened, why it mattered, and how we handled it for the WordPress sites in our care.
What happened
A post on Hacker News claimed that two critical PHP flaws were about to be disclosed. It was taken down, but screenshots had already spread, and security researchers confirmed the flaws were real. The PHP project had announced that a fix would follow on Wednesday, which is standard practice so everyone can prepare. In this case, hackers used the announcement to locate the flaw and published information about it.
CERT-EU published an advisory, and PHP scheduled an emergency release. Both flaws were rated 9.2 on the CVSS v4.0 scale. The patch was published at 15:43 Dutch time on 21 October, slightly earlier than announced. Researchers refer to the issue as PHP2Shell.
A flaw deep in the PHP interpreter left millions of websites exposed, regardless of the CMS they run on.
Why it was so serious
The flaws could let an attacker run code on a server remotely, without logging in. They sit in the PHP interpreter, the component that translates a programmer’s commands into something the computer understands. That is why WordPress, Drupal, Joomla, Magento and Laravel sites were all exposed, and why updating a CMS or its plugins could never have fixed it. The fix has to happen on the server.
The scope was uncertain at first. CERT-EU said all versions from PHP 5 onward could be affected, and PHP had not confirmed which versions were. Only PHP 8.2 and newer were expected to receive a fix. The Dutch National Cyber Security Centre (NCSC) put the risk plainly (translated from Dutch):
“Any system containing PHP and reachable from the public internet is presumably vulnerable.” — NCSC, the Netherlands
How the world responded
The scale of the precautionary shutdown was unusual for a software flaw. DigiD and MijnOverheid went down, as did the Dutch House of Representatives, RTL, and several hospitals. Charities such as KWF, the Heart Foundation and Amnesty took their sites offline, and the Schiphol app stopped showing live flight data. All Flemish government websites went offline, and French authorities took prefecture sites down.
The official stance was measured. The NCSC’s deputy director said this was not an attack but a flaw in software. She added that a patch ideally exists before a vulnerability becomes public, which was not the case here, so every minute counted. Going offline after a risk analysis was an alternative, left to each organization.
On abuse, the picture differed by vantage point. Cloudflare reported attacks already trying to exploit the flaws. The NCSC and the Dutch government had seen no active abuse, and the PHP Foundation said it saw no indication of it either. NOS noted that no concrete cases of hacked sites or leaked data were known, but expected some to follow.
Recovery began within about an hour of the fix. The first affected sites, among them RTL and Tweakers, were back online by early evening. The shutdowns had a cost, though. The Dutch Minister of Justice and Security said that so many sites going offline had an impact on the digital society.
What made this one different
Two things stand out. First, a responsible heads-up turned into an exposure window of several hours. Until the fix arrived, there was no permanent solution, and filtering suspicious traffic could not fully stop attempts, which is why many owners chose to go offline. Disabling interactive features such as logins and uploads was another option for information-only sites.
Second, speed. AI makes it easier and faster to find flaws like these, and the ethical hackers who first reported them also used AI. Defenders now have less time between a leak and exploitation, which puts a premium on preparation.
How we handled it
Profound manages more than 250 WordPress environments, hosted with our long-term partners Pressable and Cloudways. Because this vulnerability sits below WordPress, our response started with the hosting layer and with knowing exactly what we run.
Inventory. We mapped every environment we manage, including its hosting location and PHP version.
Pressable. We have worked with Pressable for more than a decade. They told us they worked directly with the PHP team and applied the fix across their platform before the official release, covering all sites regardless of PHP version. We keep our own priorities on top of that: verifying the sites ourselves, starting with business-critical and public-sector environments.
Cloudways. Cloudways put temporary, partial mitigations in place to reduce exposure, and began emergency patching of its own platform as soon as the fix became available. The patching of customer environments follows its own rollout, which we are tracking per environment and verifying one by one. For deprecated PHP versions, Cloudways is working with extended support partners on security coverage.
Communication. Every client we manage receives a direct update about their own sites, and we have posted live updates throughout the day.
After the patch: what still needs attention
Patching closes the hole, but it does not remove anything an attacker already planted. Security researchers advise looking for suspicious child processes spawned by PHP, new files in the web root, new scheduled tasks and new accounts, and preserving logs if something is found. Because there was an exposure window between the leak and the patch, we are checking environments for signs of compromise, not only confirming that they are patched.
Older sites are the next concern. Environments running end-of-life PHP versions may never get a fix, and should be upgraded or protected until they can be. Small companies and hobby sites that update late are expected to remain the most exposed in the coming period. History suggests the danger lingers: an earlier critical PHP flaw from 2024 was still seeing large attack spikes months after disclosure.
Five questions to ask your hosting provider
- Has the PHP fix been applied, and is it the official patch or a mitigation?
- Does it cover every site, regardless of PHP version?
- Which of our environments run end-of-life PHP versions?
- Has anyone checked for signs of compromise during the exposure window?
- Can you confirm all of this in writing?
If you are unsure about the answers for your own website, we are happy to look at it with you. Get in touch with us.
