The Elephant in the Server Room

Executive Summary

On October 21, 2026, the PHP project shipped emergency releases for two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell — that allow an unauthenticated attacker to run code on a web server before the application’s own code even starts. PHP powers roughly 70% of the websites whose server-side language is known. The flaws sit in the engine itself, so a WordPress blog, an e-commerce store, a Laravel API and a bare “Hello World” page are all exposed in the same way.

The researcher who found the first of these bugs did it in days, not years — with a commercially available AI model and a good memory for PHP’s history. The underlying weakness had been flagged in 2004, re-reported in 2020, and rediscovered in a 2024 audit, each time filed under too hard to exploit. That category no longer exists. Nothing hidden in a codebase will stay hidden, and the same light that shows defenders the flaw shows attackers the patch.

Part I: What Happened

A disclosure that did not go to plan

The story reached the general public on the morning of October 21, when The Wall Street Journal ran an exclusive by Robert McMillan under the headline “AI Just Found A Bug That Puts Up to 70% of the World’s Websites at Risk.” According to the Journal’s reporting, the vulnerabilities were discovered by Ryan Austin, a researcher at the security firm Calif, working with OpenAI’s GPT-5.6 Sol during an audit of PHP’s source code in August; Calif’s chief executive, Thai Duong, called Volker Dusch of the PHP Foundation on August 11 to report a serious issue; and the fix was originally scheduled for October 22 before a leak forced it forward by a day.

The primary sources — published by the PHP project, the PHP Foundation, Calif, Wiz and OpenAI within minutes of the Journal’s story — confirm that account and add the detail that matters.

What the bugs are, in two sentences

PHP’s interpreter is written in C, and both vulnerabilities live in the part of the engine that nearly every request touches: memory management and error handling. In php.net’s words, one bug lets an out-of-memory error interrupt PHP “while internal request data is only partially initialized,” and the other lets request-owned state “survive after its backing memory has been freed” so that a later request can use it. Both are rated CVSS v4.0 9.2; both can be reached by an unauthenticated request; both are fixed in the four releases above.

Three facts from the advisories matter more than the mechanics:

• It is below the application. The flaw is in the runtime, not in any CMS or framework, so clean application code does not help. The researchers demonstrated it against the most widely deployed PHP applications precisely to make that point.
• It is old. The earliest affected code dates to PHP 5.4 (2012). The PHP project supports only 8.2 and later; for 8.1 and older there is no project update, only minimal source backports and whatever your distribution or LTS vendor provides.
• Updating is the only complete fix. php.net lists a few configuration changes that reduce exposure to specific paths, and states plainly that none of them makes an installation safe.

Part II: The Economics of Exploitability

The flaw was never hidden. It was ranked.

The most uncomfortable sentence in the whole disclosure comes from the PHP Foundation’s own post-mortem, published the same afternoon as the patch. Explaining why a problem spotted in 2024 was still open in 2026, the Foundation describes a security team weighing several competing fixes — each carrying compatibility breaks, denial-of-service risk, or changes to a large ecosystem of third-party extensions — and, without a known path to remote code execution, a decision process that “stalled and restarted repeatedly over months.” Its verdict on itself: “the delay was a structural failure.”

This is not a story about negligence. It is a story about a triage rule that was correct for twenty years and is now wrong. Every mature engineering organization runs on the same rule: severity equals impact times likelihood, and the likelihood of a memory-corruption bug nobody can demonstrate is low. Esser could not prove it in 2004. The 2020 reporter did not try. The 2024 audit theorized it and moved on to findings with clear impact. The bug was never secret. It was ranked — and it sat exactly where every unproven memory bug in every C codebase sits today: in the archive, below the line.

Then the likelihood term collapsed

What changed in the summer of 2026 was not the code. It was the price of proof.

Calif’s account is deliberately unglamorous. “No special harness, or access to models that weren’t generally available to everyone were used in the initial bug discovery,” the firm writes, adding that the result came from knowing the target’s history and asking the model the right questions. Wiz, which found the same class independently three weeks later, draws the economic conclusion: “a single researcher completed in a week what previously would have taken a world-class team months of work.”

That is a γ-sized change, to borrow from an earlier thesis on this site — not a 20% improvement in a security team’s throughput, but an order-of-magnitude drop in the cost of turning a theoretical flaw into a demonstrated one. And it did not arrive overnight. PHP2Shell is the largest entry so far in a sequence that has been building for two years:

The pattern across the table is the same as the pattern inside PHP: old code, known weak spots, exploitability never demonstrated — until a model made demonstration cheap. Microsoft and the Chromium team have each reported for years that roughly 70% of their serious security bugs are memory-safety issues. Every one of those codebases has an archive of “unproven” reports. OpenAI’s disclosure post says it plainly: these bugs “are among several significant vulnerabilities we’ve already found,” and the company expects “similar findings to increase sharply in the coming months.”

The flood is the other half of the story

The same capability that found PHP2Shell is burying the people who have to fix things. The PHP security team reports publishing 15 CVEs since July 1 while working through more than 100 reports that were invalid, duplicate or unreproducible. curl’s maintainer shut down a bounty program that had paid over $100,000 because signal had fallen below 5%. The PHP Foundation’s post ends not with a victory lap but with a funding appeal: tools can find bugs, but deciding the right fix for a design decision made in 2004 “takes experienced engineers who know the entire PHP codebase, and today there are too few of them.”

That asymmetry — discovery becoming nearly free while remediation stays expensive and human — is the defining fact of software security for the rest of this decade.

Part III: The Race After the Patch

A patch is a starting gun

Every patch is also a map. The moment a fix ships, attackers compare the new code with the old, see what changed, and work backward to the weakness. This has always been true; what AI changes is the speed. An academic study in 2024 found that GPT-4, given a CVE description, could exploit 87% of a set of real one-day vulnerabilities. Anthropic reported this spring that its Mythos Preview succeeded in more than half of its attempts to weaponize recently patched flaws. Google’s threat-intelligence group counted exploited vulnerabilities rising from about 10.5 per month in 2025 to 18 per month in the first eight months of 2026, and attributes much of the growth to faster weaponization of already-patched bugs.

The long-run numbers tell the same story:

Average time from patch to first exploitation

Days · negative means exploitation preceded the patch

Heartbleed, with a larger surface and a shorter fuse

The PHP Foundation’s security engineer compared PHP2Shell to Heartbleed, the 2014 OpenSSL flaw, and the comparison is instructive in both directions. Heartbleed affected about 17% of SSL web servers, roughly half a million trusted certificates. A month after the patch, scans still found more than 318,000 vulnerable servers; two and a half months later, about 309,000. The world patched what it could reach quickly, and then stopped.

PHP2Shell’s surface is roughly four times larger. And by our arithmetic on W3Techs’ version data, about half of all PHP sites run a branch the project no longer updates — which means the fix, for them, depends on a distribution backport, a hosting provider, or a migration nobody has scheduled. The long tail of Heartbleed was measured in years. There is no reason to expect this one to be shorter.

What is shorter is the window in front of the patch. OpenAI’s disclosure post introduces the phrase that will likely define this era of security: “To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender’s Window.” That window was planned at two days of advance notice. The leak shrank it to hours, and Cloudflare reported attack traffic against its customers before the official release.

Part IV: Where the Loss Actually Lands

The web tier is the door. The database is the room.

Public coverage of PHP2Shell is about web servers, and the patch is about web servers. But nobody breaks into a web server to own a web server. In every real intrusion, the runtime is the door; the asset behind it is the data.

By design, a PHP worker holds the credentials to the application’s database — in a configuration file, an environment variable, a connection string. Compromise the runtime and you inherit the application’s database identity, with every permission that identity was granted. Wiz notes that memory exposed by these bugs “may contain passwords, authentication tokens, API keys and certificates” belonging to other requests or the server itself. The attacker who gets in through PHP walks out through the database.

That is why the actual damage of a vulnerability like this is decided long before the vulnerability is found. It is decided by schema and privilege choices made at design time, usually by a small team under deadline pressure, and never revisited:

None of these are PHP problems. All of them are data-architecture problems, and all of them are visible in the schema before any attacker arrives. This is the layer where Thor ThunderScan does its work: the Security & Compliance scan inventories PII and PHI columns, encryption gaps, over-privileged roles, missing audit trails and orphaned data across a production schema, and turns them into remediation scripts. A runtime patch closes one door. A least-privilege, encrypted, well-partitioned schema is what makes the room behind it worth less to whoever comes through the next one.

Part V: Action Plan for Founders and CTOs

Final Thoughts: Three Elephants

There are three elephants in this story.

The first is PHP’s own mascot, the elePHPant, and it stands for the software we all run and never think about — the runtime, the library, the dependency that was there before the company was founded and will be there after the current team leaves. Most of the web’s risk is not in the code you wrote. It is in the code you inherited.

The second is the elephant in the room: the industry’s quiet agreement not to talk about memory-unsafe foundations as long as nobody could prove they were exploitable. For twenty years that agreement held, because proof was expensive. The economics of proof have changed, and with them the terms of the agreement.

The third is the oldest proverb about elephants: they never forget. Neither do models. Every bug report, every audit note, every “theorized but unproven” finding in every public codebase is now in the training data and in the context window. What the industry filed, the models remember.

Sources & Further Reading

1. PHP — Security advisory: Critical remote code execution vulnerabilities, update now (Oct 21, 2026)
2. GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), php/php-src
3. The PHP Foundation — Today’s PHP Security Release, and How We’re Strengthening PHP Security (Oct 21, 2026)
4. Calif Research — php2shell: A tale of two PHP remote vulnerabilities (Oct 21, 2026)
5. Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Oct 21, 2026)
6. OpenAI — Patch the Planet: global response coordination as agents uncover critical vulnerabilities (Oct 21, 2026)
7. Cloudflare — PHP vulnerabilities: WAF protection (Oct 21, 2026)
8. The Wall Street Journal — Robert McMillan, AI Just Found A Bug That Puts Up to 70% of the World’s Websites at Risk (Oct 21, 2026)
9. W3Techs — Usage statistics of PHP for websites and PHP version breakdowns (Oct 2026)
10. Google Cloud / Mandiant — Time-to-Exploit Trends (2023) and M-Trends 2026; Google Threat Intelligence Group exploitation trends (Sep 2026)
11. VulnCheck — State of Exploitation 2026 and 1H 2026 reports
12. Verizon — 2026 Data Breach Investigations Report
13. Netcraft — Half a million widely trusted websites vulnerable to Heartbleed bug (Apr 2014); follow-up scans by Errata Security (May–Jun 2014)
14. Fang, Bindu, Gupta, Kang — LLM Agents can Autonomously Exploit One-day Vulnerabilities (arXiv 2404.08144, Apr 2024)
15. Google Project Zero / DeepMind — Big Sleep (Nov 2024, Aug 2025); DARPA AIxCC final results (Aug 2025); Anthropic — Claude Mythos Preview and Project Glasswing (Apr 2026); Daniel Stenberg — The end of the curl bug bounty (Jan 2026)
16. Microsoft Security Response Center and the Chromium project on the share of memory-safety bugs among serious vulnerabilities