PHP2Shell: Multiparty Disclosure, Same As It Ever Was
Last week felt like a century made of "daycades," with each day like living a full decade. From the US government's ban on DeepSeek in federal civilian agencies, to a certificate authority with a private key of 4, to the PHP vulnerabilities, it seemed like the flood was never going to end.
I struggled to focus long enough to get this blog out, and kept hearing echoes of multiparty disclosures past, starting with the first one, Dan Kaminsky's DNS bug. This bug was the first to attempt a multiparty vulnerability disclosure of that scale, and marked the official start of Microsoft Vulnerability Research, which I created to formalize Microsoft's roles in disclosure, not just as a vendor receiving bug reports, but also as finder and coordinator.
Panic! at the Multiparty Disco
In 2008, the late, great Dan Kaminsky asked me to help gather the people needed to coordinate his DNS bug. I distinctly recall him telling me that when he told Paul Vixie about it, Paul went quiet on the phone, then said, "I need you to never tell anyone about this on an unencrypted phone line again."
Dan even begged fellow researchers not to speculate publicly until people had time to apply the patches. The patches did not immediately point to the vulnerability, as many patches do, but fixed it in a way that would take some skill to figure out. Even then, 13 days after the patches shipped, Matasano accidentally published a blog post that broke the embargo.
Last week's PHP2Shell bugs and disclosure had the same familiar ingredients but with AI sprinkles on top. The bugs can let an unauthenticated attacker execute code on servers running PHP. If you run PHP, update now. The PHP Foundation published a candid account of what went wrong. That candor deserves praise, and so does the work: PHP's security team and release managers fixed deep engine flaws across every supported branch, after researchers at Calif, OpenAI, and Wiz found the flaws and proved they were exploitable.
Embargo to Hell
Calif, under OpenAI's Patch the Planet program, reported the first bug on August 11, and Wiz followed on August 24. OpenAI independently reported the same root cause and sent more attack vectors on September 18. Every finder becomes another party to an embargo that can't include everyone, and each one raises the odds of a leak.
The research community is no longer small enough to politely ask for silence, as Kaminsky did. Chainguard CEO Dan Lorenc told The Register that after one of the researchers mentioned a PHP bug was coming, his team found the same bugs that night with a frontier model. A hint is a disclosure in skilled hands.
PHP2Shell's CVE IDs leaked on October 20. PHP pre-announced and moved the release up a day while distributors were still packaging. Half an hour later, Calif mistakenly posted a proof of concept video.
At 07:41 UTC on October 21, more than six hours before the planned coordinated release, Chainguard published container images with the fix built in, using the patch it had received under embargo as a distributor. Lorenc said he made the call to ship early "when exploits hit in the wild," and he described Chainguard's approach as "coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild." He stood by the decision and later apologized for the added stress on PHP's maintainers. The PHP Foundation publicly disagreed, calling it a unilateral break of the embargo, and said its team had found no functional public exploit.
Potato, Oh-Day-Oh
Coordinated Vulnerability Disclosure between one finder and one vendor gets complicated enough. The complexity grows by orders of magnitude with each party added, and embargoes usually break over disagreements among reasonable people about the best way to protect users.
On paper, PHP's and Chainguard's triggers matched. PHP's pre-announcement reserved the right to release early if details went public or evidence of active exploitation appeared. Chainguard follows their own disclosure policy that allows shorter timelines when a bug is under active exploitation. Where Chainguard and PHP differed was on what counted as evidence of exploitation and who got to decide. Google and Microsoft have famously tussled over disclosure timing, too.
Mainstream Moves
Then the story did what Heartbleed did in 2014, when that bug got its own website and logo and my non-technical family members started asking me about it. PHP2Shell got a logo too, and it made major news. Governments from Australia to the UK took websites offline, some before the patch even shipped, and some posted dramatic banners instructing people who use PHP to upgrade. Only website and server admins could act on that advice.
I talked about it live on BBC World News.
The media hype got more admins patching then and now, but taking systems offline isn't sustainable as AI surfaces more exploitable bugs.
Fixing Ain't Easy
Like Dan's DNS bug, PHP2Shell's root cause was known years before it was fixed. Daniel J. Bernstein's djbdns introduced source port randomization in 1999, the same defense the 2008 DNS patches relied on. Similarly, PHP's out-of-memory problem surfaced in 2024, after a Quarkslab audit.
Old bugs stay unpatched because fixing them forces tradeoffs that take human judgment to resolve. Every candidate PHP fix had a price: broken backward compatibility, new denial of service risk, or changes to many third-party extensions. That much coordination effort across the PHP extension ecosystem wasn't justified until expert researchers found a way to exploit the flaw, which they did this year with AI's help.
Finder, Coordinator, Vendor
In 2010, I published Microsoft's first formal Coordinated Vulnerability Disclosure policy, establishing how Microsoft would act as finder, coordinator, or vendor receiving bug reports.
Frontier AI labs, among others, now hold all three roles at once. The roles are deceptively simple to describe and infinitely complex to build processes around.
OpenAI was a finder and, by its own account, "led a coalition of maintainers, researchers, and security providers." The labs have taken on a staggering amount of coordinated disclosure, more than any single organization's in-house teams can carry. As of October 2, Anthropic's dashboard showed 6,157 vulnerabilities reported across 591 open source projects, with 516 patched and human review as the bottleneck.
Even if the labs staffed up, the open source world can't keep pace with them, and shouldn't be expected to without resources or adequate funding for full-time maintainers. Across the interdependent Internet, infrastructure operators can't keep up with testing and deploying all these updates either.
Disclosure Can Build or Destroy Trust
We can't keep relying on the same assumptions, processes, and timelines as we did before AI entered the chat, but we don't need to reinvent the wheel just because AI is pushing the cart faster. AI won't automate trust between parties any time soon.
Some tips to build multiparty vulnerability coordination muscle:
Define your multiparty vulnerability coordination playbook and disclosure triggers.
Share them at the start of every Coordinated Vulnerability Disclosure embargo you run or join.
Work out what happens if one party's public disclosure trigger is met before the other parties' triggers are.
Decide how you will communicate if there is a disagreement. Drama doesn't help defenders.
Over time, there is a way to develop functional partnerships to reduce friction and surprises. Your process should enable multiparty Coordinated Vulnerability Disclosure with organizations of varying sizes and capabilities, and even with competitors, to do the right thing to protect users. Coordinated means working together, even when not all parties agree.
Coordinating Vulnerability Disclosure Is Like Practicing Yoga
You must meet the moment with each bug, stretching into some familiar and some uncomfortable positions, depending on what you are capable of that day.
Multiparty Coordinated Vulnerability Disclosure can be complex by definition, with a ton of moving parts. With AI-assisted finders auditing the same foundational code, expect many more of these multiparty disclosures. As with all efforts, stay hydrated, and do your best to avoid injuring yourself or others.
Luta Security has been helping organizations and governments build internal capacity for handling first-party bugs, as well as supporting them when they step into the other roles in disclosure.
If your organization needs help managing their Coordinated Vulnerability Disclosure program, multiparty or otherwise, you can always reach us at info@lutasecurity.com.
Comments