The End of Security by Exhaustion

Imagine a bank with no guards, no cameras, and a vault whose combination is theoretically guessable. The only reason the money stays put is that cracking it would take millions of mind-numbing manual attempts. Nobody bothers. The vault is "secure."

For more than two decades, large swaths of the internet's foundational software lived in exactly that limbo. Flaws were known or suspected. Turning them into reliable exploits required weeks or months of tedious heap-layout debugging, environment tailoring, and trial-and-error. The economic cost — in human time and cognitive exhaustion — outweighed the payoff. The bugs sat quietly. We called the resulting false sense of safety security by exhaustion.

That era ended in October 2026.

What Security by Exhaustion Actually Meant

Technology writer and researcher Nick Rogers coined the term to describe systems that remained practically secure not because their code was flawless, but because the human effort required to weaponize the flaws was too grinding. The oldest open-source foundations of the web — especially interpreters written in C — were full of these economic buffers. A specific memory-management edge case might be visible in the source. Actualizing a remote code execution chain, however, demanded specialized knowledge, patience, and the willingness to stare at core dumps until the eyes bled (Rogers, 2026).

Rogers' analogy is precise: a bank with no security guards. Anyone could walk in and try the combination. Because it would take an absurd amount of tedious work, almost nobody did. The vault stayed closed in practice.

This was never a formal security property. It was an informal market equilibrium. Defenders and attackers both operated under the assumption that certain classes of bugs were "too hard to exploit right now." Patch prioritization, audit depth, and even CVSS scoring reflected that assumption. High complexity equaled lower urgency.

The Catalyst: PHP2Shell

On 21 October 2026 the PHP project shipped emergency releases (8.5.12, 8.4.27, 8.3.36, and 8.2.35) for two critical vulnerabilities in the core interpreter itself: CVE-2026–109618 and CVE-2026–109619 (PHP Project, 2026). Collectively nicknamed PHP2Shell, both scored 9.2 under CVSS v4.0 (some independent researchers called it a straight 10). They allow unauthenticated remote code execution and memory disclosure on standard deployments. The bugs live below the application layer, so even a perfectly written WordPress, Laravel, or "Hello World" site is exposed if the PHP runtime underneath is vulnerable. PHP powers roughly 70 percent of websites whose server-side language is known (OpenAI, 2026; Pentera, 2026).

The technical roots are old. PHP workers are long-lived processes that handle many sequential requests. When a request hits its memory limit or a fatal error, the engine does not carefully unwind; it calls longjmp and jumps straight to shutdown. Any half-finished data structure or global pointer is left in an inconsistent state. Attackers who can force an out-of-memory condition at precisely the right moment during multipart form parsing (before application code runs) can turn that inconsistency into code execution or a memory leak of passwords, tokens, and addresses.

The primitive was documented by Stefan Esser in 2004. A related multipart out-of-memory issue appeared on the public bug tracker in 2019. A 2024 external audit rediscovered the pattern. No one fully weaponized it — because the engineering grind was brutal (Rogers, 2026).

Then AI changed the price.

AI Doesn't Get Tired

Calif Research (working under OpenAI's Patch the Planet initiative) and, independently, Wiz found the exploitable paths in summer 2026. Frontier models helped surface and generalize the old pattern. What historically required months of elite red-team effort collapsed into days. The models did not invent a new vulnerability class out of thin air; nearly every ingredient was already in the public training data — source code, historical advisories, bug reports. The decisive shift was that AI drives the marginal cost of exploit plumbing toward zero (Rogers, 2026; OpenAI, 2026).

Rogers puts it cleanly: any vulnerability that previously relied on being "too tedious to fix, but also too tedious to exploit" is now highly dangerous. AI does not get bored, does not need coffee, and does not stop after the tenth failed heap spray. The economic buffer that kept the vault closed has evaporated.

Details leaked a day before the coordinated patch. Exploitation attempts were observed as early as 17 October. Sites went offline. Emergency WAF rules appeared. The long tail of end-of-life PHP versions (hundreds of thousands of internet-facing hosts) remains exposed (Reuters, 2026; Pentera, 2026).

Broader Implications

This is not just a PHP story. The same dynamic applies to any complex, long-lived C/C++ codebase that serves untrusted input — interpreters, parsers, media libraries, network stacks. The "too hard to exploit" defense is now a temporary historical artifact rather than a reliable control.

Threat modeling has to change. Attack complexity scores that once justified delay now understate risk. Coordinated disclosure windows shrink because public source plus a capable model can substitute for a leaked write-up. Defenders gain a "Defender's Window" when AI finds issues first, but only if the response machinery (maintainers, distributors, operators) can move at the new speed. OpenAI's Patch the Planet coordination around PHP is an early attempt at that scaled response (OpenAI, 2026).

For developers and operators the practical takeaways are blunt:

• Treat memory-safety and state-isolation bugs in foundational runtimes as high priority even when current exploit difficulty looks high.
• Inventory the actual PHP (or equivalent) version running in production, not the one on disk. Restart workers after patching.
• Assume the long tail of unmaintained systems is now more attractive, not less.
• Distinguish security by exhaustion from security fatigue (the human burnout from endless alerts and password prompts). They are different problems; only one of them just died.

Looking Ahead

Security by exhaustion was never elegant. It was a happy accident of human cognitive limits. Those limits no longer bind the attacker side as tightly. The result is not that every old bug instantly becomes a wormable catastrophe — reliable weaponization still requires skill — but the margin of safety has collapsed.

The vault still has the same combination. The difference is that guessing it no longer requires a lifetime of tedious work. It requires a weekend with the right model and a clear prompt.

Patch your runtimes. Audit the foundations. And stop assuming that "nobody will bother" is a control.

What other quiet corners of the software stack are sitting on the same expired economic buffer? The next few years will tell us, faster than most of us would like.

References

OpenAI (2026) 'Patch the Planet: global response coordination as agents uncover critical vulnerabilities', 21 October. Available at: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/

Pentera (2026) 'PHP2Shell: the expiry date on "too hard to exploit"', 21 October. Available at: https://pentera.io/resources/research/php2shell/

Reuters (2026) 'Websites taken offline over PHP risks', 21 October. Available at: https://www.reuters.com/technology/websites-taken-offline-over-php-risks-2026-10-21/

Rogers, N. (2026) 'PHP2Shell Explained: PHP2Shell Was in the Training Data', Dead Neurons, 21 October. Available at: https://deadneurons.substack.com/p/php2shell-explained-php2shell-was

PHP Project (2026) Security advisories for CVE-2026–109618 and CVE-2026–109619. Available via php.net archive and GitHub Security Advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).