PHP2Shell: AI Exposes 40 Years of Legacy Code Debt

Researchers using AI-assisted analysis turned a long-known PHP crash bug into a critical server exploit, and a patch was released before attackers were known to have used it, according to IEEE Spectrum. The episode matters because it shows how AI can resurface flaws in widely used legacy software that were previously left unpatched as low-priority crashes.

What was PHP2Shell and which sites were at risk?

PHP2Shell is the name given to a vulnerability in PHP, the programming language created in 1994 and still used by many older websites, according to IEEE Spectrum. The publication reported that the flaw could allow an attacker both to read sensitive data and to run malicious code on the host server.

The potential reach was broad. IEEE Spectrum reported that sites run by NASA, Wikipedia and the White House were among those put at risk, along with sites using WordPress, Drupal and other systems built on PHP. That breadth is central to the story: a single flaw in a foundational language can affect organisations that have no direct control over the underlying code, as well as the open-source projects and hosting stacks they depend on.

According to IEEE Spectrum, the immediate danger appears to have been avoided. Cybersecurity researchers discovered the issue, reported it to the PHP Foundation, and a patch was released before malicious actors obtained the exploit. The publication presents that outcome as fortunate rather than guaranteed, and as a warning about similar flaws that may still be waiting in other long-lived codebases.

Why did a minor crash bug become critical?

The underlying defect was not new. IEEE Spectrum reported that the bug had been reported to the PHP Foundation as far back as 2024. It caused an out-of-memory error, meaning that too little memory was allocated to hold a piece of data. In ordinary circumstances, that kind of error simply crashes the program. A crash is disruptive, but it does not by itself give an attacker control of the server.

That distinction helps explain why the bug remained unaddressed. Suman Jana, an associate professor of computer science at Columbia University, told IEEE Spectrum that crash reports are common and often not treated as urgent. The publication also noted the amount of painstaking, case-specific reasoning needed to understand whether a crash can be shaped into something more dangerous.

Matt Suiche, AI security research lead at the cybersecurity startup Tolmo, framed the wider issue for IEEE Spectrum as a reckoning with older software. He argued that legacy code written by humans over roughly four decades is now being exposed, and that the accumulated technical debt must now be addressed. In other words, PHP2Shell was not presented as an isolated mistake. It was presented as evidence that AI is making it practical to revisit old assumptions about which bugs are harmless.

How did AI help researchers find the exploit?

Earlier this year, the cybersecurity firm Calif offered to audit PHP independently, with sponsorship from OpenAI, according to IEEE Spectrum. Within two weeks, a researcher at Calif, assisted by AI tools, found a way to use the out-of-memory bug to execute arbitrary code on the host server. At that point, the issue changed category from a crash to a critical vulnerability, and the Calif team alerted the PHP Foundation so patching could begin.

IEEE Spectrum reported that Wiz, another cybersecurity company, confirmed and expanded the vulnerabilities. The publication emphasised that the people involved had deep expertise in both cybersecurity and PHP. Jana told IEEE Spectrum that he was not claiming AI could complete the work entirely on its own, while also arguing that it is improving quickly enough to let leading experts accomplish much more and to bring less specialised practitioners closer to that level.

The technical challenge, as described to IEEE Spectrum, involved working out how to jump to a particular point in memory for a specific program on a server, and determining which bits to overwrite and in which order. Jana characterised that work as not conceptually exotic, but as requiring extensive, detailed reasoning that is painful to perform manually. AI, in his assessment, is particularly effective at sustaining that kind of reasoning.

Why is fixing bugs harder than finding them?

Finding a path to exploitation is only half of the work. After disclosure to the PHP Foundation, a team of four engineers spent two months developing a patch intended for release as quickly as possible, according to IEEE Spectrum.

Jana described a fundamental asymmetry between finding and fixing bugs. A fix must close every part of the attack while preserving existing functionality. A researcher may need to demonstrate one exploitable route, but maintainers must be confident that related routes are also closed and that legitimate use does not break. That asymmetry places particular pressure on open-source projects, which can be widely deployed without a clear revenue stream to fund intensive security work.

IEEE Spectrum reported that one proposed response is to give defenders more resources, including funding and access to frontier cybersecurity AI models. Jana welcomed donations of token budgets from frontier labs for vulnerability research and suggested that such support should expand, whether through coordinated efforts or donations.

He also pointed to formal verification as a possible way to make patching more automatable. According to IEEE Spectrum, he cited a new Anthropic release on 22 October in which a language model generates a patch and another generates a proof of correctness, while a separate proof checker, rather than a language model, validates the proof. The publication presented that combination as a hopeful direction, not as a proven replacement for expert review.

What can developers do with Grafy Code today?

For teams maintaining legacy PHP applications, the practical lesson from IEEE Spectrum is not that every crash report should be treated as an emergency, but that crash reports in exposed, long-lived code deserve a more serious second look. Developers can prioritise bugs in internet-facing components, check whether memory errors can be triggered remotely, and test whether a crash can be converted into data disclosure or code execution. Updates should be applied promptly, a point IEEE Spectrum reinforced through Matthew Green of Johns Hopkins University, who advised users not to delay available security updates.

Grafy Code is the most direct Grafy surface for that work. Developers can use Grafy Code as an AI coding studio to read legacy code, compare possible fixes, and work through patch logic with models side by side in Grafy Chat. For research teams, Grafy Reader can help them search and question papers and PDFs on memory safety, formal verification and vulnerability disclosure before deciding how to change a codebase. Grafy does not replace a security audit, but it can support the slower work of understanding old code and verifying that a proposed change is sound.

The longer-term outlook remains contested. Green told IEEE Spectrum that he expected major investment to follow a more damaging incident, which he suggested could occur in early 2027, rather than in response to PHP2Shell alone. Jana expected further discoveries and hoped that legitimate researchers would continue to find them first. For now, the episode suggests that AI-assisted auditing will increasingly test assumptions embedded in software that has run, largely unchanged, for years.

Frequently asked questions

Did AI find the PHP2Shell exploit entirely on its own?

No. According to IEEE Spectrum, a Calif researcher used AI tools during an audit sponsored by OpenAI, and the researchers involved had deep cybersecurity and PHP expertise. Suman Jana told the publication that AI could not do the work entirely by itself, although he said it was improving rapidly and helping experts complete much more detailed reasoning.

Was PHP2Shell exploited by attackers before a patch was released?

According to IEEE Spectrum, the hack was discovered by cybersecurity researchers and reported to the PHP Foundation, and a patch was released before bad actors got their hands on the exploit. The publication therefore describes the outcome as a disaster averted, rather than as a confirmed breach, while warning that the same approach could expose other legacy flaws.

When did Anthropic release the formal verification tool mentioned by Jana?

Anthropic released the tool on 22 October, according to IEEE Spectrum. Jana described its approach as generating a patch with a language model, generating a proof of correctness with a language model, and then using a separate proof checker to validate that proof because language models can hallucinate.

Source: IEEE Spectrum

---

Source: Hacker News — front page — AI is forcing us to pay off 40 years of technical debt