AI made it possible to build an exploit from an old PHP weakness, security companies say

AI made it possible to build an exploit from an old PHP weakness, security companies say

Two critical security flaws in PHP – collectively called PHP2Shell – were disclosed and patched on Wednesday 21 October 2026, after details leaked the day before. The vulnerabilities, rated 9.2 out of 10 in severity, reportedly lay hidden in the codebase for more than a decade. What changed was not the flaw itself, but the cost of turning it into a working attack: according to the security companies behind the find, it was modern AI models that made it possible to build a real exploit – and within hours of the announcement, Cloudflare reported millions of exploitation attempts.

What PHP2Shell is

The two vulnerabilities, registered as CVE-2026-109618 and CVE-2026-109619, sit in the parts of PHP that nearly every request touches: memory management and error handling. Together, they can reportedly potentially allow attackers to execute code without authentication and read memory that may contain sensitive information such as passwords (4989a813, e23ab1d3).

Since PHP underpins a very large share of the web's dynamic pages – Wiz researchers described the language as "a backbone of the web" – the flaw's reach extended far beyond the developer community.

Who found the flaws – and with what

According to AFP's reporting, the security company Calif found the vulnerabilities in August of this year, using OpenAI's model GPT-5.6 Sol, as part of an OpenAI-funded audit of the PHP code. OpenAI itself called the discovery "a new phase, where AI can find security flaws with internet-scale impact" (2a995d35).

Weeks later, the security company Wiz found the vulnerabilities independently, also reportedly with the help of AI models, including Gemini 4 Argon and GPT-5.6 Sol. It should be stressed that the model names are so far known only through secondary reporting and cannot be verified against primary sources.

Wiz's researchers wrote in a blog post on Wednesday that "what AI changed was the ability to understand the vulnerabilities and turn them into a working exploit," and that "with frontier models and the right tools, one researcher in a week completed what would previously have required months of work from a world-class team" (e23ab1d3). That is the company's own assessment, not an independently verified scorecard.

Why the flaw lay unused for years

The most striking thing about PHP2Shell may not be the discovery, but the story behind it. In its technical article, Calif traced a related weakness back to 2004, when security researcher Stefan Esser demonstrated a similar problem in PHP connected to memory exhaustion. In 2020, a related bug report was submitted – and was nearly ignored. In 2024, a third-party-funded security review of PHP ran into the same problem area, but it was never fixed, because no one could prove that it could actually be exploited (0862c340).

The PHP Foundation itself acknowledges that its own developers first spotted signs of the problem during an external audit in 2024. A theoretical exploit was sketched out, but without a concrete attack path – and with a very small core team that had to weigh the cost of an extensive fix against an uncertain payoff – the work stalled, then resumed and stagnated over months. The Foundation calls the delayed fix "a structural failure" (4989a813).

Independent author Nick Rogers, cited in coverage of the analysis, points to the mechanism: turning this kind of vulnerability into a usable exploit traditionally requires "weeks of tedious manual debugging," and previously no one was willing to pay that price (0862c340). That is the cost that AI in practice collapsed – according to the companies. The vulnerability itself is two decades older than modern language models, and the claim that AI was strictly necessary is Wiz's and its partners' framing, not a proven fact.

The leak and the accelerated patch

The PHP Foundation had planned to release the updates on Thursday. But news of the vulnerabilities leaked first in online forums, and then from Calif itself, which accidentally posted a video on Tuesday demonstrating a full exploit chain (ab992636). The Foundation then chose to release the updates roughly 24 hours ahead of schedule, at 10 a.m. US Eastern time on Wednesday 21 October.

It was thus not the planned, coordinated disclosure that started the clock, but a leak – a pattern that often makes the situation more dangerous, because defenders have less of a head start than attackers.

Hours of millions of attempts

The reaction came quickly. Matthew Prince, chief executive of Cloudflare, said in the early hours of Thursday that the company recorded tens of thousands of exploitation attempts within the first 45 minutes after the announcement, growing to "hundreds of thousands within two hours, and millions now" (21994a11).

There was also activity around the vulnerability before the official disclosure. According to the reporting, Amazon Threat Intelligence says the company observed an exploitation attempt as early as 17 October, while the information was still under embargo. The monitoring firm VulnCheck says its honeypots captured scanning and at least one exploitation attempt from an IP address in China, targeting CVE-2026-109618 – the flaw that potentially allows an attacker to execute unauthorized code. The attempt failed with a 404 error (c27c64ba).

How serious was it really? An unsettled picture

Here the sources diverge, and it is worth quoting all of them:

• Elizabeth Barron, chief executive of the PHP Foundation, told CNBC on Wednesday afternoon that the organization was "monitoring the situation closely," but that there is so far no "evidence of any working exploits, only incomplete, misleading and non-functional generated ones" (ab992636).
• Matt Suiche, security researcher at the company Tolmo, claimed by contrast, according to CNBC, that his team had coded a working exploit in under a day, with the help of AI (ab992636).
• Amazon Threat Intelligence has, according to the reporting, claimed that PHP2Shell is being "broadly exploited in the wild" (21994a11).
• Ryan Austin, a researcher at Calif who was central to the discovery, said: "So far it doesn't look like the exploitation has taken off or is widespread" (21994a11).

The difference partly comes down to what is being measured. Cloudflare's millions are attempts – traffic that looks like exploitation attempts. That is not the same as confirmed break-ins. How many of the attempts succeeded, and whether any systems were compromised before the update was available, remain unknown. That is the most open – and uncomfortable – question left in this story.

What website operators should do

The concrete advice is unambiguous: update PHP servers to the patched versions as quickly as possible. Even though evidence of successful attacks is so far lacking, the volume of attempts alone is enough to make unpatched servers attractive targets. Operators who cannot update immediately should consider whether PHP services need to be exposed to the internet at all while the fixes are rolled out.

The bigger pattern

PHP2Shell illustrates something that could become a recurring pattern in security work going forward. The vulnerability itself was theoretically known for years – sketched in a 2024 audit, with roots in 2004 research. What was missing was not the knowledge, but an economically rational path from "possibly exploitable" to "exploitable." That path was previously so costly that no one took it – neither defenders nor attackers. When one researcher with language models can, according to Wiz, complete the journey in a week, the calculus changes for all parties at once.

The implication is that the window between "theoretical vulnerability" and "real weapon" is likely shrinking. For software projects, that means the argument "no one has proven this can be exploited" grows weaker every year – someone may be able to prove it quickly, and cheaply. For the many servers that remain unpatched, the practically important lesson is simpler: theoretical flaws further out on the timeline can return as practical attacks faster than anyone has reckoned with.

As long as the disagreement between the PHP Foundation, Amazon and Calif over actual exploitation remains unresolved, the honest answer to the question of whether your data has been affected is: possibly, and no one knows for sure yet.