On October 21, PHP's maintainers shipped urgent fixes for two critical flaws, known together as PHP2Shell. PHP runs the code behind roughly 70% of websites whose underlying technology can be identified. Because the flaws sit in PHP itself, a website whose own code is sound can still be exposed. According to Wiz Research, one of the teams that found them, an attacker can take control of a server, or read passwords and access keys from its memory, without logging in. PHP is also built into products that many organizations don't realize contain it. Palo Alto Networks, for example, says that every version of its firewall software is affected and that it has no fix yet.
Attack attempts surged within hours of the announcement and now run into the millions. Two days on, security firms such as Cisco Talos still describe mostly scanning and scattered attempts, with no confirmed break-ins. As of October 22, CISA had not added either flaw to its Known Exploited Vulnerabilities Catalog. So far, the visible damage has come from caution: government, school and hospital websites have gone offline across Asia, Europe and North America. The UK government alone told Parliament that 32 of its services were unavailable.
Past events offer a yardstick. In 2023, the Cl0p ransomware group used a previously unknown flaw in MOVEit, a file-transfer product, to hit 2,773 organizations and nearly 96 million people. MOVEit was not a single point of failure: no provider went down or pushed out a bad update, and Cl0p still had to break into each organization’s server separately. What made it a large-loss event was how easy and scalable each break-in was. PHP2Shell differs from MOVEit in three ways:
There is a caveat. PHP2Shell attacks leave very little trace, and breaches often take days or weeks to come to light, so the absence of confirmed break-ins is not proof that none have happened.
The closer comparison is Log4Shell. The US Cyber Safety Review Board found that it was exploited less than experts had predicted. It still judged Log4j endemic, with vulnerable copies likely to stay in systems for a decade or longer. Today, PHP2Shell looks set to follow the same pattern. More than half of the PHP servers that reveal their version run versions with no official fix. Products with PHP built in will stay exposed until their vendors act. Passwords and keys stolen now can be used months later.
We expect most insurable loss to come from medium and large enterprises. They are better resourced and usually patch faster than small firms. But they run far more PHP systems, including older in-house applications and vendor devices that cannot be fixed quickly, or at all. Those systems are also more often connected to internal networks and sensitive data, so a single breach can lead to ransomware, business interruption, or a large data loss. Small and micro businesses are less likely to patch. However, their exposure is mostly simple websites, often on hosts that fix PHP centrally, and their incidents tend to produce small claims.
The vulnerable code has been in PHP since 2012. AI cut the work of turning it into an attack from months to about a week. The security firm Calif found the first flaw using an OpenAI model, and Wiz discovered the problem independently, according to OpenAI. OpenAI says it has already found several other significant vulnerabilities and expects similar findings to rise sharply in the coming months.
The wider evidence points the same way. Mandiant's measure of how quickly attackers exploit vulnerabilities, relative to when a patch is released, fell from an average of 63 days in 2018–19 to five days in 2023. This month, researchers at XBOW used a publicly available AI model to build a full attack chain against Chrome in six days, work that once took a team months. And two days after the PHP2Shell fixes, PHP disclosed another flaw that those fixes do not cover, though PHP considers it an unlikely risk.
In the next weeks to months, the race from disclosure to attack to patch will repeat, often with several races at once. Node.js, for example, fixed a remote code execution flaw of its own on the same day as PHP. (Re)insurers need playbooks that treat a vulnerability discovery event, where millions of systems are exposed but no losses are confirmed, differently from a widespread event with material losses. Treating every disclosure as a catastrophe will exhaust teams, and treating none of them seriously risks missing the one that turns. A good playbook assigns who in underwriting, claims and portfolio management acts at each stage, and sets out the signals that would escalate an event. For PHP2Shell, these are the signals we are watching:
None of these alone would make PHP2Shell a catastrophe, but each would be a reason to look again at how the event is developing.
The volume of fixes is already straining defenders: Microsoft's October update alone fixed a record 1,413 flaws. Upgrading PHP can break websites, and insureds must wait for vendors to fix devices with PHP built in. If AI keeps surfacing critical flaws faster than organizations can install fixes in the next months and even into the next few years, an insured's speed at patching becomes a stronger underwriting and pricing signal.
Over the following years, there are two possible futures. In one, exploitable flaws outpace our ability to fix them, and widespread insecurity becomes the norm. In the other, the same AI tools help defenders find and close most of the serious flaws in the most widely used code, and the world becomes measurably more secure. There are early signs of both. OpenAI argues that AI found PHP2Shell before attackers did, and the Zero-Day Initiative notes that flaws are now being found faster than they are being exploited. Both futures are plausible, and it is too early to say which will prevail. Time will tell.
What is clear is that the past is a weaker guide than it used to be. The events that matter most to a cyber portfolio may be ones that haven't happened yet. That makes it important to pressure-test portfolios now against plausible but still theoretical scenarios, rather than wait for the next disclosure to become the next catastrophe.
CyberCube clients can do this today by running the relevant catastrophe scenarios in Portfolio Manager to see the range of outcomes a PHP2Shell-enabled event could produce. Our Concierge team is available to help work through the results.
To see how CyberCube keeps clients informed as major cyber events unfold, learn more about CAERS.