// TOM'S HARDWARE US — HARDWARE & GADGET
PHP vulnerability post-mortem reveals bug was known two years ago — Small team of maintainers knew of the issue before it was made public, as new PHP2Shell chained exploit ravages servers
Long-standing technological debt is being charged with interest.
When you purchase through links on our site, we may earn an affiliate commission. Here’s how it works.
The phrase "when it rains, it pours" applies both to weather and computer security, as proven the week of October 19, 2026, when OpenAI's GPT 5.6-Sol discovered critical vulnerabilities in the open-source programming language PHP. As published in a post-mortem, a small team of maintainers knew of the issue two years ago. Security experts had warned for decades about mounting technical debt, as agentic AI exponentially sped up vulnerability scanning, to the point that the usual 90-day disclosure window for security exploits became pointless. PHP, one of the internet's ubiquitous software packages, was unlucky enough to in the crosshairs of bug-hunting AI agents.
PHP hosts around 70% of websites on the internet, and the vulnerability allows for remote code execution with enough attacker knowledge. That combination is enough to sound alarms, but the situation got worse once the collective internet realized that, at the time, 73% of PHP installations online were running end-of-life versions with no active support — eliciting face-palms from many techies, and an exasperated sigh from anyone familiar with the ecosystem, myself included. So ultimately the problem wasn't really the vulnerability, but the general complacency.
The root cause of the vulnerability was an ancient architectural decision in the PHP engine's error handling. When a PHP process runs out of memory, it'll call the longjmp() C function, which means "immediately jump the execution to another place, no questions asked." Using longjmp() without a very good reason is generally unadvisable, though that by itself wasn't the problem.
The real issue is that if that jump happens while building a data structure (like adding an array entry, or initializing an object), that half-baked data remains in the memory heap. When the PHP engine moves execution to its cleanup-end-exit mechanism, that code will execute expecting good, complete data, but instead acts on inconsistent leftover bytes.
With some clever injection of just the right content in a web request, this mechanism can be exploited to run any code with PHP's permissions, as shown by the ongoing PHP2Shell exploit.
Gaining a remote shell does require an attacker to know the exact version and build of PHP used, so it's not as trivial as just pressing the "Hack" button. Yet the wide blast radius, with tens of millions of vulnerable servers, many of them running the same exact version, is enough to give anyone pause. After the vulnerability was made public, many sysadmins disabled version number reporting on their PHP installation, so as not to aid prospective hackers.
The PHP Foundation's post-mortem indicates that the team had known about the issue for two years, but didn't immediately see it as a cause for concern, and went back and forth several times on the best way to fix the problem while maintaining compatibility with third-party extensions.
The team admitted it had made management mistakes, but it's a small outfit with one full-time employee and 14 part-time contractors, tasked with maintaining one of the most widespread pieces of software on the internet. This is a common pattern: open-source software that's of critical importance to modern computing, yet undermanned, underfunded, or both.