Critical PHP Flaw Was Known to Maintainers Two Years Ago

Critical security flaws in the open-source language PHP, discovered the week of October 19, 2026 by OpenAI's GPT 5.6-Sol model, have created a wide-ranging threat. According to a published post-incident review, a small team of maintainers had in fact known about the problem for two years.

Security experts had warned for decades about the technical debt that had piled up. AI agents that accelerate vulnerability scanning exponentially have now made the customary 90-day disclosure window meaningless. PHP, which powers roughly 70 percent of websites, has come into the sights of these bug-hunting agents. The flaw allows remote code execution if an attacker has enough information.

Technical roots of the flaw

The problem stems from an old architectural decision in how the PHP engine handles errors. When a PHP process runs out of memory, the engine calls the C function longjmp(), which unconditionally redirects execution to another point. Using the function without strong justification is generally discouraged, but that is not the core issue. If the jump happens while an array entry is being added or an object is being initialized, half-finished data is left behind in memory.

When the engine then moves on to its cleanup and exit routines, that code assumes it is working with complete, consistent data, when in fact it is handling inconsistent leftover bytes. An attacker who places the right content in a web request can abuse this mechanism to run arbitrary code with PHP's privileges, as the ongoing PHP2Shell attack demonstrates.

Obtaining a remote shell requires the attacker to know the exact version and build of PHP in use, so it is not a one-click operation. Still, the existence of tens of millions of vulnerable servers, many running the same version, makes the threat serious. After the flaw was made public, many system administrators turned off PHP version reporting so as not to make things easier for would-be attackers.

The team knew about it

According to the PHP Foundation's post-incident review, the team had been aware of the problem for two years but did not immediately treat it as a cause for concern. There was repeated back-and-forth over the best way to fix it while preserving compatibility with third-party extensions. The team acknowledged that it made management mistakes.

The team is small: one full-time employee and 14 part-time contractors maintain one of the most widely deployed pieces of software on the internet. It is a familiar pattern of open-source projects that are critical to modern computing yet lack enough staff or funding.

Old versions and patching options

The real issue appears to be less the flaw itself than a broader pattern of neglect. At the time of disclosure, 73 percent of PHP installations on the internet were running end-of-life versions with no active support. The branches currently maintained run from 8.1 to the latest, 8.5. The standard patching process is relatively easy: a point-release update and, in some cases, restarting certain services. System administrators rarely install PHP directly; most rely on up-to-date packages from their preferred Linux distribution or community repositories.

The PHP Foundation has published source-code patches for versions 7.4 through 8.1, which makes it possible to develop patches for even older versions, and many organizations have done so. Packages from Debian developer Ondřej Surý for Debian and Ubuntu derivatives span PHP 5.6 to 8.1. CloudLinux and AlmaLinux have produced backported fixes. Commercial providers such as Ubuntu Pro and Zend have shipped packages for versions going back to PHP 5.5.

Sites on PHP 7 are in a tougher spot. The move from PHP 7.4 to 8.0 in late 2020 brought many small but review-worthy changes to the language. Many had expected their distribution to keep backporting fixes, especially for long-term support releases within their support window. But those on 7.3 and earlier may have to update their site code, since there is no guarantee every distribution will backport the fix. PHP 7.3 was released in 2018, and roughly 8 percent of installations are on PHP 5.x, which dates to 2005. Hardware that bundles PHP, such as NAS devices and network appliances, also needs updating; Palo Alto Networks has published an advisory for its PanOS-based products.

The real fix is to move to a patched PHP release, but there are additional mitigations. Web application firewalls such as Imunify360 can block malicious requests before they reach the server. Because legacy site code is likely to contain other vulnerabilities beyond the PHP engine itself, a comprehensive update and upgrade is a far sounder path.