PHP2Shell: How AI Is Forcing Software to Pay Off 40 Years of Technical Debt

The PHP2Shell vulnerability turned a two-year-old PHP crash bug into a remote code execution flaw that put WordPress, Drupal, NASA, Wikipedia, and White House websites at risk — and it was found in roughly two weeks once AI tools were pointed at the code. The episode, reported by IEEE Spectrum in November 2026, has become the reference case for a larger argument: AI has collapsed the cost of finding exploitable bugs in decades of legacy software, forcing the industry to confront technical debt it has deferred for 40 years.

What PHP2Shell actually was

PHP2Shell was a critical vulnerability in PHP, the server-side language created in 1994 that still underpins a large share of the web. The flaw allowed an attacker to read sensitive data and run malicious code on a host server, which would permit installing malware or exfiltrating critical data.

The bug underneath it was not new. It was reported to the PHP Foundation as far back as 2024 and manifested as an out-of-memory error — a class of bug that normally just crashes a program. Because crashes are common and usually not dangerous, the report sat unaddressed.

"If you look at any at any point of time, there will be a bunch of bug reports that are waiting to be fixed, which are just crashes. Most people don't take them very seriously." — Suman Jana, associate professor of computer science at Columbia University

The turning point came when the cybersecurity firm Calif offered to independently audit PHP, sponsored by OpenAI. Within two weeks, a Calif researcher aided by AI tools found a way to convert the out-of-memory bug into arbitrary code execution. The firm Wiz confirmed and expanded the findings. A team of four PHP Foundation engineers then spent two months developing a patch.

As far as is publicly known, the vulnerability was reported by researchers before bad actors obtained it, and a patch shipped first. Other major security issues disclosed around the same time included a Brotli remote code execution flaw affecting Node.js, three bugs in Ruby's regex engine, and a certificate authority whose keys were cracked in milliseconds.

Why AI changes the economics of exploitation

AI does not need to be a autonomous hacker to shift the security balance. It needs only to make painful, highly specific reasoning cheap enough that more people can do it.

Exploiting a memory bug requires working out how to jump to a specific point in memory for a particular program and determining exactly which bits to overwrite in what order. Suman Jana describes this as tedious rather than brilliant work.

"It's not really rocket science. It's just that it's a lot of very specific reasoning that is painful to do. And AI, I think, has done a very good job at that." — Suman Jana, Columbia University

Jana is explicit that humans remain essential: the Calif, OpenAI, and Wiz researchers had deep expertise in both cybersecurity and PHP. His claim is narrower and more consequential — that AI raises the output of the top 0.1 percent of experts and lets people just below that tier operate without mastering every detail.

Hacker News commenters extended the point to attack economics. One described the shift from a world where sophisticated attacks required a costly professional to one where they cost cents to dollars:

"Security by obscurity was always big in most companies, as long as the bar to carrying out sophisticated attacks was putting a costly IT professional to the task you could be relatively relaxed... now carrying out such an attack costs a few cents to a few dollars at most, that changes the game entirely and everyone is a target." — @ThePhysicist

Another framed the same shift as the death of a common implicit strategy:

"The mentality of 'It's too painful to attack' as a security strategy isn't working anymore in the era of AI." — @ctrlaltdileep

The asymmetry between finding and fixing bugs

The core reason PHP2Shell is a warning rather than a victory is that finding bugs and fixing them are not symmetric tasks. Discovery is parallelizable and cheap; remediation requires proving that every path of an attack is closed without breaking existing behavior.

"There is a fundamental asymmetry in finding bugs and fixing bugs. Because when you're fixing bugs you have to make sure that you know all parts of that attack are closed, and also that you don't break any existing functionality." — Suman Jana

That asymmetry lands hardest on open-source projects such as PHP, which are widely depended upon without a clear revenue stream. AI-assisted discovery makes the maintenance burden more urgent without automatically funding it.

Jana's proposed mitigation is for frontier AI labs to donate token budgets to security auditing of critical open-source code, and he argues this should happen more often, whether through coordinated effort or donations. He also points to formal verification as a way to automate the patching side: a new Anthropic release on 22 October demonstrated a pipeline in which an LLM generates a patch and another LLM generates a proof that the patch is correct.

"The only thing not done by an LLM is the proof checker, because somebody has to check the proof, because LLMs hallucinate. So, you want something that's formal." — Suman Jana

The counterargument: AI is also creating technical debt

The strongest pushback on Hacker News was that the headline is only half the story. AI is accelerating the discovery of old flaws while simultaneously generating new code that few people understand.

"Ironically, AI is also making us create a new whole new level of technical debt - where no one has actual understanding of the code being written and we're just trusting the machine." — @herval

"What's hilarious is people vibe coding massive AI apps thinking its not creating tech debt and security holes. If anything, AI is discovering existing holes, and creating them faster than ever before in history." — @program_whiz

Several commenters drew a distinction between bugs and debt. Bugs are defects; debt is the accumulated cost of code nobody understands. On that definition, AI-generated code that passes tests without being comprehended is debt creation, not repayment.

"Technical debt isn't bugs, technical debt is if you get AI to generate an application and have barely any understanding of how it works. AI without understanding creates infinite technical debt." — @nwmcsween

A related concern is that AI fixes tend to be narrow. Commenters reported that AI-generated patches can pass a specific test while remaining brittle or introducing non-obvious failure modes, which matters most precisely in security-critical repairs.

The framing dispute: forcing payment or enabling repayment?

A large faction on Hacker News rejected the article's pessimistic framing outright. If AI found the bug and AI helped write the patch, they argued, the headline should be about eliminating debt rather than being forced to pay it.

"So, the headline should read, 'AI is helping us eliminate 40 years of technical debt.' Since AI found the bug, and probably also generated the patch at this point." — @Kevin_Flynn

"You could just as easily headline this as: AI is enabling us to fix longstanding software security issues that nobody had the time, skill, or desire to find. All a matter of perspective, I suppose." — @cushychicken

Others argued that AI removes the excuses that sustained deferral. Work that was previously too expensive to justify becomes affordable, which changes what counts as acceptable neglect.

"AI has removed all the excuses we had not to remove technical debt." — @Lucasoato

A more skeptical commenter raised the possibility that neither framing is right, and that the outcome is a permanent treadmill rather than a one-time repayment: if every non-trivial fix carries the risk of a new issue, the industry may end up continuously churning code simply to remain a moving target.

"If that happens to be the case, and AI isn't able to magically produce perfect software in finite time, then what's really happened is that the threat of hostile AI exploiting our technical debt will force us to always be burning and churning code just to remain a moving target." — @swatcoder

The bottleneck is deployment, not discovery

A practical objection cut through much of the debate: finding bugs is becoming cheap, but shipping fixes inside large organizations is not.

"In a lot of large organizations the oldest systems have no clear owners, they also lack sufficient automated tests, and a release process understood by a couple of people. When a critical patch lands, the team still can't answer basic questions: where is this component actually running, who can approve the change, and how do we know we didn't break something else?" — @rahulsawhneyonl

This is why claims that "disaster has been averted" drew immediate skepticism. A patch existing is not the same as a patch being deployed. Commenters noted that many operators do not automatically update PHP, so the vulnerable surface persists in the wild long after disclosure.

"Aren't there still vulnerable services right now being hacked?" — @tlhunter

"A lot of people don't actually auto update their PHP so.. it's not like the vulnerability disappeared from the wild." — @hoppp

The timeline counterargument

One commenter challenged the article's premise that AI is the decisive new factor, pointing to the Brotli/HTTP2Shell timeline as evidence that human processes still dominate the delay. That timeline, as cited, shows a flaw present in code for eight years, a fix sitting unreleased in Git for eight months, and at least four independent researchers finding and reporting the problem.

"The article takes PHP2Shell as the worst offender of the present wave of vulnerabilities but HTTP2Shell/Brotli2Shell was arguably worse... at least part of reality is actually still very much 'humans just sitting on vulnerabilities for months or even years.'" — @vanschelven

The counterpoint does not refute the AI argument so much as complicate it: disclosure and remediation pipelines were already failing before AI entered the picture.

What security practitioners should actually do

Matthew Green of Johns Hopkins University's Information Security Institute is pessimistic about institutional response. His prediction is that meaningful funding will arrive only after a severe incident that ordinary people notice, which he places possibly in early 2027.

"Nobody's going to fix this problem until something really bad happens. And PHP2Shell wasn't bad enough to be really bad." — Matthew Green, Johns Hopkins University

His immediate advice is unglamorous and concrete: install security updates as soon as they are offered rather than waiting.

"If your phone is like, 'Hey, there's a security update available, do you want to install it,' don't wait till next week. Just do it." — Matthew Green

Jana's conclusion is that PHP2Shell is a preview rather than an anomaly.

"This won't be the last one for sure. It's just who finds it. Hopefully, the white-hat hackers find it first, like this one." — Suman Jana

Commenters added practical corollaries: use AI offensively against your own code before someone else does, treat bug bounty programs as capacity-constrained, and expect formal verification to arrive first for foundational software rather than for fast-moving application code.

"It's an easy prediction that we will see verification on large trunks of fundamental software in the next few years, and a sub-verification confidence scheme for the software on top of it." — @samuelknight

Is perfectly secure software even possible?

The thread's deepest disagreement was philosophical. Several commenters invoked Gödel's Incompleteness Theorem, via Gödel, Escher, Bach, to argue that no system can be made unbreakable in principle, only more expensive to break. Others pushed back that the practical goal was never perfection but raising the cost of attack above the value of the target.

"Do we know if it is even possible for a non trivial software to be fully secure? Or will there always exist a way to break it, no matter how much we fix it?" — @carra

"No software of normal complexity can be 'provable.'" — @pyrphoros

That tension is unresolved, and it is the real subject of the PHP2Shell story. AI has made the search for flaws nearly free. Whether the industry uses the same capability to harden its foundations, or merely to keep patching faster, determines whether the next decade of software is more secure or simply more frantic.

"Yes, we're going to see the bugs exposed by AI and it's going to suck a bit for a few months. But when this is all over, software will be more secure than it has ever been before." — @glennfiedler