Chainguard stands by early PHP patch release as security community debates disclosure timing

During KubeCon + CloudNativeCon North America 2026, Chainguard co-founder and CTO Matt Moore publicly justified the company's decision to ship patched PHP container images ahead of an October 21 coordinated security release window. The move triggered criticism from PHP's maintainers, who said Chainguard had given attackers a window of opportunity. Chainguard countered that hostile actors had already begun targeting the flaws.

In remarks to The New Stack, Moore stated, "We own the decision that we chose to do it. Nobody could force us to do it — but we did not do it in a vacuum." He outlined conversations with other embargo participants and reports from security vendors documenting attack activity targeting the vulnerabilities before Chainguard's release at 07:41 UTC.

The company did not claim to have patched the flaws faster than others, Moore explained. Rather, Chainguard assessed that attackers could already exploit the bugs or were actively attempting to reverse-engineer them.

The vulnerabilities and their severity

Two critical flaws—CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state)—collectively dubbed PHP2Shell involved fundamental memory-management and error-handling defects. Under certain conditions, an unauthenticated attacker could achieve code execution on a PHP server.

The first vulnerability stemmed from PHP's handling of memory exhaustion. If a memory limit was reached at the wrong moment, PHP could fail to complete internal data setup. Subsequent processing might then treat incomplete data as valid. The second flaw involved PHP retaining references to memory from earlier requests that had already been freed, allowing a later request to access that invalid memory. Both scenarios could enable remote code execution under exploitable conditions.

Researchers demonstrated remote code execution through both Apache/mod_php and PHP-FPM application-level paths for the first vulnerability, and against a real-world Apache/mod_php application for the second.

PHP assigned both vulnerabilities a CVSS v4.0 score of 9.2, marking them as critical. The actual exploitability varied depending on PHP build configuration, server settings, extensions, and application behavior. PHP released fixes in versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The potential reach was substantial: as of November 11, W3Techs reported that PHP powered 68.8% of websites whose server-side programming language could be identified.

How the disclosure process fractured

According to the PHP Foundation, a developer reviewing findings from a 2024 security audit initially identified the out-of-memory issue, though no concrete attack method emerged at that time. Proposed fixes carried risks of compatibility breaks, new denial-of-service conditions, or changes affecting PHP extensions.

On August 11, researcher Ryan A. from Calif reported remote code execution stemming from the same underlying problem. This discovery elevated fixing the flaw to the PHP Foundation security team's highest priority. OpenAI independently reported the same vulnerability. Wiz contributed additional attack vectors on August 24, followed by further reports from OpenAI on September 18.

PHP's maintainers coordinated fixes with researchers and distributors, but the release process began to unravel. On October 20, CVE identifiers leaked publicly along with an incorrect release time and severity rating. PHP responded by issuing an advisory and accelerating the release to October 21 at 14:00 UTC. Calif, one of the reporting security firms, mistakenly published a video demonstrating its proof of concept; although deleted, copies spread. PHP also acknowledged that guidance provided to critical infrastructure operators may have been compromised.

The information landscape was already chaotic before Chainguard took action. The PHP Foundation maintained that its remaining coordination window still held value—specifically, distributors were still packaging the fixes, and an immediate release would leave many users without a straightforward update path. At 07:41 UTC on October 21, Chainguard published its patched images anyway, six hours and 19 minutes before the scheduled time.

The PHP Foundation responded sharply: "Chainguard unilaterally broke the embargo and published built images containing the fix." This meant, the foundation argued, that "any attacker could now study the fix in binary form while every other PHP user was still waiting for the release."

A patched binary protects the person who installs it. It can also tell an attacker where to look.

PHP Foundation

Moore's case: Attackers already had momentum

Moore did not deny that releasing patched binaries can aid attackers. He contended, however, that the protective advantage an embargo was meant to preserve had already eroded by that point.

When only defenders possess knowledge of a vulnerability, Moore told The New Stack, confidentiality provides time for preparation. Once attackers gain sufficient information to exploit it, withholding available fixes can flip the advantage: attackers can act while users outside the embargo remain defenseless.

"If we see exploitation in the wild, it's incumbent upon us to release it," Moore said. According to his account, reports from other security vendors drove Chainguard toward this decision.

Chainguard learned of the PHP vulnerability on the Friday before the release, Moore said, deployed its vulnerability-hunting tools against the software, and identified the flaw or produced a proof of concept within hours. This account of Chainguard's own research process informed the company's thinking on breaking the embargo: if Chainguard's tools could find the bug quickly, attackers' tools might do the same.

Moore also rejected the suggestion that Chainguard acted unilaterally. Other embargo participants contacted Chainguard CEO Dan Lorenc while PHP maintainers in Europe were offline to discuss the situation, he said, though he declined to name those participants. Moore acknowledged that Chainguard made the final call, but distinguished the company's account of a contested emergency decision from one in which it ignored all other voices.

What the evidence actually shows

Public data supports Chainguard's concern that attackers were already probing the vulnerabilities. Amazon Threat Intelligence documented a PHP2Shell exploitation attempt against its MadPot honeypot network on October 17, four days before public disclosure. It also logged proof-of-concept exploits beginning around 02:00 UTC on October 21, with additional attempts from anonymized infrastructure over the following six hours. Some of this activity clearly preceded Chainguard's 07:41 release.

Cloudflare reported observing attack traffic targeting its customers before the official release. Its free and paid web application firewall protections activated by default starting at 03:02 UTC on October 21.

Chainguard was not inventing hostile interest in these bugs. However, Amazon included a significant caveat: "Technical analysis is ongoing, and it's unclear if any of these attempts would have succeeded in real-world systems." The PHP security team stated it examined circulating proofs of concept and "did not identify any functional exploits at the time of release/public disclosure."

These statements need not contradict each other. A honeypot can record an exploitation attempt without confirming that it achieves remote code execution against a production application. Similarly, PHP's inability to locate a functional public exploit does not rule out the possibility that private attackers possessed one.

Later evidence should not be conflated with what was known that morning. On October 26, CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog, confirming that exploitation was documented by then. This does not establish when the first successful compromise took place or whether Chainguard's early release enabled it.

Did the binaries hand attackers new advantages?

Moore's second argument is more specific. Attackers were already examining the relevant code, so releasing patched binaries might not have provided much additional benefit.

"I don't see any evidence that what we did helped the attackers in ways that they didn't already have," he told The New Stack. He acknowledged that comparing patched and unpatched binaries can pinpoint vulnerable code, including through AI-assisted disassembly. But identifying the code, he argued, differs from building a working exploit.

That distinction holds some weight. Finding a memory-corruption bug and reliably weaponizing it into remote code execution represent separate engineering challenges.

Yet this defense has boundaries. Evidence that some attackers knew where to look does not establish that all prospective attackers did. Nor does it prove that the patch contained no useful information beyond the vulnerability's location. Chainguard's argument hinges on how much actionable information was already in circulation and how reliable it was.

The same caution applies to the accusation against Chainguard. Publishing the binaries created an opportunity to study the changes. It does not, standing alone, demonstrate that a particular breach occurred because Chainguard released early.

The two sides were weighing different risks. Chainguard stressed the danger of withholding a ready patch from users while hostile activity was documented. PHP stressed the danger of distributing new information before the broader ecosystem could update. Both risks were genuine.

AI accelerates the timing crisis

A deeper concern is that AI-assisted vulnerability research could compress the window defenders have to respond. The public accounts cited here do not clarify whether the pre-release PHP2Shell attempts employed AI, or whether this was an isolated incident.

For Moore, the PHP dispute exemplifies a larger challenge: attackers' capacity to convert vulnerability information into an exploit may outpace defenders' ability to build and distribute a fix.

He outlined a scenario in which a Chromium patch becomes public and an attacker develops an exploit faster than it takes to compile the browser. This was a caution about the industry's trajectory, not a claim that this specific scenario had transpired.

"You literally cannot produce builds fast enough," he said. And building is only the start. Even if Chainguard produces an updated image rapidly, customers must still integrate it, rebuild their applications, test them, and roll out the changes.

Faster does not mean instantaneous, and a supplier's release time is not a customer's remediation time.

Matt Moore

That is the uncomfortable reality of the "patch faster" approach. Speed matters. Speed does not equal immediacy, and when a supplier releases an update is not when a customer finishes patching.

Moore's longer-term proposal focuses on reducing the number of vulnerabilities that trigger this race. He discussed with The New Stack efforts to develop ABI-compatible replacements for foundational software components written in Rust, along with formal verification methods designed to eliminate specific categories of defects. These remain engineering objectives awaiting evaluation.

They also do not address, in the view of Chainguard's critics, what the company should have done on October 21. A future with fewer memory-corruption bugs would be desirable, but administrators managing current bugs still need a functional disclosure process, they would contend.

The implications extend beyond one vendor

It would be tempting to frame this solely as a story of one vendor violating the rules. It would be equally tempting to portray it as an agile security company rescuing users from a sluggish upstream maintainer. Neither characterization captures the full picture.

PHP's own postmortem identifies a deeper structural problem. The foundation characterizes the delay as "a structural failure," rooted in both decision-making and insufficient resources.

Discovering bugs faster does not automatically supply the engineers required to fix them safely. And having a patch ready at one company does not mean an ecosystem of distributions, hosting providers, extensions, and applications stands ready to deploy it.

Many observers moved quickly to condemn Chainguard's choice. Jay Gazlay, CISA's acting associate director for vulnerability management, stated at an October 28 Red Hat conference in Washington: "that type of behavior is dangerous, and we've got to be careful about holding embargoes."

Reconciliation may still be possible. Federal News Network, citing Politico, reported that PHP Foundation Executive Director Elizabeth Barron expressed disappointment with Chainguard but indicated a desire to rebuild trust and maintain collaboration.

Moore characterized it as "a really tough call" between "two really, really bad choices." He is correct.

Maintainers and distributors need to establish in advance the conditions for lifting an embargo early, who holds that authority, and how other distributors will deliver fixes to their users. This work must happen soon. Otherwise, the next incident will unfold identically, with vendors disputing who broke the embargo while administrators scramble to determine whether they can patch before attackers compromise their systems.