Lessons from PHP2Shell: Why waiting for confirmed exploitation is no longer an option

PHP2Shell is a pair of critical remote code execution flaws in the PHP runtime, found with the help of frontier AI models and patched on October 21. PHP powers roughly 70% of websites whose server-side language is known, making a vulnerability in such a widely used component particularly significant.

The vulnerability was reported and the details were kept under embargo until the release of the fix, which was set at two whole months after the discovery. Towards the fag end of the embargo, details of the vulnerability were leaked. But the exploit attempts began a few days before the leak itself.

This raises the question: in today’s threat landscape, where AI is being used to discover vulnerabilities and build exploits, does this model of disclosure still work?

Coordinated disclosure remains the most practical model we have today. It gives maintainers time to investigate a vulnerability and develop a fix without immediately exposing the details to potential attackers. Without coordination, more vulnerabilities could become zero-days before organizations have an opportunity to respond.

However, this process has room to be streamlined. A more consistent disclosure framework, with clearly defined timelines for acknowledging reports, validating findings, and releasing fixes, plus an agreed protocol for what happens when details leak early could reduce avoidable delays in releasing the fix.

But delays don’t end when a patch becomes available. Organizations must still decide how quickly to deploy it, and that decision often depends on whether the threat feels immediate.

Within days of disclosure, CISA confirmed that attackers were exploiting the flaws in the wild, and urgency followed. This is a common pattern: organizations tend to accelerate remediation when a vulnerability makes headlines. Other vulnerabilities, even those listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, can take much longer to address. This is a problematic pattern. Waiting for confirmed exploitation was acceptable when attackers themselves needed weeks to exploit. Today, that isn’t the case, so delaying a patch is almost like inviting the attacker to go first.

The open-source dependency challenge

One of the challenges with vulnerabilities such as PHP2Shell is that organizations may not have complete visibility into every instance of a vulnerable component across their environments. This is because PHP can also run as a portable application with no formal installation, so conventional scans may not find it.

Software bills of materials (SBOMs) and software composition analysis (SCA) can help address the visibility gap. An SBOM provides an inventory of software components, while SCA helps identify and assess those components for vulnerabilities.

Once they gain the visibility, an organization can patch the PHP components it uses internally and manage directly. But what about third-party products that also depend on the vulnerable component? Those fixes depend on the respective vendors incorporating the patch and releasing updates.

This leaves organizations dealing with a problem they cannot always resolve independently. Although a patch exists, the fix they need may not yet be available from their vendor.

What organizations should learn from PHP2Shell

One of the underlying bugs was noticed in a 2024 audit but went unfixed, as no working exploit existed and the fix stalled. Flaws once ranked “not exploitable” can become exploitable quickly thanks to AI, so prioritization can’t rest on what attackers can do today.

Don’t wait for confirmed exploitation to patch

As frontier models become more capable and open-weight models make advanced capabilities more accessible, the effort and cost of developing exploits are falling. Defenders have less room to rely on lengthy remediation windows.

Start with the backlog of flaws marked “no known exploit.” Prioritize those that are internet-facing, need no authentication, and sit in widely deployed components, since these are the ones AI is most likely to turn into working exploits.

Patch as quickly as possible. Automation can help organizations move toward faster, risk-based patching by factoring in vulnerability severity, asset criticality, and exposure when prioritizing remediation. It can also streamline deployment through staged rollouts, allowing teams to validate patches before wider deployment.

Organizations must also account for production dependencies and extend vulnerability management to bundled components and third-party software.

Make attack surface reduction a continuous practice

Reduce reachable systems, restrict unnecessary access, and limit lateral movement. A smaller, better-controlled attack surface reduces exploitation opportunities and gives organizations more time to respond when vulnerabilities emerge.

Use AI to find weaknesses before attackers do

PHP2Shell was discovered using frontier AI models. Organizations can use AI-assisted security assessments to identify weaknesses in their own applications, infrastructure, and dependencies. While these assessments may not uncover flaws buried in underlying components, they can reveal exposure within an organization’s environment.

The takeaway

The PHP2Shell vulnerability drew attention because of PHP’s ubiquitous presence across the web. But the next vulnerability could emerge in any component, application, or dependency. Organizations can’t afford to wait for vulnerabilities to be discovered, patches to be released, and threats to become widespread before taking action. Diligently following basic cyber hygiene practices—from reducing attack surface and maintaining visibility into software dependencies to prioritizing patches—can help organizations limit their exposure when the next vulnerability emerges. And if the pace of AI-assisted vulnerability discovery is any indication, incidents like this are only going to become more frequent.