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

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.

How the attack came to be

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.

The exploit is only half of the problem

The standard patch process is reasonably trivial, needing only a point update and perhaps requiring a restart of some services. The currently maintained branches of PHP are 8.1 through the current 8.5. Sysadmins rarely install PHP directly, though, relying on their Linux distribution of choice or community repositories for updated packages.

Those 73% of sites still stuck with PHP 7 are now stuck between a rock and a hard place. When PHP moved from 7.4 to 8.0 in late 2020, there were a number of changes to the language, most of them minor, but still requiring revision work. Many folks likely expected their distro to keep backporting fixes, especially for LTS (Long-Term Support) variants still in their support period, with PHP 7.4 in tow. That excuse is arguably always a little thin, as even before the AI age there were already automated tools to upgrade existing PHP code with relatively little work.

Now, depending on their specific situation, those relying on ancient versions like 7.3 or older may be forced to bring their websites' code up to speed, given that not all distros are bound to have backported fixes. For reference, PHP 7.3 came out in 2018. Making matters worse, nearly 8% of PHP installations are of version 5.x, which came out in 2005. Plus, a number of network appliances, NAS boxes, and similar hardware carries PHP within, and that too will need updating. Palo Alto Networks issued an advisory for products powered by its PanOS system, for example.

It's not all doom and gloom, however. Since the PHP Foundation published source code patches for 7.4 up to 8.1, most anyone can devise a patch for the older versions. Many entities did so, and there are packages available for Debian/Ubuntu flavors from Ondřej Surý (Debian developer) covering PHP 5.6 to 8.1. CloudLinux and AlmaLinux have likewise produced backported fixes.

This is one occasion where paying for extended support comes in handy, as commercial vendors like Ubuntu Pro and Zend released packages for positively ancient PHP versions, down to 5.5. Old website code is likely to have vulnerabilities other than the PHP engine, so a wholesale update-and-upgrade is much preferable, but very few CTOs will ever listen to that song.

Other options

Given how broad the problem is, and how it'll be a while before every machine is protected, there are a number of other means to mitigate the issue — though the proper fix is to update to a patched PHP version. Web application firewalls (WAFs) like Immunify360 may block malicious requests from even getting to the server in the first place.

Content delivery networks (CDNs) like Cloudflare or Fastly universally offer options for adding a WAF to their setup. Both firms immediately issued their respective notices and added detection of PHP2Shell to their respective rulesets. Finally, server-level security suites like CrowdStrike can also detect and block malicious activity by the PHP binary itself, in case an attacker tries something funny. It's reasonable to guess that these protections have slowed exploitation efforts.

So where are we?

Right now, the PHP2Shell exploit is doing the rounds, with at least one high-profile case involving a campaign that chained the PHP vulnerability together with Fragnesia (aka Dirty Frag) to eventually get kernel-level access to 25 servers seemingly linked to the U.S. government. As of October 29, security firm BitSight had recorded copious attempts of PHP2Shell intrusion across its monitoring fleet, from many distinct origins.

BitSight's dark web forum sleuths indicate that there was no one-size-fits-all exploit package available at that date. This may indicate that hacking campaigns for now are likely to be specifically targeted, but a proverbial one-click red button is bound to appear at some point, likely with a deeper exploit in tow, as with the Fragnesia example above.

Meanwhile, several cybersecurity firms kept a close eye on patching progress since the October 19 reveal. Censys has a real-time view, updated hourly, and suffice it to say that things could be going a lot better. The initial count estimated the number of vulnerable PHP installs at around 45.7 million, out of 119 million total.

The number of unpatched services has mercifully dropped to around 29 million as of this writing, seemingly indicating a patch rate of around 1 million per day, depending on how you count. It's worth noting that fix backports may not change the version number, so those instances could still count as unpatched.

But remember how most everyone toggled off their server's PHP version number reporting. According to Censys, 62% of PHP servers it's consulting aren't reporting that datum at all, so there's no telling what the actual totals might be. If history is any indication, a significant percentage of those machines remain unpatched today.