The week the web’s plumbing failed

On Wednesday afternoon, most of the world’s websites became exploitable at the same moment. The reason was PHP, the thirty-year-old language that still serves roughly seven out of ten sites you visit, including nearly every WordPress, Drupal, Magento and Joomla deployment on earth.

Two bugs, CVE-2026-109618 and CVE-2026-109619, now known collectively as PHP2Shell, let an unauthenticated attacker run code on any server that handles PHP web requests. They are present in every PHP version back to 5.4, released in 2012. The coordinated disclosure broke down a day early, after leaks on 20 October. Exploit attempts hit honeypots before a patch existed. Government sites in Europe chose to go dark on patch day rather than stay online and exposed.

I have watched a great many “critical” bulletins come and go. Most of them deserve a calm Tuesday and a ticket in the queue. This one does not, and I want to explain why in business terms rather than technical ones. The technical story will be told well by the researchers who found it, and our own research team at Orca has published its analysis. The business story is the one your board, your CFO and your customers are going to ask you about.

What happened

The two flaws sit in the parts of PHP that every request touches: memory management and error handling. CVE-2026-109618 abuses how PHP bails out of an out-of-memory condition while request data is only half initialised. CVE-2026-109619 abuses global state that keeps pointing at request memory after that memory has been freed. Both are rated 9.2 on CVSS v4 and work without credentials, and both can also be used to read process memory, which is where your database passwords, API keys and session secrets happen to live.

What makes this different from the usual PHP advisory is the discovery story. The out-of-memory weakness was first noticed in 2020 and rediscovered during an audit in 2024. Nobody could prove it was exploitable, so it was never fixed. In August 2026, a small group of researchers, among them Calif and OpenAI, used frontier AI models to build the exploit chain that human researchers had judged impractical. The flaw did not change. The cost of proving it had.

Then the disclosure process came apart. A video with a working proof of concept was published by mistake. A container vendor shipped fixed images six hours before the coordinated release, giving anyone who cared to look a binary diff of the patch. The PHP Foundation pulled its release forward by a day. By the time the fixes landed, proof-of-concept exploits were already circulating and several vendors were watching attempts against their sensors.

When (UTC)What happened
11 Aug 2026The OOM-to-RCE chain is reported to the PHP security team by two independent parties; further attack vectors follow over the next weeks
17 Oct 2026Amazon’s MadPot honeypots record an exploitation attempt, four days before public disclosure
20 Oct 2026CVE IDs leak online; PHP issues a pre-announcement and moves the release up a day; a research team’s exploit video follows that evening
21 Oct, 02:00First public proof-of-concept exploits appear; multiple actors begin probing honeypots
21 Oct, 03:02Cloudflare deploys WAF rules for the known vectors, about eleven hours ahead of the patch
21 Oct, 07:41Chainguard publishes patched container images, more than six hours before the embargo lifts
21 Oct, 14:00PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released; minimal source backports for 7.4 through 8.1; nothing for 5.4 through 7.3
21 Oct, afternoonGovernment websites in Europe taken offline; exploitation reported “at scale” against the session upload-progress path
22 Oct 2026Open-source scanners released; mass exploitation under way

The PHP team’s own position is blunt: there are no complete mitigations and updating is the only safe choice. Configuration tweaks can narrow specific attack paths. They do not close the hole.

Censys counts roughly 2.58 million internet-facing hosts and 54.9 million web properties running PHP. Every one of them that serves web requests, whether through PHP-FPM, mod_php, php-cgi, FrankenPHP or LiteSpeed, is in scope.

Why this one hurts

The first thing to understand is that this is an engine bug, so every WordPress site, Drupal install and plugin inherits it. “Our application code is secure” is a true statement that does not matter. If your code runs on PHP, your code is the delivery vehicle for someone else’s payload.

The second thing is that almost nobody knows how much PHP they run. The flagship e-commerce platform, yes. The marketing microsite the agency built in 2019, the acquired brand’s storefront that was never migrated, the internal wiki, the staging box someone exposed to test a webhook, the customer portal your SaaS vendor runs on a hosting provider you have never heard of: these are the servers that will be compromised. Most of them are not in a CMDB. Many of them are not in anyone’s memory.

The third thing is what the attacker gets. The natural outcome of PHP2Shell is a web shell: a persistent backdoor living inside a legitimate, trusted, SSL-certified site that carries your brand. From there an attacker phishes your customers from your own domain, serves malware from a URL that every security product trusts, and reads credentials out of process memory to pivot into the cloud accounts behind the site. The breach does not look like a breach. It looks like your website.

The fourth thing is the patch itself. For PHP 8.2 and above there is a clean update. For 7.4 through 8.1 there are source backports, which means someone has to compile them. For anything older there is nothing at all. A great many enterprises are running end-of-life PHP underneath applications nobody wants to touch, because the last time someone touched them the site broke. Those organisations are now choosing between a planned outage and an unplanned compromise. That is where the stress in the market comes from this week: a bill for technical debt that was supposed to be deferred indefinitely has arrived all at once.

And the fifth thing is that the regulators are watching. Under NIS2, DORA and the SEC’s four-day disclosure rule, “we did not know we were running PHP” will be read as an admission.

WhoExposureWhat it costs
Companies with modern PHP (8.2+) and a known inventoryPatched within hoursA busy day and a hunt for anything that got in between 17 Oct and the patch
Companies with modern PHP and an unknown inventoryPatched the sites they know aboutWeeks of discovery; the forgotten sites are the ones that get shelled
Companies on PHP 7.x or 8.0/8.1Source backports onlyBuild and test effort, or an emergency upgrade with regression risk
Companies on PHP 5.x or 7.0 to 7.3No fix existsTake it offline, put it behind a WAF and hope, or rebuild
EveryoneVendors and suppliers running PHPDue diligence you cannot do yourself; you are only as patched as your weakest agency

The uncomfortable lessons

This embargo was handled by serious people with months of preparation, and it still leaked through a mistaken video upload and a vendor publishing early. Amazon saw exploitation attempts four days before anyone outside the circle was supposed to know. I would now treat any embargo as a courtesy. Plan on 24 to 48 hours of warning for the next one, and expect that warning to come from a honeypot rather than a mailing list.

The OOM flaw sat unfixed for six years because turning it into code execution looked impractical. Frontier models made it practical, so “not proven exploitable” should no longer be enough to close a ticket. The PHP Foundation has published 15 CVEs since July and says AI-assisted research is sending it far more reports than before. Every mature codebase written in C has a drawer full of bugs that were triaged as theoretical. That drawer is now being emptied, and not only by the people who will tell you about it.

Inventory was the control that mattered on Wednesday. Everyone was vulnerable, so the useful question was where PHP was running. The organisations that could answer that in minutes were patched within hours. The ones that could not are still discovering what they own, and they are discovering it in the same order the attackers are.

The sites that cannot be patched today were kept on old PHP because upgrading looked expensive and the risk looked abstract. For years that was a defensible trade-off. This week the risk became concrete, and the upgrade belongs on this quarter’s plan for anyone still running end-of-life runtimes on internet-facing systems.

The maintainers are carrying us. A handful of people at a foundation spent ten weeks fixing the engine that runs seventy percent of the web, under embargo, while watching that embargo fail around them. That arrangement held while bugs surfaced slowly. It will not hold once AI finds them faster than volunteers can fix them. Every enterprise that depends on PHP and does not fund the PHP Foundation is taking a free ride on infrastructure it would never accept for its own data centre.

What to do now

The next 72 hours are about containment. The next quarter is about never being in this position again.

In the next 72 hours

  1. Find every PHP runtime you own, not every application you remember. Scan from the outside in. Include container images, serverless functions, appliances with embedded web interfaces, the marketing stack, acquired brands and anything an agency ever built for you. If you run Orca, the PHP2Shell news item in the platform includes a query that lists every asset with a PHP package installed across your connected cloud accounts.
  2. Patch everything on 8.2 or later today, without waiting for a change window.
  3. For 7.4 through 8.1, compile the backports or upgrade. For anything older, take it off the internet or put it behind a WAF with the PHP2Shell rules enabled, and accept that this is a bandage.
  4. Assume compromise for any internet-facing PHP host that was unpatched after 17 October. In Orca, the PHP2Shell alerts flag which vulnerable hosts are reachable from the internet, so start there. Hunt for web shells, new admin users, modified core files and outbound connections you did not expect.
  5. Rotate every secret that lived in PHP process memory on an exposed host: database credentials, API keys, cloud access keys, signing secrets.
  6. Ask every vendor, agency and SaaS provider that touches your data the same question: which PHP version, patched when, and what did you find.

In the next quarter

  • Retire end-of-life PHP from anything internet-facing, with a budget line and an owner. If the application cannot move, treat the application itself as the risk.
  • Get secrets out of process memory. Short-lived credentials, workload identity and a secrets manager mean that the next memory-read bug leaks tokens that expire in an hour instead of keys that last for years.
  • Put an edge in front of everything. A CDN or WAF that can take a virtual patch in minutes bought the well-prepared organisations about eleven hours this week, which is often the difference between a hunt and a breach.
  • Create a pre-authorised emergency change path. The companies that patched within hours had already agreed, in calm times, who can push a change to production without a meeting.
  • Prioritise by exposure, not by CVSS. Two 9.2s on an internal admin tool behind a VPN are a Thursday. The same two on a public storefront holding card data are a board call. Your tooling should already know the difference.

How Orca can help

Most of the first 72 hours goes on finding out what you own, and that is where Orca starts. Orca’s agentless SideScanning reads installed packages directly from cloud workloads, so PHP is found on virtual machines, containers and container images without anything to deploy first. Detection for both CVEs went live in the platform on 21 October.

Finding PHP answers half of the question. The other half is deciding what to patch first and what an attacker could reach from each host. Each PHP2Shell alert shows whether the asset is reachable from the internet, whether the vulnerable component is loaded at runtime, and how critical it is to the business.

For the hunt and the clean-up, Orca’s lightweight eBPF Sensor adds runtime visibility on the hosts where it is deployed, and the asset graph shows which keys and cloud roles each exposed host holds, and that is where secret rotation should start. 

Several customers told us the Early Intel query in the platform’s From the News item gave them a head start, letting them find their PHP hosts and begin mitigating before the official advisory went out.

None of this replaces patching. It shortens the time between the advisory and knowing where to patch first.

What this means for the next two years

PHP2Shell is the first widely visible instance of a pattern that will define vulnerability management for the rest of this decade.

AI has collapsed the cost of turning a theoretical bug into a working exploit. The backlog of “unproven” memory-safety issues in the foundational C codebases of the internet, the interpreters, the TLS libraries, the image parsers, the web servers, is enormous, and it was accumulated in an era when proving exploitability took a specialist a month. That era ended this summer. Expect the same story, with different names, in Python, Ruby, Node, OpenSSL and the kernel. Expect it more than once a quarter. Every CISO should assume their foundational dependencies have critical bugs. What they can still influence is whether they hear about them through a coordinated advisory or through an incident.

The window between disclosure and mass exploitation is now measured in hours, and sometimes it is negative. Monthly patch cycles were designed for a world where attackers needed weeks to weaponise a bug. For anything that faces the internet, that cadence is obsolete. The operating model that survives this decade treats patching exposed systems as a continuous process with a pre-approved fast lane, and treats a virtual patch at the edge as the normal first response rather than an exotic one. It also depends on an inventory that can answer “where do we run X” in a minute, across cloud, on-premises, containers, vendors and the long tail of forgotten sites.

If there is a single takeaway, it is about time. The weakness had been in PHP since 2012, the working exploit was about two months old, and the response had to happen within hours. The organisations under the most stress this week are the ones whose decision-making was built for a slower world, whatever the quality of their security teams. Most of what fixes that is deciding things in advance, so that the answers already exist before the next disclosure.

Sources