The PHP Foundation has confirmed that Chainguard broke embargo, causing a lot of undue chaos.
Read here for more information about that, and the Foundation’s efforts: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
“On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.”
It seems that Chainguard released their binaries 55 minutes before public exploitation was seen online, making it very hard to see past the probable causation that Chainguard caused the early exploitations to commence, which made this incident far worse than it had to be - as PHP say, undoing weeks of coordinated, careful work.
The PHP Foundation have detailed how the OOM problems were almost discovered back in 2024.
“In 2024, PHP underwent its first external security audit in years. The PHP Foundation secured funding from the Sovereign Tech Agency to organise this audit through OSTIF, and it was carried out by Quarkslab. While fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs of the OOM problem behind CVE-2026-109618. In 2024, a potential exploit for the OOM problem was theorised, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns.
To fix the OOM problem, the PHP security team developed several competing approaches, but each came with its own trade-offs: backward compatibility breaks, new denial-of-service potential, or requiring changes to many third-party extensions which seemed impossible to coordinate. The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice. Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months.”
Part of our escalation with CloudLinux is seeking for them to become a trusted party by PHP, to reduce delays in the future when vulnerabilities are published - as if they had that status before today, it should’ve been fast.
We’ll continue to share further updates, and are providing this to give context around the vulnerabilities.