“It’s understandable that people are confused about how this unfolded. Word of the vulnerabilities leaked on Y Combinator’s Hacker News forum two days before the planned disclosure, and PHP moved its security release up a day in response. The source of the leak hasn’t been identified, but there’s no evidence a threat group was involved, and no exploit code was released. A screenshot of the researchers’ exploit tool did circulate, which added to the alarm. In the end, the early reports were largely accurate. The main difference is severity: PHP officially rates both flaws 9.2 rather than the 10.0 some reports cited. That’s still critical, and it doesn’t change the advice.

“The organizations I’m most concerned about are the ones that don’t know where PHP is running in their environment. Older versions sitting in containers, appliances, or legacy sites won’t receive an official fix. Nobody wants to be building a software inventory in the middle of an emergency. You need that visibility before the next one hits.”

Tim Mackey, Head of Software Supply Chain Risk Strategy at Black Duck, adds, “Preventing leaks of any vulnerability data for a CVE prior to an embargo for the patch being published is precisely what coordinated vulnerability disclosure processes are designed to protect against. When a leak, or advance knowledge, of a vulnerability occurs the entire ecosystem surrounding the vulnerability is placed at risk. As details of the leak are published, security defenders are faced with the real risk that malicious actors could use the absence of an official patch to supply their own malicious patches. 

“Defenders should pay extra attention to the origin of their patches and validate functional changes against official release notes. After all, a malicious patch could implant a backdoor for future use and a rush to patch might present the right opportunity for malicious actors.”