NEWS
You Can't Patch What You Can't See: Lessons from the PHP2Shell Vulnerabilities
October's critical PHP flaws took councils, police and banks offline. Here's how it happened, why it will happen again, and how to be ready.
6
MIN READ
On 21 October 2026, organisations across the UK started taking their websites offline on purpose.
Council sites in Edinburgh and Oxford went dark. So did the Metropolitan Police site. Banks, retailers and hospitals elsewhere did the same. They weren't under attack yet. They were racing to patch two critical flaws in PHP, the language behind around 70% of websites whose server-side technology can be identified.
The flaws, nicknamed PHP2Shell, let an attacker run their own code on an internet-facing server. No password was needed, and nobody had to click anything. Five days later, US authorities confirmed attackers were actively exploiting them.
This post isn't a patching guide. That moment has passed, and your vendors will have one. Instead it looks at why an event like this catches so many organisations out, and what to put in place before the next one.
What happened, briefly
2024: The two underlying bugs were found but judged not to be exploitable, so they weren't fixed.
2026: Researchers auditing PHP found a way to exploit them and reported it privately to the PHP Foundation.
17 October: Amazon later reported possible exploitation from this date, days before any public fix.
20 October: Details leaked online ahead of the planned disclosure.
21 October: PHP released patched versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35). The NCSC told UK organisations to update immediately, or take affected systems offline if they couldn't.
26 October: CISA confirmed active exploitation and gave US federal agencies three days to fix.
Each flaw scored 9.2 out of 10 for severity. Palo Alto Networks' Unit 42 counted more than 22.6 million internet-facing systems that could be vulnerable.
Why this keeps happening
Old bugs don't stay harmless. These flaws sat in the code for two years because they looked unexploitable. Better tooling, including AI-assisted analysis, keeps turning "theoretical" into "working exploit". Anything you once marked low risk deserves a second look.
Memory safety is still the root cause. Both flaws come from how PHP manages memory between requests. The NSA estimates that around three-quarters of actively exploited vulnerabilities involve memory-safety issues. Much of the internet still runs on code written before memory-safe languages became the norm.
Disclosure windows are shrinking. The fix was due under embargo, but details leaked a day early and exploitation may have started days before that. The gap between "announced" and "attacked" can now be close to zero.
You're running PHP in places you don't know about. This is the real problem. PHP doesn't only power your website. It sits inside content management systems, control panels, developer tools, and the admin interfaces of routers, storage devices, firewalls and VPNs. Many teams lost days in October just working out where they were exposed.
The part you can control: knowing what you run
When a critical flaw drops, the organisations that cope are the ones that can answer three questions in minutes, not days:
Where is the affected component? That means every server, appliance and application, including software bundled inside vendor products.
Which version is it? "PHP" isn't enough. You need the exact branch to know whether a patch exists, or whether you're on an unsupported version like 8.1 or older.
What is it connected to? An exposed admin panel on a firewall is a very different risk from a brochure site behind a web application firewall.
This is a software supply chain problem as much as a patching one. Your code depends on languages, libraries and packages you didn't write and may not have listed. Tools that scan repositories and generate a software inventory, such as GitLens, give you that list before you need it. They flag outdated dependencies, known CVEs and exposed secrets repository by repository.
What to do now, and before the next one
If you haven't already:
Confirm every PHP installation is on a patched version, including those inside third-party appliances. Check with your vendors directly.
Where you can't patch, apply PHP's published mitigation (session.upload_progress.enabled = Off), or take the system off the internet.
Look back for signs of compromise from 17 October onwards. Watch for web server processes spawning shells or download tools, new files in the web root, and new scheduled tasks or accounts.
For the next one:
Keep a living asset and software inventory. Know which components and versions you run, and where.
Treat end-of-life software as a known risk. Unsupported versions don't get fixes. Budget the upgrade before an incident forces it.
Reduce exposure by default. Admin interfaces and management panels shouldn't face the open internet.
Monitor behaviour, not just signatures. A web server that suddenly starts running system commands is a red flag, whatever the exploit.
Rehearse the response. Decide in advance who can take a public service offline, and how fast.
Compliance won't save you here
A valid certificate on the wall told nobody whether their routers were running a vulnerable PHP build. As we argued in Why Compliance Doesn't Equal Security, an audit is a snapshot, and events like PHP2Shell happen between snapshots. Real resilience comes from visibility you can call on at any time.
How CDS can help
CDS builds security technology for defence, government and critical infrastructure. Visibility is at the core of everything we do. Our cyber security team helps organisations map their exposure and harden what faces the internet. GitLens gives development teams a dependency and vulnerability inventory for every repository.
The next critical flaw is already in someone's code. Talk to our team about being ready when it's found.
