Even after PHP2Shell, blast radius matters more than a CVSS score

Here’s a prediction: we’re about to see a stellar quarter for application security companies. PHP2Shell is about to become the strongest budget argument application security vendors have had in years. AI helped researchers find two remote code execution vulnerabilities in the language behind 69% of the web, attackers targeted it before the patch shipped, and the pitch writes itself: find more bugs and fix them faster.

Enterprises should rethink this idea. Security teams cannot patch at machine speed, but they can reduce what an attacker can reach after exploitation by focusing on identity as the control plane.

Beyond the initial exploitation, the ultimate incident severity depends heavily on which service accounts, API keys, cloud roles, and tokens the compromised workload can use and what they can access.

From vulnerability to exploitation

First, we need to understand just how much faster exploitation is now. The two flaws behind PHP2Shell had been in PHP’s code since 2012. Researchers at Calif and Wiz found them in August, with help from OpenAI and Google models, and disclosed them jointly with OpenAI.

Amazon saw an exploitation attempt on October 17, four days before disclosure. PHP shipped the patch on October 21, and watchTowr saw exploitation attempts in the wild the same day. Cloudflare observed attack traffic escalating rapidly after disclosure, and on October 26, CISA added both flaws to its list of known exploited vulnerabilities.

Exploitation now often starts before disclosure. Unfortunately, things aren’t moving as quickly on the remediation side. Verizon’s 2026 DBIR states the median time-to-fix of a known exploited vulnerability is 43 days. According to Qualys, the mean remediation time is 21.2 days, and 63% of critical vulnerabilities are still open after a week. All while around 195 new CVEs are published every day.

PHP2Shell will take longer than most to clean up. PHP ships inside appliances and hosting control panels that customers can’t patch themselves. Moreover, versions 8.1 and older got no official builds.

As of October 27, Censys counted 32.5 million internet-facing PHP services still running potentially vulnerable versions, and more than 60 million others that don’t report a version at all.

However you look at it, remediation speed will remain slower than the pace of exploitation for the foreseeable future, even when patching itself benefits greatly from AI-driven workflows.

Finding isn’t fixing

With the exploitation gap widening, it’s tempting to invest everything you can in holding back the tide. But even if an AI-driven scan found 2,000 new zero-day vulnerabilities in your environment tomorrow, that won’t result in a stronger security posture.

It will give you a list. Some items will be easy to patch, while others will need more time than your team has.

For supported PHP branches, the direct fix was simple: install the updated release. Governments and companies still took their sites offline while they waited for it.

Here’s another, more optimistic way to look at it. Vulnerabilities lead to exploits, and exploits lead to attacks, but in an enterprise context, the impact of an attack is determined by how far the compromised identities can reach. A shell on a PHP server grants the attacker access to whatever that server can read, from environment variables to cloud keys in config files.

PHP2Shell can also leak worker memory, including passwords, tokens, and API keys. An attacker executing code on one host opens a door to a hallway, but the real valuables are usually in locked rooms.

And the controls that limit lateral movement don’t depend on winning a race against discovery. Finding vulnerabilities is an open-ended process, and limiting the reach of a service account is a quantifiable task.

Attackers take the easiest path

This approach has limits. If the vulnerability is in the IdP or the secrets manager, lateral movement capabilities come built in. If it’s in the database or in the storage provider, the attacker is already where they want to be.

So with limited resources, it’s tempting to stay vulnerability-first: catalog what the advisories and scanners found, triage it, work down from the top. But cataloging takes weeks, and fixing the most pressing findings takes even longer. The bet here is that the most exploitable holes in your core systems are the ones you’ll close first.

That bet prioritizes the vulnerability’s severity (the CVSS score) over the blast radius. Attackers aren’t looking for the most direct path; they’re looking for the easiest path. Taking a leaked credential and moving with it is easier than stringing together zero-days to reach a database directly.

October’s other headlines show that path. At LiteLLM, attackers used a master key exposed in a public repository to retrieve an unscoped GitHub organization-owner token from an internal agent platform. That identity let them steal two more maintainer tokens, subvert the release workflow, and publish credential-stealing artifacts.

Shrink the blast radius first

You can’t win the race to patch every server before the attackers arrive, but you can determine what a compromised server is worth to them. Discover and inventory every AI agent and non-human identity and start by securing the ones that reach the most.

Assign an owner, scope access to purpose and intent, remove dormant credentials, and continuously govern the identity lifecycle. For AI agents, go further and grant access by intent. That is what it means to treat identity as the control plane.

Patching decides how fast you close a hole. Identity decides how much an attacker gets when you can’t.

To see more from Token Security, book a technical demo with our team.

Sponsored and written by Token Security.