Two remote code execution flaws discovered in PHP—which powers 69% of the web—are poised to reshape how enterprises think about vulnerability management. AI-assisted research uncovered these bugs, which had lurked in PHP's codebase since 2012, and attackers began exploiting them before patches arrived. Yet the real lesson isn't about finding more vulnerabilities faster; it's about limiting the damage when exploitation inevitably succeeds.
Security teams face a hard truth: they cannot patch at the speed attackers exploit. The median time to fix a known exploited vulnerability stands at 43 days, according to Verizon's 2026 Data Breach Investigations Report, while Qualys data shows the mean remediation time is 21.2 days and 63% of critical vulnerabilities remain unpatched after a week. Meanwhile, roughly 195 new CVEs publish daily. The only viable defense is to reduce what an attacker can reach after breaking in by treating identity as the control plane.
From vulnerability to exploitation
The timeline of PHP2Shell illustrates how quickly the exploitation window has compressed. Researchers at Calif and Wiz, working with OpenAI and Google models, identified the two flaws in August. Amazon detected an exploitation attempt on October 17—four days before public disclosure. PHP released patches on October 21, and watchTowr observed active exploitation that same day. Cloudflare reported attack traffic surging after disclosure, and on October 26, CISA listed both vulnerabilities among known exploited flaws.
The PHP2Shell case presents particular remediation challenges. PHP often ships embedded in appliances and hosting control panels that customers cannot patch independently. Versions 8.1 and earlier received no official builds. As of October 27, Censys identified 32.5 million internet-facing PHP services still operating on potentially vulnerable versions, with more than 60 million additional services not reporting version information at all.
Finding isn't fixing
Even if AI-powered scanning discovered 2,000 new zero-day vulnerabilities in an organization tomorrow, the result would be a list, not improved security. Some items would patch easily; others would demand more time than teams possess. For supported PHP branches, the direct remediation was straightforward—install the updated release—yet governments and companies still took systems offline during the process.
A different perspective emerges when considering the attack chain beyond initial compromise. Vulnerabilities enable exploits, and exploits enable attacks, but in enterprise environments, attack impact depends on how far compromised identities can travel. Code execution on a PHP server grants attackers access to whatever that server can read: environment variables, cloud keys in configuration files, and worker memory containing passwords, tokens, and API keys. The attacker gains entry to a hallway, but the valuable assets typically sit behind locked doors.
Controlling lateral movement doesn't require winning a speed contest against vulnerability discovery. Finding flaws is an endless process; limiting what a service account can reach is a measurable objective.
Attackers take the easiest path
This strategy has boundaries. If the vulnerability exists in the identity provider or secrets manager, lateral movement capabilities come pre-built. If it affects the database or storage provider, the attacker has already reached their target. With constrained resources, the vulnerability-first approach remains tempting: document findings from advisories and scanners, prioritize by severity, work downward. Yet cataloging takes weeks, and fixing the most critical items takes longer still. This approach bets that the most exploitable gaps in core systems will close first—prioritizing CVSS scores over blast radius.
Attackers pursue the easiest path, not the most direct one. Using a leaked credential to move laterally proves simpler than chaining zero-days to reach a database directly. October's LiteLLM incident demonstrated this pattern: attackers leveraged a master key exposed in a public repository to retrieve an unscoped GitHub organization-owner token from an internal agent platform. That identity enabled them to steal two additional maintainer tokens, compromise the release workflow, and distribute credential-stealing artifacts.
Shrink the blast radius first
Organizations cannot outpace attackers in patching every server before compromise occurs, but they can control what a compromised server means to an attacker. The path forward involves discovering and cataloging every AI agent and non-human identity, then securing those with the broadest reach first.
Assign ownership to each identity, restrict access to specific purposes and intents, eliminate dormant credentials, and maintain continuous governance of the identity lifecycle. For AI agents, extend this further by granting access based on intent. This constitutes treating identity as the control plane.
Patching determines how quickly a hole closes. Identity determines how much an attacker gains when closure cannot happen fast enough.