Why PHP2Shell Claims Will Lag Exploits by Weeks
A serious bug landed in PHP last month.
The software powers roughly 7 out of 10 of websites whose server-side language is known, and two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) let an attacker run code on a web server and take control of it without logging in.
Cyber insurance claims from PHP2Shell haven’t arrived en masse yet, causing some to wonder whether our entire industry has overhyped how bad this is.
Below, I’ll explain why the fact that claims aren’t rolling in doesn’t mean we’re safe. To start, we need to understand two things: the difference between crashing a program and controlling it, and a defense called Address Space Layout Randomization (ASLR).
PHP2Shell: Understanding the bug
PHP2Shell lives in the code PHP uses to read file uploads. When a browser sends a form with a file attached, PHP has to take that stream of bytes apart. If you send a carefully broken upload, PHP writes outside the memory it was meant to use. This is called memory corruption.
Crashing is easy. Control is hard.
Memory corruption bugs come in two grades.
The easy grade is crashing. Send the bad upload, the PHP worker dies, and the visitor gets an error page. Our scanner does exactly this, in a controlled way, which is how we know who is vulnerable. Crashing takes an afternoon.
The hard grade is control. Instead of crashing, the attacker overwrites memory with such precision that the program starts running the attacker's instructions. That is a web shell, and that is what leads to a claim. Control takes weeks or months, and it is where ASLR comes in.
ASLR: The street that gets renumbered
To take control, the attacker has to point the program at code of their choosing. That means knowing exactly where things live in memory. Think of it as needing a street address to deliver a package.
ASLR is a defense built into every modern operating system. Every time a program starts, the operating system shuffles where everything sits in memory. The street gets renumbered. The attacker's package, built for last week's address, lands on the wrong house, and the program just crashes.
So the attacker has to find the address first. Usually that means finding a second bug that leaks memory, or finding some part of the layout that does not move. Each of those is its own research project.
One exploit per platform, per version
Here’s the part that matters most for timing: Even once an attacker beats ASLR on one server, that work does not transfer.
PHP isn’t a single program. There’s PHP 7.4, 8.1, and 8.3, built by Ubuntu, Red Hat, and cPanel, running inside Apache or behind PHP-FPM, compiled with different options on each. Every one of those combinations lays memory out differently. An exploit that works on PHP 8.3 on Ubuntu with PHP-FPM does nothing on PHP 7.4 on CentOS with Apache. It has to be rebuilt and retested for each one.
Coalition scanning data shows how fragmented this is. Among the servers we can confirm as vulnerable, most are on old PHP branches (5.x, 7.x, 8.0, and 8.1), scattered across dozens of patch levels. There’s no single target that covers the fleet.
That’s why a crash is one afternoon, and a weaponized exploit is a long list of afternoons.
Why the claims come later
Right now, the attackers who can exploit PHP2Shell are skilled teams working one platform at a time. They pick high-value targets, not everyone. Mass exploitation, the kind that produces a flood of claims, needs a reliable exploit that someone has packaged and sold or published. That hasn’t happened yet for most platforms.
And even when it does, the break-in isn't the claim. The claim is the ransomware note or the data theft that comes weeks after the break-in, once the attacker has moved around inside the network. The claims curve always lags the exploit curve by weeks.
What to do now
The window before mass exploitation is exactly the time to act, and the fix is simple. For version numbers, patch levels and temporary mitigations, see our full security alert.
On a supported PHP version? Update it.
On an end-of-life version? Most of the vulnerable servers we see are. You can’t patch, so you need to upgrade or put a web application firewall (WAF) in front.
We can already see these measures working in our scans; the number of servers with a WAF in front jumped in just the first two days.
The lack of claims so far is the calm before the storm, not proof that the storm isn't coming. Patch now, while attackers are still doing the hard part.