PHP2Shell highlights a widening gap between vulnerability exploitation and remediation. Researchers used AI to help identify two remote code execution flaws in PHP, while attackers reportedly began targeting them before the official patch was released. Although application security vendors may use the incident to argue for faster discovery and patching, organizations cannot update every system at machine speed. A stronger defense is to limit what a compromised workload can reach by treating identity—including service accounts, API keys, cloud roles, and tokens—as a central security control.
From vulnerability discovery to exploitation
PHP2Shell involves two PHP flaws. PHP is used across 69% of the web, according to W3Techs. Researchers at Calif and Wiz discovered the vulnerabilities in August with help from OpenAI and Google models, and published their findings in collaboration with OpenAI. The flaws affect PHP code that has been in use since 2012, according to Sansec.
The timeline shows how quickly exploitation can follow discovery. Amazon reported an exploitation attempt on October 17, four days before the public release. PHP shipped a patch on October 21. watchTowr observed an exploit attempt in the wild that same day.
After the vulnerabilities were published, Cloudflare observed a rapid increase in attack traffic. On October 26, CISA added both flaws to its Known Exploited Vulnerabilities catalog.
Exploitation is increasingly beginning before vulnerabilities are publicly disclosed, but remediation is not keeping pace. Verizon’s 2026 Data Breach Investigations Report puts the median time to fix known exploited vulnerabilities at 43 days. Qualys reports an average remediation time of 21.2 days, with 63% of critical vulnerabilities still unresolved after one week. During that period, approximately 195 new CVEs are published each day.
PHP2Shell may take longer to remediate than some other vulnerabilities because PHP is embedded in appliances and hosting control panels that customers may not be able to patch themselves. In addition, there was no official build available before version 8.1.
As of October 27, Censys counted 32.5 million internet-facing PHP services still running potentially vulnerable versions. More than 60 million other services were not reporting their versions, making their exposure difficult to determine.
Even if AI-assisted workflows make patching more efficient, remediation is likely to remain slower than exploitation for some time.
Why vulnerability discovery is not enough
As the exploitation gap widens, organizations may be tempted to invest all their resources in finding more flaws. However, discovering 2,000 new zero-day vulnerabilities in an environment would not, by itself, improve its security posture. It would produce a list of issues, some easy to fix and others requiring more time than a security team has available.
For supported PHP branches, the direct fix is straightforward: install the updated release. Some governments and businesses took their sites offline while waiting for a fix.
A more useful way to assess risk is to look beyond the vulnerability itself. Vulnerabilities can lead to exploits, and exploits can lead to attacks, but the impact of an attack in an enterprise depends largely on how far the compromised identity can reach.
A shell on a PHP server may give an attacker access to everything the server can read, including environment variables and cloud keys stored in configuration files. PHP2Shell may also expose worker memory containing passwords, tokens, and API keys. Code execution on one host opens the door to the surrounding network, but the most valuable systems may still be protected if the compromised workload has limited permissions.
Unlike vulnerability discovery, which is open-ended, limiting service-account permissions is a measurable task. Restricting identities and credentials can reduce lateral movement even when an organization cannot patch every vulnerable system immediately.
Attackers choose the easiest path
Identity-based controls have limits. If a vulnerability affects an identity provider or secret manager, an attacker may gain built-in lateral-movement capabilities. If the target is a database or storage provider, the attacker may already have reached the desired destination.
When resources are limited, organizations may therefore prioritize vulnerabilities first. Security teams catalog and triage findings from advisories and scanners, working from the highest-priority issues downward. However, cataloging can take weeks, and addressing the most urgent findings can take even longer.
This approach often favors vulnerability severity, such as a CVSS score, over potential blast radius. Attackers are not necessarily seeking the most direct route. They are looking for the easiest one. Finding exposed credentials and using them may be simpler than developing a zero-day exploit and gaining direct access to a database.
An October incident involving LiteLLM illustrates the risk. According to the company’s account of the attack chain, an attacker used a master key exposed in a public repository to obtain an out-of-scope GitHub organization owner token from an internal agent platform. That identity enabled the attacker to publish artifacts that stole two additional maintainer tokens, subverted release workflows, and obtained credentials.
Reduce the blast radius first
Organizations cannot reliably patch every server before an attacker arrives, but they can determine how valuable a compromised server would be. The first step is to identify and inventory AI agents and other non-human identities, then establish who owns them and what resources they can access.
Access should be limited to specific purposes and intended actions. Dormant credentials should be removed, and identity permissions should be reviewed throughout their lifecycle. For AI agents, organizations can go further by granting access based on the agent’s intent and approved tasks.
This is the principle of treating identity as a control plane. Patching determines how quickly a vulnerability is closed; identity controls determine how much an attacker can gain if a vulnerable system is compromised.
The agent now operates system-wide with permissions that no one has reviewed.
Token Security’s AI Agent Security is designed to find agents, link them to their owners, and limit what they can do through identity-based controls.
To learn more about Token Security, book a technology demonstration with its team.
Sponsored and written by Token Security.
Source: www.bleepingcomputer.com