Chainguard

PHP2shell

PHP2shell is the collective name for two PHP vulnerabilities published on October 21, 2026. Both lead to remote code execution (RCE), and each was given a CVSS v4.0 score of 9.2.

• CVE-2026-109618: depending on the timing at which the memory limit (memory_limit) is reached, internal data that has not finished initializing is treated as valid, corrupting memory. In Apache's mod_php it is triggered by an unauthenticated request before the application's code runs, and RCE under default settings was demonstrated
• CVE-2026-109619: depending on where a fatal error occurs, internal state is left pointing at the previous request's memory, causing a use-after-free. RCE was demonstrated on a real application running on mod_php

The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. According to Wiz, every PHP release from 5.4 onward, roughly the past ten years, is affected by at least one of the two.

According to the PHP Foundation's account, signs of the problem had already been found during an external audit in 2024, but no way to exploit it was found at the time and it was set aside. On August 11, 2026, a researcher at Calif reported an unconditional RCE with the same root cause, followed by Wiz (August 24) and OpenAI (September 18). All of these investigations are said to have used AI models. The PHP side acknowledged that the fix took time because of the way the security team's decision-making proceeded and a shortage of people.

Confusion from the day before publication

From the day before publication, leaks of information followed one after another. Times are in UTC.

• Friday, October 16: Chainguard learned from one of the researchers that a PHP announcement was near, and that night used its internal AI system to find the same vulnerability independently. From the next day it joined the coordinated disclosure communication channel and helped test the fix
• Saturday, October 17: Amazon's honeypot MadPot detected the first attempted attack. Where the attackers got their information is not known
• Tuesday, October 20, around 15:00: the two CVE numbers circulated on forums and social media, together with a wrong release time and a wrong CVSS score (10.0)
• Same day, 19:30: PHP announced in advance that it was moving the release forward by a day, from 14:00 on October 22 to 14:00 on October 21
• Same day, around 20:00: Calif accidentally published a proof-of-concept (PoC) video of the attack. It was deleted at once, but copies spread
• Same day, around 23:00: mitigations communicated to critical infrastructure operators may have leaked
• Wednesday, October 21, 07:41: Chainguard published images containing the fix
• Same day, 14:00: PHP officially released the fixed versions

The dispute over Chainguard's early distribution

Chainguard, like other distributions, had received the fix in advance so that users could update at the moment of publication. The PHP Foundation criticized the company for unilaterally breaking this arrangement. Its argument was that Chainguard had created a state in which the content of the fix could be examined in binary form before the official release, ignoring a coordinated disclosure that many parties had spent weeks advancing. It also stated that, at the time of the official release, it had not confirmed any actually working exploit code.

Lorenc admitted the early publication but countered that the company had not leaked anything. The company's policy is coordinated disclosure, he said, with an exception when there is evidence of active exploitation. On the night of October 20 to 21, late at night in Europe where many PHP developers are, multiple vendors on the communication channel reported attacks taking place, and the company judged that damage was occurring before publication and went ahead with distribution. The images with the fix were published in a form available to anyone, not only to customers, and he rejected the view that it was done for the company's own customers. While he said it was regrettable to have burdened the PHP Foundation and the developers, when asked whether he would make the same decision again, he answered that he would not change it.

The case also drew attention to the fact that the speed at which open source developers can issue fixes is no longer keeping up with the speed at which AI finds vulnerabilities. Lorenc cited the fact that his company's AI found the same vulnerability overnight from a simple instruction, and said that exploit code being produced within hours is becoming "the new normal".

Attacks after publication

According to Cloudflare CEO Matthew Prince, the company's network observed thousands of attack attempts in the ten hours before publication, tens of thousands within 45 minutes after it, and hundreds of thousands within two hours. Chainguard's honeypots are said to have captured attacks mainly from IP addresses in China and Russia. On the other hand, much of the exploit code circulating on GitHub and elsewhere was fake or was removed while still incomplete, and Lorenc also said that an attack requires knowledge of the target environment and is not easy. The full extent of the damage is not yet known.