PHP knew about a PHP2Shell flaw in 2024. Why did the fix stall?
The fix for one of the PHP2Shell flaws stalled for months on hard trade-offs and too few people to resolve them. Any engineering leader with a hard fix parked in the backlog should recognise the pattern.
In 2024 a developer working for the PHP Foundation found the first signs of a flaw in how PHP handles running out of memory. Every fix the team built carried a cost, nobody had found a way to exploit the flaw, and work on it stalled and restarted for months. In August, AI-assisted researchers showed it could be exploited. On 21 October PHP shipped fixes for that flaw and a second one, both rated 9.2 out of 10 on the industry’s severity scale and both able to let an unauthenticated attacker run code on a server. The release was brought forward a day after the flaws’ identifiers began circulating online.
Headlines from the Wall Street Journal to Wiz’s blog led with the AI. The PHP Foundation’s account of why the first flaw sat unfixed is more useful for leaders, and it was blunt:
“We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.”
The fix stalled on trade-offs and too few people
The flaw surfaced while the developer was fixing an issue from PHP’s first external security audit in years, which the Foundation organised with funding from Germany’s Sovereign Tech Agency. An exploit was theorised, but nobody found a concrete way in, and other issues with clear impact took precedence. The security team built several competing fixes. Each had costs, from backward-compatibility breaks and new denial-of-service risks to changes in third-party extensions that seemed impossible to coordinate. The Foundation described what followed:
“The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice.”
Few people know the engine well enough to make that call. The Foundation maintains the language with only 13 full-time and part-time engineers, The Guardian reported. The Foundation says its security work depends on “a small group of foundation-funded developers and a little volunteer help”.
AI made the exploit cheaper
The Foundation brought PHP into the Patch the Planet programme, through which Calif began auditing it on 30 July. On 11 August a Calif researcher, helped by OpenAI’s GPT-5.6 Sol, reported remote code execution with the same root cause. From then on the fix was the Foundation’s top security priority, and it was still a big job. Close to 200 files were fixed and more than 10,000 lines of code written, the Journal reported. Recorded Future said release-day reporting didn’t establish how many attacks had succeeded.
AI-assisted research also brought far more reports. Since 1 July, the Foundation said, the team has published 15 CVEs and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible. AI helps sort them, but a person makes every call. The Foundation was clear about what the tools can’t do:
“Tools now find bugs faster than ever, for defenders and attackers alike, and the number of reports will keep growing. What tools cannot do is decide on the right fix for a long-standing design decision in the engine, weigh the compatibility trade-offs, and review the patch.”
AI made finding the exploit cheaper. The bottleneck stayed where it was: choosing a fix, and having people with the time and expertise to build and review it.
A near miss, with limits
I read this through my book, Come Prepared to Die, which drew on Scott Snook’s Friendly Fire. Snook studied the 1994 shootdown of two US Army Black Hawks over northern Iraq. About 18 months earlier, Air Force F-111s nearly attacked Black Hawks from the same unit under nearly the same conditions. One of the Black Hawk pilots told investigators the unit’s commander had been on the flight: “As far as I know he knew about it and that was about as far as it went.” In the book’s chapter on safety I wrote that the near miss was the leading indicator, and the accident report was the lagging one.
PHP’s warning was tracked and worked on, while Snook’s near miss was never formally reported. Snook also doubted that escalation alone would have taught the right lesson. Recognising a hazard doesn’t mean an organisation can resolve it.
What to do with your own parked fixes
The Foundation created an Ecosystem Security Team in May and says stuck fixes will now reach its leadership sooner. The security team is changing its process so decisions can be made by majority. The Foundation is also asking companies that build on PHP to sponsor it “at a level that reflects how much you rely on it”. If your business runs on PHP, consider making a contribution here.
In Minimum Viable Bureaucracy, the handbook I refined over my last three engagements, a risk that hasn’t become an incident yet still goes to a named owner and into the backlog, ranked by how likely it is to happen and how bad it would be if it did. A flaw nobody can exploit yet can still rank near the top.
In your own backlog, start with high-consequence fixes deferred because exploitation seems hard. Name who owns the decision and can commit engineering time, and set a date to review the deferral. If you accept the risk for now, write down what evidence would reopen it.
Thanks to George Lawton, who suggested I look at PHP2Shell through the lens of the book.
Sources
- PHP Foundation, “Today’s PHP Security Release, and How We’re Strengthening PHP Security”, 21 October 2026.
- PHP, release notice and pre-announcement, 20–21 October 2026.
- Robert McMillan, “AI Just Found a Bug That Puts up to 70% of the World’s Websites at Risk”, Wall Street Journal, 21 October 2026, via To Vima.
- The Guardian, “What is PHP and how serious is the computer language flaw causing website shutdowns?”, 22 October 2026.
- Recorded Future, “PHP2Shell Exploitation: Two Critical PHP Flaws Explained”, 21 October 2026.
- Scott A. Snook, Friendly Fire, 2000, chapter 7.
- Chris Gagné, Come Prepared to Die, chapter 15.