Blog
Research
Navigating PHP2Shell: From Broad Exposure to Critical Action
The average Fortune 500 company has 2,266 assets running PHP vulnerable to PHP2Shell. Only 16 of them need to be fixed first.
5 min read
The average Fortune 500 company has 2,266 assets with a PHP version affected by PHP2Shell. By 5 p.m. Pacific today, fewer than 1% of them had been patched.
PHP2Shell refers to two critical vulnerabilities in the PHP engine (CVE-2026-109618 and CVE-2026-109619), which were disclosed today along with patched releases for every supported branch. Both carry a CVSS v4.0 score of 9.2 and can lead to unauthenticated remote code execution. Because the flaws are in PHP itself, an application built on PHP can be vulnerable even if its own code has no flaws.
Cogent Research analyzed the environments of dozens of Fortune 500 companies on the day of disclosure, focusing on servers and virtual machines. For each affected asset, we looked at whether PHP was running, whether the asset could be reached from the internet, and the asset's business criticality.
The Two Questions Every Security Team Has to Answer
When PHP2Shell was disclosed, every enterprise security team needed answers to the same two questions: Where are we exposed to the vulnerable PHP versions, and what should we fix first?
The first question takes time to answer because PHP often runs in places that aren't closely tracked, such as base images, internal admin tools, and servers left over from retired web applications. Vulnerability scanners will identify these installations, but only after they release detections for the new CVEs. In our earlier research, that lag averaged up to 5.1 days.
The second question is even more challenging for many security teams today. A scanner would score all 2,266 assets the same, and without more context, a team has no way to tell which ones to patch first.
How We Narrowed the Average Enterprise's 2,266 Affected Assets to 16
Cogent Research went deeper on these assets, peeling back three layers of context to identify which ones are urgent to fix. The highest-priority assets meet every condition: they run an affected PHP version, load it at runtime, are exposed to the internet, and are business critical.
PHP loaded at runtime: PHP is installed and observed executing. 926 of the 2,266 affected assets (41%) met this condition. Installations that aren't running still need to be addressed, but they aren't processing the web requests that trigger this attack.
Exposed to the internet: The asset accepts traffic from the internet, as confirmed by external scans. This includes assets behind load balancers and WAFs. 122 of the 926 runtime assets (13%) met this condition.
High or critical business impact: The asset supports a system the business depends on. Cogent's AI agents continuously classify the business criticality of every asset in the environment. 16 of the 122 internet-exposed assets met this condition.
Security teams should patch those 16 assets first. Each one can be reached from the internet with a single unauthenticated request, and a compromise of any of them could disrupt a system the business depends on or expose sensitive data.
The remaining assets still need attention. The 106 internet-exposed assets with lower business impact should be patched next, because attackers can reach them the same way. The 804 assets running PHP on internal networks follow. The 1,340 assets where PHP is installed but not running can follow the normal patch cycle, and in many cases PHP can be removed from them entirely.
71% of Internet-Exposed Assets Have No WAF
A WAF rule is the fastest stopgap for an internet-facing server that can't be patched today, but most exposed assets in our data don't have a WAF in front of them. Only 29% of the average enterprise's 122 internet-exposed assets sit behind one, which leaves the other 71% with nothing to stop an exploit attempt from reaching the vulnerable server.
Those 71% should be prioritized for patching. For the 29% behind a WAF, a rule targeting PHP2Shell can block known exploit attempts while the team prepares and tests the patch. The PHP project is clear, however, that only an update fully fixes these vulnerabilities, and that interim measures reduce exposure without making an installation safe.
53% of Affected Assets Run End-of-Life PHP
More than half of affected assets (53%) run end-of-life PHP versions, which the PHP project no longer updates. That includes PHP 8.1 and older. Because of PHP2Shell's severity, the PHP security team published minimal source backports for 7.4, 8.0, and 8.1, and some Linux distributions and long-term support vendors offer backported fixes. Assets on other end-of-life versions will need to migrate to a supported branch, which requires more application testing than a routine patch.
PHP 8.2 received a patch today, but it reaches end of life on December 31 and will not receive security fixes after that date. Teams planning a migration should move to PHP 8.3 or later.
AI Makes PHP2Shell Easier to Exploit at Scale
Two weeks ago, Cogent Research published our Q4 2026 Threat Report, which found that the effort required to exploit the deepest attack paths kept them safe from human attackers for years, and that AI agents are removing that barrier. PHP2Shell follows the same pattern. The memory-safety bugs behind it sat in the PHP codebase for more than a decade before researchers found them with the help of frontier AI models.
Attackers have access to the same capabilities. AI agents will likely build a working PHP2Shell exploit soon and chain it with other weaknesses in the environment, such as exposed credentials or misconfigured permissions, to reach systems deeper in the network. That reduces the time security teams have to address the 106 lower-impact exposed assets and the 804 internal ones.
What Security Teams Should Do Now
Patch the highest-risk, exploitable, internet-exposed assets first. Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install the equivalent package from your distribution.
Apply interim mitigations to exposed assets you can't patch today. The PHP project recommends setting session.upload_progress.enabled=0 in php.ini or the FPM pool configuration, setting memory_limit=-1 where applications can't override it (such as through php_admin_value), and lowering post_max_size to 8M for applications without uploads, or 32M for those with them. Restart every worker afterward. None of these measures fully closes the vulnerability.
Put a WAF rule in front of exposed assets that lack one, and use it as a temporary measure until the patch is applied.
Start end-of-life migrations now. Begin with internet-exposed assets, check whether your distribution or LTS vendor has shipped a backport, and target PHP 8.3 or later.
Remove PHP where it isn't running. The 1,340 dormant installations in the average environment add risk without serving any business purpose.
How Cogent Customers Got This Analysis Within Minutes
Cogent customers had this analysis within minutes of the advisory's release this morning. Cogent Zero Day Response processed the PHP2Shell advisory and mapped vulnerable assets across customer environments in an average of five minutes, days ahead of scanner signatures. It works by matching new vulnerabilities against a software inventory that Cogent continuously updates for each organization. Runtime status came from the EDR and security telemetry customers already run, so there was no new agent to deploy. External scans confirmed which assets were reachable from the internet, and Cogent's AI agents had already mapped the business criticality of every asset. When security teams began working on PHP2Shell, their list of highest-priority assets was already waiting in Cogent.
As AI helps attackers build and adapt exploits at m
