Expert views: what the PHP2Shell fallout teaches about patching and disclosure

Joe Tidy: an AI story, and not how defence should work

Joe Tidy wrote on Bluesky that this is also an AI story, because the flaws were found with frontier models.

Joe Tidy wrote that a leak forced a rushed, panicked patch as criminals raced to build an exploit from it. He did not say who he meant.

The PHP Foundation sees the AI side too. It says AI-assisted research means its security team now receives far more reports than before.

The PHP Foundation's account, and Chainguard's reply

The PHP Foundation published its own account on 21 October 2026. It says the two CVE IDs began circulating on online forums and social media on 20 October, at around 15:00 UTC. The PHP project then moved the release from 22 October to 21 October, at 14:00 UTC.

The Foundation says Calif, one of the security firms that reported the flaws, mistakenly published a video. It says mitigation advice given to a few critical infrastructure providers may have leaked as well.

The Foundation says Chainguard published built images containing the fix at 07:41 UTC on 21 October, more than six hours before the coordinated release. It says this broke the embargo. Like other distributors, Chainguard had received the patch in advance.

Chainguard's chief executive, Dan Lorenc, gave Chainguard's side on LinkedIn. Dan Lorenc wrote that several of the other security vendors in the process confirmed seeing exploits in the wild. Lorenc wrote that he then made the call to ship the fixes and immediately notified the group.

Dan Lorenc wrote that Chainguard independently found the same issue using its own harness and a frontier model. Lorenc wrote that his decision rested on how easily Chainguard found the flaw and built an exploit. It also rested, he wrote, on how much information was already out and on the evidence shared on active exploits.

Dan Lorenc wrote that Chainguard made the built artifacts publicly accessible for anyone, not just its customers. Lorenc also wrote that the PHP Foundation and maintainers did an amazing job in a high stress situation. Lorenc wrote that he is sorry his decision led to even more stress for them.

The Foundation is also open about its own part. It calls the long delay in fixing the underlying problem a structural failure of its decision process and its lack of resources.

Amazon: attacks can start before the advisory

Amazon Threat Intelligence found an attempt to exploit PHP2Shell in its MadPot honeypots, dating to 17 October 2026, four days before public disclosure.

Amazon says it remains unclear how the attacker got the information. It also says it is unclear whether any of the attempts would have succeeded against real systems.

At the time of the release, the PHP security team had not found any working exploits. CISA said it had not seen exploitation when it published its alert on 21 October 2026.

Amazon's view is that an embargo protects defenders only until someone else finds the same bug. It says coordinated disclosure is still the right model. It also says AI-assisted analysis makes it cheaper to turn a patch into a working exploit.

Graham Cluley: asking questions is the right instinct

Graham Cluley wrote on Bluesky that hundreds of people were mocking Joe Tidy for admitting he did not know what PHP was.

Graham Cluley's view is that asking questions is what good journalists do, and pile-ons are what bad communities do.

The same instinct helps a firm that buys its website from a supplier. PHP says Linux distributions and long-term support vendors received the patches in advance, so check with your vendor for updated packages.

CISA says PHP is often part of other software, so it may not be easy to see where it runs. The NCSC asks organisations to watch for updates from vendors of appliances and services that may bundle PHP.

Amazon advises starting any investigation from the earliest known exploitation, which for PHP2Shell means from at least 17 October. The NCSC advises checking for evidence of compromise and for backdoors.

What happens next

The PHP security team is changing its processes so that decisions can be made by majority. The Foundation is also changing processes so its leadership can help steer a stuck fix to a timely resolution.

PHP now suggests turning off session upload progress until its next regular bugfix release, to protect against an unlikely further attack route. It says this further issue is unlikely in practice, so it is handling it in the regular release cycle.

The NCSC says it will continue to monitor for any impact on UK organisations. For firms that want a way for researchers to report flaws to them, the NCSC Vulnerability Disclosure Toolkit covers the basics.