AI Is Forcing Us to Pay Off 40 Years of Tech Debt
NASA, Wikipedia, and the White House were all one exploit away from compromise. Researchers reported PHP2Shell to the PHP Foundation before criminals got it, and four engineers spent two months building a patch. That timeline made sense in 2024. It looks ridiculous now.
On October 22, Anthropic released a tool that automates exactly that work: an LLM writes the patch, then another LLM generates the formal proof that the patch is correct. Jana, who works on this, points out that the verification side is advancing quickly. Two months of engineering compressed into an automated pipeline.
I think this is one of the more practical uses of AI we've seen, because it attacks a real bottleneck: the dangerous window between disclosure and patch, which is where forty years of legacy code gets exposed. But the demos skip over what happens when the generated proof has a gap, and that's the part I'd want to stress-test before letting it near production.
The Near-Miss That Exposed the Debt
The PHP2Shell exploit surfaced through coordinated disclosure to the PHP Foundation, meaning the vulnerability was patched before anyone could weaponize it against production servers. That timing is the whole story here: catching it early doesn't make the finding less dangerous, it just confirms that the attack surface in legacy PHP code is still wide enough to hide remote code execution paths. As Suman Jana at Columbia put it, "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." The implication is stark. The reasoning required to chain together obscure PHP behaviors into a working exploit is exactly the kind of tedious, multi-step logic that AI systems handle well, which means these bugs are now easier to find than they were five years ago.
This incident is a canary for anyone running decade-old PHP applications. The debt isn't just technical; it's a liability that compounds as the tools for finding exploits get better. "Better sooner than later, to be honest" applies here. The PHP Foundation moved quickly, but most legacy codebases don't have a foundation to disclose to.
<?php
// Legacy pattern that PHP2Shell targeted: unvalidated input in eval
// Real-world versions often hide behind variable variables or dynamic includes
$action = $_GET['action'] ?? '';
$allowed = ['status', 'info'];
if (!in_array($action, $allowed)) {
eval('$result = ' . $action . ';'); // RCE when $action is crafted
}
?>My take is that AI-assisted vulnerability discovery is going to force a faster patch cycle than most teams are ready for. The gotcha is that disclosure only helps if you're running a maintained version of PHP; teams stuck on EOL releases get no patch, just a public proof of concept. Compared to the manual code audits that used to take security researchers weeks of grep and guesswork, this class of bug is now findable in hours.
Automated Patching with Mathematical Proof
On October 22, Anthropic released tools that let a large language model generate not just a code patch but a formal proof that the patch is correct. The model writes the fix and the mathematical argument for why it works in one pass. As Suman Jana at Columbia put it, "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." The painful part is exactly what's being automated.
This changes the economics of technical debt. For decades, the reason bugs sat in production for years is that verifying a fix costs more time than writing it. Automating the proof collapses that cost. Here's what a generated patch with its correctness condition looks like:
def safe_divide(a: float, b: float) -> float:
# Precondition: b != 0
# Proof obligation: division requires nonzero denominator
assert b != 0, "division by zero"
return a / bThe assertion isn't just a runtime check. In Anthropic's workflow, the LLM generates a formal proof that the guard holds for all valid inputs, reducing the verification step to checking the proof rather than testing cases.
My take is that this is worth trying if your codebase has invariants where a regression costs more than the tooling. The gotcha is that proofs only cover properties the model can formalize. Memory safety and type correctness are straightforward, but "this feature behaves as the user expects" isn't. Compared to fuzzing, which only checks the inputs you happened to generate, a formal proof covers every possible input, but only if the specification itself is right. Better sooner than later, to be honest. We still need to figure out who is liable when the proof turns out to be wrong.
The Human Cost of Legacy Maintenance
I think the relief here is warranted but temporary. The fact that researchers caught PHP2Shell before it reached criminal markets is genuinely good news—unlike Log4j, where exploitation was already widespread before most organizations patched, this appears to have been contained at the disclosure stage. But "as far as anyone is aware" is doing heavy lifting in that sentence. The canary metaphor fits: legacy PHP codebases aren't just running old software; they're running software that attackers have had decades to study, and the maintenance model that keeps them alive often prioritizes stability over the continuous security auditing that would catch a backdoor like this early. The commenters calling for proactive vulnerability discovery and minimalist architectures are pointing at the right problem, though I think they underestimate the friction. Self-contained authentication and reformed certifications sound like structural fixes, but most legacy PHP applications are held together by decades of accumulated dependencies and institutional knowledge that no certification reform will untangle quickly. Minimalism is a luxury for new projects; for the millions of WordPress sites and custom CRMs still running on unsupported PHP versions, the architecture is already ossified. What the announcement doesn't mention is that a patch only closes this specific vector—it doesn't address the underlying incentive structure that allowed someone to inject code in the first place. We still don't know if this was a compromised maintainer account, a supply chain attack through a dependency, or something else, and until that's clear, the next backdoor is just a matter of time. There's also a named gotcha the announcement glosses over: the regression testing gap. AI-generated patches can close the specific vulnerability while silently breaking legacy functionality, because these codebases rarely have the automated test suites needed to catch behavioral changes—meaning we might seal the backdoor but break the billing system in the process. The real cost here isn't the incident itself; it's the slow erosion of trust in the open-source infrastructure that legacy systems depend on. Will the PHP Foundation actually fund the kind of proactive auditing the community is asking for, or will this become another incident report filed away until the next one?
Conclusion
The PHP2Shell scare was less a near-miss and more a preview. A vulnerability reported to the PHP Foundation back in 2024 sat in the queue until October 2025, and it took four engineers two months to ship the fix. That's the reality of maintaining a language born in 1994 that still powers NASA, Wikipedia, and the White House. The promise of AI-generated patches with LLM-generated mathematical proofs—like the tooling Anthropic released on October 22—sounds like it solves the human bottleneck. But I'm not convinced we're paying off the debt so much as refinancing it at a lower interest rate. Automated patching can handle the symptoms, yet it doesn't explain why critical infrastructure still runs on forty years of accumulated technical debt in the first place. So here's what I keep coming back to: when the next exploit surfaces in a codebase nobody remembers writing, will we have verification tools mature enough to catch it before another two-month scramble? Or are we just building faster ways to clean up after a system that should have been retired decades ago? I think we're doing the latter, and that's the problem: until we treat security maintenance as a funded engineering discipline rather than an afterthought, AI will just give us faster ways to mop up after exploits instead of preventing them.