PHP Blames Chainguard for Blowing Critical Disclosure After AI Finds Huge Vulnerabilities
PHP's maintainers are furious at supply chain security firm Chainguard, accusing it of unilaterally torpedoing a carefully coordinated disclosure process for two serious vulnerabilities now tracked as CVE-2026-109618 and CVE-2026-109619. The bugs, collectively dubbed PHP2shell, allow unauthenticated remote code execution on servers running PHP. Given that PHP runs somewhere around 70 percent of the web, this is not a minor nuisance.
Emergency patches landed on Wednesday, accompanied by a PHP Foundation blog post that reads less like a technical debrief and more like a formal complaint. Researchers at Calif, OpenAI, and Wiz found the flaws between August and September, all using AI models to do it. The PHP team credited them, coordinated a Thursday disclosure, gave distributors advance access to patches so their users could update the moment the announcement went live. Standard responsible disclosure stuff.
Then it fell apart.
On Tuesday around 15:00 UTC, CVE IDs started circulating on forums and social media. No technical details, just the numbers and some wrong information about severity ratings and release timing. Enough to cause panic, not enough to patch. PHP maintainers moved the disclosure forward a day to Wednesday as a result, accepting that some distributors were still packaging fixes and that pushing it out immediately would leave users stranded without a clear upgrade path.
A few hours after that, Calif accidentally published a proof-of-concept video. Mitigation advice that had been quietly shared with a handful of critical infrastructure providers appears to have leaked too. And then, at 07:41 UTC on Wednesday morning, more than six hours before the coordinated release, Chainguard shipped container images containing the fix. Publicly. To anyone.
The PHP Foundation was not pleased. Having received the patch in advance precisely so its customers could update the moment disclosure happened, Chainguard instead handed any interested attacker a binary they could study while the rest of the PHP ecosystem was still waiting.
Chainguard's CEO says he'd do it again
Chainguard CEO Dan Lorenc is unapologetic. Speaking to The Register, he confirmed the timeline but pushed back hard on the framing. He says Chainguard first heard something was brewing in PHP on Friday, from one of the researchers who found the bugs. That same night, using an AI model and what he described as a basic prompt asking it to find serious vulnerabilities in PHP, Lorenc and his team independently discovered the same memory corruption flaws themselves.
By Saturday, Chainguard was working with PHP maintainers, had confirmed its findings matched existing bug reports, and was helping test patches. By Monday, rumours were spreading. By Tuesday night, Lorenc says, active exploitation had begun.
"People were getting hit in advance of the official disclosure," he told The Register. "So we made the call."
He notified the PHP coordinated disclosure channel before shipping, made the fixed images available to everyone rather than just Chainguard customers, and then woke up the next morning to find his company was being blamed for the whole mess.
Lorenc's position is essentially that coordinated disclosure is the right process right up until there is evidence of active exploitation in the wild, at which point waiting becomes indefensible. Chainguard's honeypots were already logging IPs from China and Russia targeting the vulnerabilities on Wednesday.
He also made a broader point that is worth sitting with. He found these vulnerabilities himself, on a Friday night, with no prior knowledge of them, using a general-purpose AI prompt. "Just being told there's a vulnerability in a piece of software is enough to find it," he said. "I think this is the new normal. People are able to build an exploit in hours without even knowing what the vulnerability is."
What the bugs actually do
Both vulnerabilities stem from how PHP handles memory and error conditions when requests terminate unexpectedly. A corrupted internal state can persist and get picked up by a subsequent request, resulting in memory disclosure or full remote code execution.
CVE-2026-109618 is the nastier of the two on Apache with mod_php. If a request hits PHP's memory limit at exactly the wrong moment, PHP can leave partially initialised internal data in place and later treat it as legitimate. On affected configurations, an unauthenticated request can trigger this before any application code even runs. No login required. No user interaction needed.
CVE-2026-109619 is cut from the same cloth. Both are memory corruption issues where a sufficiently motivated attacker who can shape the memory PHP trusts can redirect execution and achieve RCE.
Wiz researchers noted that every PHP version released in the last decade is vulnerable to at least one of these, going back to version 5.4. Given PHP's ubiquity and the age of many production deployments, the attack surface is considerable. Patch now, ask questions later.