The week of October 20th was unusually chaotic, even without the PHP news. Not only did teams need to scramble to identify and understand the impact of emergency PHP vulnerabilities, but there were also critical vulnerabilities in node.js, cryptographically weak keys issues by a certificate authority, exploited vulns in network security equipment, and potentially accidental distribution of even more zero days from a security vendor. The PHP mayhem arrived under unusual circumstances: the vulnerabilities were made public before coordinated disclosure completed, patches were not ready, and mitigations were still underway.  Given that PHP is omnipresent in every environment (leaving many to compare the event to Log4Shell), researchers, social media, government agencies, and vendors all had their own perspective on the significance of the threat.

Two weeks later, the PHP2Shell vulnerabilities are the least interesting thing that happened that week.

The week of October 20th demonstrated what happens when AI led vulnerability discovery, attempts to use AI to write exploits, and uncoordinated vulnerability disclosure converged. We think these three things will continue to happen independently while converging to make each scenario worse. Here’s what it means for you.

Any “Non-Event” Means That Defenders Won

WAF vendors including Cloudflare and Akamai had to expedite protections due to the breach in coordinated disclosure, but this gave customers a preventative measure while they waited to patch. Other organizations took aggressive steps of temporarily shutting down websites, including government sites and the Netherlands and Finland. Estimates of the number of sites taken down proactively range from hundreds to thousands.

We are now seeing security take precedence over availability. Over the past few months, we’ve had several conversations with security leaders on whether it was time to change risk appetites for availability vs security which at that time were limited to updates, questions, and decisions that security and business/technology leadership had to discuss with their organizations. We’re seeing those conversations evolve into actions.

As of this writing, we still haven’t heard of a successful breach leveraging these vulnerabilities. It’s likely that mitigations disrupted or prevented breaches, but until or if there is a breach leveraging these vulns, it will be difficult to determine how successful and necessary all of these mitigations were. The absence of a known breach is evidence that defenses worked, despite thoughts that organizations overreacted.

Hindsight is always 20/20. Organizations that decided to take down sites were acting on incomplete information. Incomplete information made worse by a breach in the coordinated disclosure process. Was PHP2Shell as bad as some of the predictions? No. Was it a nothing burger? Probably not. Did swift, decisive coordinated action play a role in keeping the worst predictions from coming to pass? Likely.

AI Discovered The PHP Vulnerabilities…But Clarity On Its Impact Might As Well Have Been Coming From The Muppet’s Swedish Chef

The first day of the PHP2Shell announcement left security teams parsing through competing threat analysis and mitigation guidance. Some initial proposed mitigations provided incomplete protection. PHP warned that configuration recommendations could reduce exposure, but it didn’t make installation safe.

Meanwhile, teams had to deal with discovering multiple PHP branches, unsupported installations, two separate CVEs, and reports of probing and exploitation from their SOC and different online sources. Whether the vulnerabilities could be reliably exploited remained difficult to establish. Some security companies said they had working exploits, but AI generated exploits published online didn’t work. This left many SOC teams triaging nonfunctional exploits. Eventually one pen tester put his own bitcoin up for grabs on a site running vulnerable PHP to prove whether an exploit was possible.

Many organizations rely on Known Exploited Vulnerability (KEV) catalogues, especially the one maintained by CISA (which didn’t publish the CVEs on their KEV until Monday Oct 26), but these can no longer serve as the only trigger to kick off emergency remediations. The barrier to exploit is shrinking along with the barrier to discover vulnerabilities, and as AI models mature, knowing whether a vuln is a KEV will matter less. AI will continue to write bad exploits, and they will continue to proliferate online. A published POC alone does not constitute expediting remediation. Teams need to prioritize based on reachability and exploitability in their specific environment.

As more researchers trust AI to generate exploits and don’t fully validate them, we are likely to see more incomplete exploits. This will muddy the waters on what’s possible, add misinformation in an already chaotic period, and (most dangerously) make some doubt the severity of the incident. On Monday morning after the incident, it was still unclear where proven exploits existed, and we started to hear security pros wondering if this entire thing had been overblown. It hadn’t.

(Un)Coordinated Disclosure: Kermit vs. Miss Piggy

Coordinated vulnerability disclosure is like the Muppets putting on a perfect show. Every puppet has a specific role: developing mitigations, writing and testing patches, coordinating communications, and working toward publication of a CVE. Not every disclosure has a Kermit trying to hold the production together and protect the broader community. Some have Miss Piggy who wants to make the show about themselves.

Vulnerability disclosure shouldn’t be an object lesson in game theory. Even if it were, the strategy would be clear: Cooperation produces the best outcome for most participants. Unlike the prisoner’s dilemma, coordinated disclosure doesn’t even impose artificial constraints, such as preventing the participants from communicating. Researchers, maintainers, and security vendors can coordinate. They just need to honor that process.

PHP2Shell began with a failure to do so. When Chainguard made the two CVEs public and the news reached Hacker News on October 20, the PHP team was still finalizing patches. The early announcement forced PHP to accelerate its release and security vendors to hastily deploy mitigations. Everyone else had to recalculate their response on an abbreviated timeline.

When a company is trusted with embargoed information about widespread, novel, and potentially catastrophic vulnerabilities, breaking that trust leaves the rest of the security community cleaning up afterward. Chainguard said that it acted because it was aware of exploit attempts and wanted to protect defenders. It remains unclear whether the company was responding to credible evidence of working exploits or to the wider information chaos surrounding PHP2Shell. Whatever the intent, the result hurt defenders, damaged trust in the disclosure process, and demonstrated that reputation is a critical part of responsible disclosure.

We will say this with zero ambiguity: The responsible disclosure process exists for a reason. Coordinated disclosure is critical when the potential stakes are as high as they were with the PHP vulnerabilities. The security community has thrived because of collaboration and trust between researchers and software providers. Breaking that trust has consequences: negligible upside for customers, deserved reputational damage for the organization that jumps the gun, and less time for everyone else to protect vulnerable systems.

PHP2Shell wasn’t the only recent example of irregular disclosure. Late on October 21 or early on October 22, TrendAI’s Zero Day Initiative inadvertently sent information about unpatched Linux kernel vulnerabilities to public kernel mailing lists, rather than private vulnerability disclosure processes. The circumstances differed from those surrounding PHP2Shell. It’s not clear whether emailing the public distribution list was intentional, since the project has stated that sending AI discovered vulnerabilities to a private list is a waste of time and that AI discovered bugs should not be defined as secret. But the operational effect was familiar: Defenders faced newly disclosed vulnerabilities; no available patches, substantial uncertainty, and another remediation effort layered onto the work already in progress. The faster disclosure moves and the more vulnerabilities the process must handle, the more opportunities there are for consequential mistakes.

That pressure will increase as AI changes vulnerability research. Open source and commercial maintainers are already receiving lengthy AI-generated bug reports, many of which are insignificant, incomplete, or wrong. The burden created by accelerated vulnerability discovery therefore begins before coordinated disclosure. Maintainers need to separate credible findings from noise, determine which reports deserve investigation, and identify which vulnerabilities require confidential coordination and remediation.

For that reason, PHP2Shell marks a turning point in responsible disclosure in the AI age. AI will increase the volume of vulnerability reports and compress the time available to evaluate them. It will also make it harder to distinguish a credible exploit from an incomplete proof of concept. Responsible disclosure matters more than ever because AI is forcing the security community to more hastily decide which reports deserve triage, which vulnerabilities require coordinated remediation, and when releasing exploit details would put defenders at an immediate disadvantage.

Some of us remember the days before responsible disclosure. Even with a much smaller internet footprint than today, it was the Wild West. Some researchers notified vendors; others didn’t. Vendors were often caught unaware, while researchers trying to do the right thing sometimes faced threats of legal action. We cannot go back to that model. Setting the precedent that any researcher or company can unilaterally bypass coordinated disclosure is dangerous and damages trust across the security community. If an individual or organization believes a disclosure process is failing, it should escalate those concerns through the established channels, not appoint itself the exception

The Show Must Go On, But Animal is Waiting Backstage

PHP2Shell will be remembered as three things: 1: A near miss. 2: A well defended critical vulnerability. 3: a failure in responsible vulnerability disclosure. It will also get lost in the noise of more critical CVEs and a busy landscape every team is now seeing as a reality. We learned that the response does not always match the severity of the bug or the presence, or lack thereof, an exploit. It further cements the need for orgs to know what is true, know how they are exposed, and know the options for immediate defense. To prepare for the next emergency, you must:

  • Understanding the current strain of the vulnerability disclosure process. Recognize that AI will increase both vulnerability discovery and exploit discovery. Some will be valid, some won’t. Both scenarios will consume research and maintainer attention, complicate triage and disclosure and compress time for responsible disclosure and response.
  • Define your sources of truth before the next emergency. Establish how you weigh CISA KEV’s catalog, other vulnerability intelligence sources, maintainer guidance, attributes that make exploit evidence valid, and your own telemetry sources. Decide in advance what constitutes credible evidence and criteria for an emergency.
  • Treat mitigations as measurable risk reduction. WAFs and compensating controls should factor into vulnerability priority when they demonstrate reduced exposure or block viable attack paths. Track their deployment and effectiveness alongside patching SLAs and other emergency response metrics.
  • Invest in visibility before you wish you had it. SCA and SBOMs identify where vulnerable software exists. EASM determines where they may be exposed to the internet. Threat intelligence and your own SOC telemetry determine when an exposure requires emergency action.

 

Forrester clients can schedule a guidance session with any of us to discuss their vulnerability management, application security, or proactive security programs. Forrester clients can also access our PHP2Shell board report update template.

Share