PHP2Shell exposes the weakness in coordinated vulnerability disclosure

Two critical vulnerabilities discovered in the widely-used PHP programming language have shaken up enterprises, and the ramifications will take some time to truly understand. But one of the lesser-known stories centers around disclosure. According to The PHP Foundation , several organizations had agreed to a coordinated release detailing the critical flaws and mitigation actions, but cybersecurity firm Chainguard “unlaterally” broke this embargo. This prompted the PHP project to release its patches early, but also allowed attackers to study the fix in binary form and craft proofs-of-concept (PoCs) for exploits before defenders had a chance to update their systems. But some, including AWS and Cloudflare, contend that active exploits began hours, even days before the disclosure. By some estimates, there have since been millions of attempts to abuse the 9.2-severity-rated bugs, collectively known as PHP2Shell. Many organizations, including government bodies, have reacted by taking their websites offline altogether. “Frankly, the disclosure story is more interesting than the bugs themselves,” said Frank Dickson of Dickson Research. “Embargoes matter. This one was nearly impossible to keep.” The messy disclosure CVE-2026-109618 and CVE-2026-109619 could allow attackers to launch remote code execution (RCE) attacks. The PHP Foundation acknowledged that one of its contractors had discovered the first signs of the out-of-memory (OOM) problem behind CVE-2026-109618 as far back as 2024, but “no concrete vectors” were found, and other issues with “clear impact” overshadowed its concerns about the flaw. Deep research into the problem didn’t occur until July 30, 2026, after the Foundation got the PHP project into OpenAI’s Patch the Planet program. Researchers from Calif, OpenAI, and Google Cloud’s Wiz “made the full impact of the OOM problem clear,” and fixing it became top priority. Once researchers developed patches, distributors, including Chainguard, received them in advance so their users could update “the moment the vulnerabilities were disclosed,” the Foundation said. It set an embargo for October 22 at 14:00 UTC. That coordinated disclosure appeared to work well until two days prior to the embargo lifting, the Foundation explained. On October 20, around 15:00 UTC, the two CVE IDs began circulating online, although no technical details were leaked. The PHP project brought its pre-announcement forward and published it at 19:30 UTC . It also moved the release of fixes from October 22, 14:00 UTC, to October 21, 14:00 UTC. The advancement of the pre-announcement’s timing led cybersecurity company Calif to “mistakenly” publish a video showing a PoC exploit against numerous targets. It also revealed “limited” details about the flaws. The video was subsequently deleted, but it had already begun circulating on social media. Then, on October 21 at 07:41 UTC, Chainguard published built images containing the fix. This was roughly six hours before the agreed-upon release time, and “disregarded weeks of work by many parties toward a coordinated disclosure,” the PHP Foundation alleged. Eighteen hours after the pre-release, on October 21, 14:00 UTC, the PHP project made the patches public. This was 24 hours earlier than originally planned. The Foundation explained that distributors were still packaging the fix, so releasing it sooner would have left many users without an easy way to update. “Moving the release forward by one day was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path when the vulnerabilities were disclosed.” Chainguard CEO Dan Lorenc fired back against the Foundation’s criticism, saying that he followed disclosure process guidelines for releasing after uncovering evidence of active exploits. “This decision was based on how easily we were able to independently discover the vulnerability and build an exploit, how much information was already out there on the coming vulnerabilities and fixes, and the evidence shared on active exploits in the wild,” he wrote in a LinkedIn post . Indeed, Cloudflare CEO Matthew Prince said his company saw “thousands” of attempts to exploit PHP2Shell 10 hours before the public announcement. That jumped to “tens of thousands in the 45 minutes post announcement, hundreds of thousands within two hours, and millions now,” he said. And AWS claims that at least one exploit attempt occurred four days before public disclosure, on October 17. This attempt originated from an IP address associated with a commercial anonymization network, according to AWS CISO CJ Moses, indicating that it was conducted by a threat actor, “though it remains unclear how the actor acquired exploit information prior to disclosure.” Keeping secrets is hard, but it’s still the right model While there seem to have been various leaks, that doesn’t excuse Chainguard, Dickson said. The company received the fix early for a reason, and publishing it early gave attackers a fix to study while every other PHP user waited. “An embargo protects defenders only until someone else finds the same bug,” he said, adding that the longer a fix sits in the queue, the shorter the protection window gets. “Every party that receives the patch early is one more way for the secret to escape.” That said, coordinated disclosure is still the right model; it just needs to run tighter, he said. That means shorter windows, fewer early recipients, and a clear understanding that the fix itself is the secret. “A patch is a treasure map,” he noted. Ultimately, “keeping secrets is hard,” said David Shipley , CEO of Beauceron Security. “The more people that know, the longer the time frame, the more likely something leaks.” That’s a huge problem now, he noted, because with AI agents and a little bit of knowledge of how a flaw works, “you can point a tool at software and figure it out.” Liability in the age of AI The effect of PHP2Shell will be felt for years, just like that of Log4J, said Shipley. After showing up in the largest online presences, it will work its way through to IoT devices and others. Defenders must know their software estate and dependencies; a software bill of materials (SBOM) can help there. “It’s not an easy fix, but it’s the simple grunt work of IT and cyber that can make or break response,” Shipley said. Enterprises also need product maker liability and AI tool provider liability. “The vulnpocylpse isn’t because of AI,” he said. For decades now, market incentives have been to ship it and fix, move fast, and break things. Businesses that have prioritized shipping more slowly but more securely have been pummeled in the market by companies that didn’t and “pushed out new and shiny while building technology and security debt,” Shipley said. Incentives need to change, especially in the era of AI. And, Dickson advised, security teams should understand where every runtime lives, including those from inside vendors. Decide in advance who has the authority to take a service offline, so that call is “made in calm rather than argued in a crisis.” Invest in detections built on behavior, such as unexpected process execution or new files on a web server, because a signature for a specific CVE will not exist on day zero. “Chainguard jumped the gun, but the race had already started,” Dickson said. “Embargoes are still worth keeping. But CISOs should plan for exploitation to begin before the advisory, because it now does.” This article originally appeared on InfoWorld .