By JD Bungart in Open Source — 22 Oct 2026

Chainguard Broke the PHP Embargo by Six Hours. That Was the Wrong Call

Chainguard shipped fixed PHP images more than six hours before the coordinated October 21 release, citing exploits in the wild. Here is how embargoes work, what Chainguard says, and why I still think releasing early was the wrong call for open source.

Photo by Julia Taubitz on Unsplash

On October 21, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical remote code execution bugs, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Full unauthenticated remote code execution was demonstrated on Apache with mod_php with default settings, before any application code runs. On PHP-FPM, the Foundation reports remote code execution through application-level code paths, though the official oss-security advisory says no complete FPM exploit was shown. I covered the release itself here, so this post is not about patching. If you run PHP and have not updated, stop reading and do that first. The php.net advisory has the versions and the interim mitigations.

This post is about one decision during that release. According to the PHP Foundation, Chainguard published built container images containing the fix on October 21 at 07:41 UTC (3:41 PM PHT). The coordinated release was set for 14:00 UTC (10 PM PHT). That is a gap of more than six hours. I think it was the wrong call, and I want to explain why without pretending the other side has no argument.

How an embargo is supposed to work

When a serious bug is found in a widely used open-source project, the maintainers build a fix in private and share it ahead of time with the people who ship that software to users: Linux distributions, LTS vendors, image builders. Everyone agrees on a public date and time. Until then, nobody publishes anything that reveals the fix.

The best-known version of this is the distros and linux-distros mailing lists run by Openwall. Their policy caps embargoes at 14 days and says members must not make embargoed information public, or even hint at it, until the agreed date or substantially complete publication by others. It goes further and says members must not share the information "in any derived form (not even through delivering or deploying undocumented fixes)." A built binary with the patch inside is exactly that kind of derived form.

I am not claiming Chainguard was a member of that list or bound by its text. The PHP Foundation says only that Chainguard, "like other distributors," had received the patch in advance. I cite the Openwall policy because it spells out the norm the whole ecosystem works under: you get early access so your users can update the moment disclosure happens, not before.

The reason is simple. A fix is a map to the bug. Once patched code is public, in source or binary, anyone can diff it against the previous version and work backward to the vulnerability. Embargoes exist to make sure that map appears for everyone at the same time.

What happened on October 20 and 21

The Foundation's timeline, all from its post:

Oct 20, around 15:00 UTC (11 PM PHT): the two CVE IDs leaked on forums and social media, with a wrong release time and a wrong CVSS score of 10.0. The real score is CVSS v4.0 9.2. No technical details leaked.
Oct 20, 19:30 UTC (Oct 21, 3:30 AM PHT): PHP published its pre-announcement and moved the release up a day, to Oct 21 at 14:00 UTC, because distributors were still packaging.
Around 20:00 UTC: Calif, one of the reporting firms, mistakenly published a proof-of-concept video. Copies circulated after it was deleted.
Oct 21, 07:41 UTC (3:41 PM PHT): Chainguard published images containing the fix.
Oct 21, 14:00 UTC (10 PM PHT): the coordinated release.

The Foundation says its security team inspected the PoCs that appeared after the leak and "did not identify any functional exploits at the time of release." It also wrote that "any attacker could now study the fix in binary form while every other PHP user was still waiting for the release."

Chainguard's side

Chainguard has not published a blog post or advisory about this as far as I can find. Its CEO, Dan Lorenc, has explained the decision in public, and his reasoning deserves a fair hearing.

The patched images did not go unnoticed. A Hacker News commenter pointed to them at 06:07 UTC on October 21, and Lorenc confirmed the decision in the same thread at 06:18 UTC. In that comment he wrote: "We've been working with the team on the coordinated disclosure, but I made the call to get these out early when exploits hit in the wild." He praised the maintainers, said Chainguard had tested the patch extensively, and said the images were free and would stay that way.

He went further in an interview with The Register. He said Chainguard learned "something was coming in PHP" from one of the researchers, then independently found the same bugs with an AI harness and a frontier model, and later helped the maintainers test the patches. He said other security vendors reported real-world exploitation, that he notified the PHP coordinated disclosure channel before shipping, and that the artifacts were open to anyone, not only customers. His summary: "It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild." Asked whether he would do anything differently, he said no.

That position matches Chainguard's own Coordinated Vulnerability Handling Policy, which reserves the right to shorten timelines if a vulnerability is under active exploitation, if details are already public, or in other exceptional situations, and promises to notify the reporter when it does.

So this was not a careless leak. It was a deliberate call by someone who knows how embargoes work, made under real pressure, with a stated reason. I take that seriously.

Why I still think it was the wrong call

First, the evidence, because it cuts both ways. Lorenc was not making it up. According to Tenable's FAQ, Amazon Threat Intelligence observed a php2shell exploitation attempt against its honeypot network on October 17, four days before disclosure, and Cloudflare CTO Dane Knecht said on October 21 that Cloudflare was "seeing early attacks emerging." At the same time, the Foundation says the PoCs it inspected after the leak were not functional at release time, and Amazon itself says it is unclear whether the October 21 attempts would have succeeded against real systems. Reasonable people can read that picture differently. That is exactly why I do not think one vendor should be the one reading it for everyone.

Second, the math. If attackers already had working exploits, an early patch in one vendor's images helps that vendor's users and changes little for attackers. If they did not yet, a published binary fix hands them a shortcut. With about six hours left and the evidence still disputed, the coordinators were the ones in a position to weigh those two risks for everyone. Users of every other distribution were still waiting on the agreed time, and so was everyone building from source.

Third, the decision belonged to the coordinators. Chainguard did notify the coordination group before shipping, and I give it credit for that. But notifying the group is not the same as getting agreement. PHP's own pre-announcement said it would release earlier if details became public or active exploit evidence appeared, and it had already moved the release up once that week to deal with the leak. If Chainguard had evidence of exploitation, the right move was to put it in front of the coordinators and push them to move the whole release earlier for everyone, not to ship alone.

Fourth, trust is the whole system. Embargoes only work because maintainers can hand patches to downstream vendors and expect them to hold. Lorenc made the point better than I could in his July post, Summer of Clearinghouses: "The fix is the map, so pre-disclosure protection extends exactly as far as the people you can vet and hold to an embargo." I agree with that line. If vendors start treating their own policy as overriding the project's schedule, maintainers will respond the only way they can: share less, share later, and with fewer people. That hurts every user, including Chainguard's.

What I would like to see

Nobody here is a villain. The PHP security team owned its own failure in plain words: the fix stalled for months, and the Foundation called that "a structural failure." Calif's video was a mistake. Chainguard made a judgment call under pressure. The leak of the CVE IDs started the chaos before any of them acted.

A few things would help next time:

Embargo agreements should say up front what happens if exploitation is reported, who decides, and what evidence they need to see.
A vendor that believes it must break an embargo should ask the coordinators to move the release for everyone first, and only act alone if that fails.
Exploitation evidence used to justify an early release should go to the coordinators first, so they can decide for everyone, and be published afterward.
Companies that depend on PHP should fund the PHP Foundation, so the security team is not stretched this thin when the next one lands.

AI tools are making it faster to find bugs and faster to turn a patch into an exploit. Lorenc said as much himself. That is the strongest argument for holding embargoes more tightly, not loosening them. The few hours between a fix existing and a fix being public are now worth more than they used to be, and they only protect anyone if everyone holds the line together.