Skip to main content
CybersecurityVulnerability Management

Chainguard's Early Disclosure Sparks PHP Vulnerability Controversy

Developer workstation with laptop, notebook, and coffee on a minimalist desk in a bright, daytime setting.

"Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4," Wiz researchers warned, summarizing why two newly disclosed bugs have put a sizable fraction of the public web on alert.

How the disclosure unfolded

PHP maintainers say the incident began on Tuesday around 15:00 UTC when "two CVE IDs began circulating on online forums and social media" along with incorrect details about timing and severity. That chatter led maintainers to move a planned Thursday disclosure forward by one day to Wednesday so that distributors would have a simple update path when the vulnerabilities were published. The project blog said distributors were still packaging the fix and that moving the release by one day "was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path."

Shortly after the schedule change, Calif "mistakenly" published a video showing a proof-of-concept exploit and additional limited information. The PHP blog noted mitigation advice the project began providing to "a few critical infrastructure providers around Oct 20th 23:00 UTC" may also have leaked, though the blog did not name those providers. Then, the blog says, Chainguard published built images containing the fix on October 21 at 07:41 UTC — "more than six hours before the coordinated release" — which, the maintainers argue, allowed anyone to study the fix in binary form while other PHP users were still waiting for the coordinated disclosure.

Chainguard's decision and public defense

Chainguard CEO Dan Lorenc acknowledged his company shipped fixes early but rejected the label of a leak. Lorenc told The Register Chainguard "didn't leak" and that the company "made the call." He said Chainguard learned "something was coming in PHP" on the prior Friday from one of the researchers, then used its AI harness and a frontier model to independently find the same memory corruption vulnerabilities after a "basic prompt of 'find bad vulnerabilities in PHP.'"

According to Lorenc, Chainguard began working with PHP maintainers on Saturday, confirmed some findings matched the bug reports, and helped test the patches. On Tuesday night, facing reports of proofs-of-concept and alleged real-world exploitation, Lorenc said he decided to ship the fixes and notified the coordinated disclosure channel. Chainguard published built artifacts and made them accessible to anyone, not just customers. Asked whether he would do anything differently, Lorenc said no: "This process and policy is based on trying to coordinate as much as possible until shit hits the fan and people start weaponizing things." He added that Chainguard's honeypots trapped IPs from China and Russia targeting the vulnerabilities on Wednesday.

The technical core: CVE-2026-109618 and CVE-2026-109619

Two memory-corruption vulnerabilities now tracked as CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) allow unauthenticated remote code execution, according to the published findings and researcher statements. Both are tied to how PHP handles memory management and error handling and can lead to a corrupted internal PHP state when a request ends unexpectedly; a later request can reuse that state with disastrous effect.

The project maintainer wrote that CVE-2026-109618 leads to RCE via out-of-memory corruption: "If a request reached PHP's memory_limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory." For CVE-2026-109619, "a fatal error at the wrong point could leave internal state pointing to memory that belonged to a previous request," the PGP Foundation wrote, noting a use-after-free and worker crash were confirmed and a reporter demonstrated remote code execution against a real-world application running on Apache with mod_php. VulnCheck researcher Patrick Garrity summarized: "Both are memory corruption vulnerabilities... If an attacker can shape the memory PHP trusts, they can potentially hijack what it does next, and in these cases that means remote code execution."

Impact on servers, exploitation, and immediate guidance

Wiz researchers warned that "successful exploitation could allow attackers to take control of affected servers, steal sensitive data, and deface the websites running on them," and cited the commonness of PHP: "PHP powers 70 percent of all websites in the world." The Wiz team added that "Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4," and concluded that "Immediate patching is strongly advised."

The project maintainer also noted a specific attack vector: "On Apache with mod_php, an unauthenticated request can trigger" the out-of-memory corruption before any application code runs — underlining why operators running mod_php should prioritize updates.

How technologists, distributors, and website operators are responding

  • Technologists and security teams: Security teams will be triaging signs of exploitation, applying the emergency patches the PHP project released, and heeding the Wiz admonition that "immediate patching is strongly advised."
  • Distributors and packagers: The PHP Foundation blog said distributors were still packaging fixes when the disclosure was accelerated; Chainguard's unilateral publication of built images shifted the dynamics and raised questions — within the record here — about tradeoffs between early fixes and coordinated embargoes.
  • Website operators and end users: Operators running affected PHP versions — including legacy builds back to 5.4 per Wiz's note — should apply available patches and follow any published mitigation guidance, especially those running Apache with mod_php where unauthenticated requests can invoke the flaw.

The immediate fact is blunt: fixes were published and emergency patches are available, and multiple researchers — including teams at Calif, OpenAI, and Wiz — used AI models to find the bugs between August and September. Whether unilateral early shipping of built images by a distributor will become a more common response to active exploitation is left unresolved in the record, but for operators the practical order is clear in the researchers' own words: "Immediate patching is strongly advised."

Original story