PHP2Shell: The 14-Year-Old Bug That Took Government Sites Offline

On the night of October 21, the Dutch cybersecurity agency took its own website offline. So did the Port of Rotterdam, the Danish national school platform, every Finnish government public web service, and France’s Interior Ministry sites. Wikipedia pulled systems down; the Internet Archive briefly went dark. None had been hacked — they all chose to disappear rather than find out the hard way.

The reason was a pair of bugs in PHP, a programming language so old and so everywhere that it has quietly become load-bearing for a huge share of the internet. Researchers call the pair PHP2Shell: CVE-2026-109618 and CVE-2026-109619. For roughly 48 hours it looked like the web might have a very bad week.

What PHP2Shell actually is

Both flaws sit in PHP’s core memory handling, and both allow unauthenticated remote code execution. No password. Nothing for the visitor to click. A crafted HTTP request to an unpatched PHP server hands an attacker code execution on the machine — and from there, whatever that machine can reach.

The two work differently. CVE-2026-109618 corrupts state when PHP runs out of memory mid-request, leaving request data half-initialized; cleanup then treats that broken data as valid. CVE-2026-109619 is a use-after-free: request-owned state survives after its memory is freed, and a later request on the same worker can follow the stale reference into it. Both carry a CVSS v4.0 score of 9.2.

The PHP team rated risk highest for Apache running mod_php, because a demonstrated exploit fires before any application code runs. Your maintained WordPress install and patched plugins get no say — the bug sits underneath all of it.

Why this reached 70% of the web

PHP runs roughly 70% to 75% of websites whose language can be identified, per tracker W3Techs. WordPress, Drupal, Joomla, MediaWiki and Magento are all PHP — not a niche runtime, but the floor under half the internet, maintained largely by volunteers.

The vulnerable code path dates back to PHP 5.4.0, released in 2012. Tiffany Farriss, interim chief executive of the Drupal Association, put it bluntly: “All servers using any version of PHP released in the last 20 years will be vulnerable. This issue impacts the majority of the internet.”

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Source patches went out for 7.4, 8.0 and 8.1, but no official binaries, because those branches are end-of-life. If you sit on one, PHP’s advice is explicit: update, or take the system offline.

It is the same shape of story I covered when Chrome dropped support for XSLT — old technology reaching the end of its road, and every site leaning on it forced to scramble. Except this time it is being exploited, not retired.

The AI question nobody answered honestly

Calif, the firm that discovered the bugs, used a large language model on August 1, then spent months turning that into something real. Wiz found the same flaws independently using its Atlas tool plus Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol. Both coordinated through OpenAI’s Hack the Planet initiative.

Wiz’s framing is the one worth sitting with: “Pre-AI, this manual work would be difficult to implement and even harder to scale. With AI, this is no longer a barrier.”

But Calif added the honest caveat, and TechCrunch’s own reporting made the same point — these were found by human researchers, not by models left alone with a prompt. Calif wrote: “No model is simply capable of unearthing ‘all bugs’ with simple prompts. At least for now.”

The uncomfortable part is not discovery but what happens after. Once a patch is public, the diff says exactly what was broken — and in open source anyone can read it. Amazon’s threat intelligence team argues the gap between patch and exploit keeps shrinking, partly because AI-assisted analysis turns a diff into an exploit faster than a human can.

I have written before about the wake-up call around AI security and about Anthropic’s Claude publishing malware to PyPI. PHP2Shell is a different flavour of the same problem: the tooling is faster on both sides, and the defensive side does not move first.

The scramble, and the numbers behind it

Amazon detected an exploitation attempt against its MadPot honeypot network on October 17 — four days before the embargo lifted. It does not know how that actor learned of the flaw. More activity followed within hours of the October 21 release. Amazon’s conclusion was blunt: the flaw “is now being broadly exploited in the wild.”

Cloudflare’s telemetry shows the shape of the response. Chief executive Matthew Prince saw thousands of exploit attempts in the ten hours before disclosure, tens of thousands in the 45 minutes after, hundreds of thousands within two hours, and millions by October 22. PHP published no complete mitigations — only partial workarounds.

Censys counted roughly 1.58 million internet-facing hosts reporting an identifiable PHP version on October 21 — about 1.57 million of them unpatched. CloudLinux, which maintains the Imunify360 firewall used across much of shared hosting, pushed three virtual-patch rulesets and reported a public exploit tool used for mass scanning, while cautioning that no rule blocks the out-of-memory path.

And then, notably, the mass event did not arrive. Dataminr’s TRACE team assessed the activity as mostly scanning and fingerprinting, with no confirmed compromises as of October 22. The Canadian Centre for Cyber Security reported no active exploitation as of October 21, and neither CVE had entered CISA’s Known Exploited Vulnerabilities catalog as of October 23. WatchTowr did see exploitation attempts through its honeypots, and Palo Alto Networks’ Unit 42 and Trail of Bits both reported confirmed compromises by late Friday.

That is a race in progress, not a contradiction. Attackers had the tool; defenders had a head start on the biggest hosts. The long tail — small agencies, shared hosting, solo developers — is where this gets decided.

What this means for Philippine agencies

This is the part that is not academic for me. I manage an ICT division in a Philippine government institution, and most of our public-facing systems are not ours to patch.

CERT-PH, the DICT’s national response team, issued an advisory on the pair (Back End News). Its most important line is the one people miss: “Updating a CMS or website application without updating the underlying PHP installation does not remediate the vulnerability.” That is the trap. Your contractor patches WordPress, sends you an invoice, and the server is still vulnerable because PHP itself was never touched.

The reporting obligations are tighter than most teams realise. The National Privacy Commission requires notification within 72 hours of knowing or reasonably believing a breach has occurred. The DICT separately requires government agencies to remediate critical vulnerabilities within five business days. Amazon’s advice to start hunting from October 17 rather than the disclosure date is the right instinct — the exposure window is not the news cycle.

If you are responsible for a site: inventory every internet-facing PHP install, patch or take offline what you cannot patch, then hunt backward from October 17. Repeated server errors alone do not prove an attack.

What to check this week

• Confirm the version, not the CMS. Ask your hosting provider directly which PHP version the server runs. An answer that names no version is not an answer.
• Patch or isolate. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On unsupported branches, CISA’s advice is to take PHP systems offline until they can be patched.
• Apply the interim controls if you must wait. PHP’s partial mitigations: set memory_limit to -1 where the application cannot override it, reduce post_max_size to 8 MB where uploads are unneeded, and enforce request-size limits at the proxy. These reduce risk; they do not remove it.
• Hunt from October 17. Review logs, session files and outbound connections from that date forward. The upload-progress handler can return freed worker memory to a client inside a session cookie — memory that can hold passwords, session tokens, API keys and TLS keys from other requests.
• Check your dependencies honestly. I have a guide to detecting compromised packages, and a practical security checklist for teams that want a starting point.

The part nobody wants to say out loud

The internet did not break this week. Governments took their own sites offline as a precaution, big hosts patched early, and the mass exploitation everyone feared did not materialise. That is a win worth saying so.

But it is a win built on luck and volunteer labour. PHP is one of many aging, omnipresent technologies — codecs, compression libraries, the rest of the stack from decades ago — maintained by people who are not paid for it, while the companies depending on them do not contribute to the projects. When one of those breaks, the consequences belong to everyone.

The NSA and CISA estimate around 75% of actively exploited vulnerabilities abuse memory-related flaws. PHP is memory-unsafe by design. Moving critical infrastructure to memory-safe languages is the real fix — slow, expensive work that no budget line wants to own.

So the bottom line: patch what you control, verify what you outsourced, and stop treating the foundation as somebody else’s problem. The next one will be found faster — on both sides.