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.

EASILY SPOT & STOP CYBER THREATS IN ONE PLACE

Coalition Control

Take control of your cyber risk >

This blog post is designed to provide general information on the topic presented and is not intended to construe or render legal or other professional services of any kind. If legal or other professional services are required, the services of a professional should be sought. Descriptions of coverage are for general informational purposes only and are subject to the terms and conditions, including the limitations and exclusions, of the applicable policy. The reader is cautioned to consult independent professional advisors and formulate independent conclusions and opinions regarding the subject matter discussed herein. Coalition makes no representations as to the accuracy or completeness of this content. Any action taken based on this information is at the sole discretion and risk of the reader. Coalition and its affiliates expressly disclaim any liability for losses or damages resulting from the use of or reliance on this information, which is used strictly at the reader’s own risk. The blog post may include links to other third-party websites. These links are provided as a convenience only. Coalition does not endorse, have control over nor assume responsibility or liability for the content, privacy policy or practices of any such third-party websites.

Copyright © 2026. All rights reserved. Coalition and the Coalition logo are trademarks of Coalition, Inc.