This week’s most-discussed engineering story on Hacker News carried a blunt headline: AI is forcing us to pay off 40 years of technical debt. It comes from an IEEE Spectrum report by Dina Genkina, published November 2, 2026, on PHP2Shell, a pair of critical flaws in the PHP engine. The story is about security, not coding assistants. Even so, it carries a lesson for anyone running legacy software: technical debt now has a clock on it.
What PHP2Shell actually is
The PHP Foundation shipped fixes on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The two CVEs, CVE-2026-109618 and CVE-2026-109619, are both rated CVSS 9.2. The first is remote code execution through out-of-memory corruption: a request that hits the memory limit at the wrong moment can leave partially initialized data that PHP later treats as valid. On Apache with mod_php, the Foundation says an unauthenticated request can trigger it before application code even runs.
Wiz Research reports that every PHP release from the last decade, going back to PHP 5.4, has at least one of the bugs. Because the flaws sit in the core engine, an application does not need to be vulnerable itself. Wiz demonstrated attacks against WordPress, Drupal and Joomla.
The debt was visible for years
IEEE Spectrum notes the underlying out-of-memory bug was first reported to the PHP Foundation in 2024. Out-of-memory errors usually just crash a program, so nobody treated it as urgent. The Foundation’s own account adds a process angle: after a 2024 external audit, competing fix approaches stalled under consensus-based decision-making. It has since created an Ecosystem Security Team and changed its rules so security decisions can be made by majority.
That is a useful reminder that debt is not only messy code. It is also the decision that nobody was empowered to make.
What AI changed
According to IEEE Spectrum, the security firm Calif, working on an audit sponsored by OpenAI, used AI tools to turn that dormant bug into arbitrary code execution within two weeks. Wiz says its models helped chain the bugs and adapt exploits to different PHP versions, configurations and memory layouts, and argues this lowered the effort needed to exploit a decades-old flaw.
The source also keeps the claim in proportion. Suman Jana, a computer science professor at Columbia, told IEEE that AI is good at this very specific reasoning but cannot do the job alone, and that deep expertise is still needed. Matt Suiche of Tolmo gave the story its headline idea: AI is exposing legacy software written over 40 years, and “now it is time for the technical debt to be paid off.” PHP dates to 1994, so the 40 years refers to legacy software in general.
The cost lands on defenders
Jana describes a fundamental asymmetry: defenders must close every route while keeping existing behavior intact, and attackers need one way in. The PHP Foundation shows the other side of it. AI-assisted research raised its report volume, and the team worked through more than 100 reports that were invalid, duplicates or not reproducible. AI helps triage them, but a person still makes every decision and works on every patch. IEEE reports that four engineers spent two months on the fix.
One published timeline also states that PHP 8.1 and older have no official fix (a secondary source). If that holds for your estate, upgrading is the only remediation, and Wiz calls patching the only complete one.
What this means for nearshore engineering teams
The following is our perspective, not a finding from the sources above. A runtime upgrade is only fast if you can prove nothing broke, and that takes tests, documented behavior and someone who understands the system. Those are the things legacy estates tend to lack. A nearshore team working in your time zone can build that safety net first, then do the upgrade work while your own engineers keep shipping.
- Inventory every runtime and framework version in production, including the ones nobody owns.
- Add characterization tests around the riskiest legacy modules before touching them.
- Set a patch cadence and an owner with authority to decide, so a known issue does not sit for two years.
- Treat end-of-support runtimes as an incident waiting for a date, and schedule their retirement.
Conclusion
Matthew Green of Johns Hopkins predicts that people will act only after something really bad happens. You do not have to wait for it. If you are sizing up a legacy modernization effort, talk to the Luby team about where to start.