PHP2Shell: critical PHP vulnerabilities and how Cloudflare buys you time to update

As of October 22, 2026. The situation is changing daily; we add new information at the bottom, in the "Updates" section.

On October 21, the PHP team released fixes for two critical vulnerabilities in the PHP engine itself, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They allow an attacker to take over a server without logging in and without any bug in the website's code. Attacks are ongoing, and the first attempts were observed before the fixes were even published.

Below we explain what the problem is, how we assess it at ICWT, and what Cloudflare can realistically do when it is configured properly.

In short

• PHP from version 5.4 to 8.5.11 is vulnerable, which means practically every installation from before October 21.
• Fixes exist only for the 8.2, 8.3, 8.4 and 8.5 branches. Older versions have no official patch.
• The only complete fix is to update PHP and restart all PHP processes.
• Cloudflare enabled rules against the known attack variants automatically, on all plans, a few hours before disclosure. This does not replace updating, but it raises the bar for attackers considerably and buys time to patch calmly.

What the problem is

PHP limits how much memory a single request can use. When a request exceeds that limit or hits another fatal error, PHP stops immediately, in the middle of an operation, and does not clean up everything behind it. For years this was considered a cosmetic flaw. It turns out an attacker can deliberately trigger such an abort at the right moment and then use the mess left in memory to run their own code on the server.

Three things matter:

1. The attack does not need a bug in the application. The problem is in PHP, not in WordPress or your online store. Researchers demonstrated successful takeovers of WordPress, Drupal, Joomla, Magento, Nextcloud and Laravel applications, among others, without logging in.
2. An ordinary HTTP request is enough. The attack is delivered through a regular form submission (POST). There is no single vulnerable URL that could be blocked.
3. The risk depends on the server setup. Servers running Apache with mod_php are the most exposed, because the attack works before the website's code even runs. On PHP-FPM, today's most common setup, a successful attack has been confirmed for one of the two vulnerabilities, although it depends on what the application does.

The vulnerabilities are rated 9.2 on the CVSS v4 scale. The high score reflects that the attack is remote, requires no authentication and gives full control of the server. At the same time, the exploit itself is not trivial, and whether it works depends on the server's version and configuration.

How we assess it at ICWT

We take PHP2Shell seriously, but without panic. A few facts that we think matter more than the headlines:

• The attacks are real and ongoing. Amazon observed the first attempt on October 17, four days before disclosure, and since October 21 exploitation has been widespread. If your PHP server was reachable from the internet, review logs from October 17, not from the disclosure date.
• Older PHP versions are the biggest problem. A server on PHP 7.4, 8.0 or 8.1 will not get an official fix from the PHP team. Some Linux distributions (e.g. Debian, Ubuntu, Red Hat) are preparing their own packages, but for many companies this means a migration project rather than a quick patch. Until then, protection at the network edge is the main line of defense.
• Updating alone is not enough. After installing the new version, you must restart all PHP processes (PHP-FPM, Apache). Old code loaded in memory remains vulnerable.
• Don't trust slogans like "70% of the internet at risk". PHP does run on about 70% of websites whose server-side language is known (W3Techs), but the real risk for a given server depends on its PHP version, how PHP is run, and whether traffic passes through protection.

What Cloudflare did

Cloudflare enabled WAF rules detecting the known attack variants on October 21 at 03:02 UTC, about 9 hours before the fixes were officially published. The rules took effect automatically on all plans, including Free. Cloudflare also provides a rule that inspects the server's response and can stop it before data reaches the attacker (it is worth checking that it is enabled).

Cloudflare itself says plainly that this is a temporary measure and that the only complete fix is updating PHP. We agree. The WAF plays a different role here: it should filter out as many attacks as possible before they reach the server, and buy time for a planned, tested update instead of patching in the middle of the night.

This matters most against mass scanners. Bots sweeping the internet usually use publicly available exploits without major changes, and those are exactly the patterns Cloudflare's rules recognize best. There is no guarantee that the WAF will stop every variant, especially one hand-tuned for a specific server. It does, however, give a good chance that the server will not fall victim to the first wave of automated attacks.

What we tested ourselves

In our test environment, we sent a series of harmless requests to zones behind Cloudflare. They only mimicked the shape of known attacks, with no malicious payload. Cloudflare's default rules blocked every request shaped like one of the most widely described public attack variants. Other suspicious patterns, described by independent researchers, got through without being blocked.

This is not a weakness of Cloudflare but a property of any signature-based protection. Managed rules run on millions of websites at once, so they must target patterns that indicate an attack with high confidence, and they must not break legitimate traffic. They are also the same for everyone. Anyone, attackers included, can open their own Cloudflare account, put a test site behind it and try modified versions of the exploit until one gets through. Cloudflare itself reports that attackers are already modifying exploits, and it keeps updating its rules.

Mass scanners usually don't bother. A determined attacker targeting a specific company might. That is why we built our own rule set that catches a wider range of signals, including ones the default rules cannot safely block for all customers. Attackers don't know their contents and have no way to test their modifications against them. Because we start in log mode, the rules can be tuned to a specific application without the risk of blocking real users. More about them below.

Cloudflare protects you only when it is deployed properly

In practice, we see the biggest risk not in the rules themselves but in the configuration around them. The most common problems:

• Managed rules set to "Log" instead of "Block", or globally disabled or changed during earlier work. On paid plans, check that the new rules actually block.
• Exceptions that skip the WAF. Rules like "skip WAF for the admin panel", "skip for the API" or "skip for office IPs" often cover exactly the paths that PHP handles.
• A server reachable around Cloudflare. If the server responds directly on its IP address (old DNS records, a test environment, an api subdomain), an attacker can simply bypass the WAF. That is why the origin should accept traffic only from Cloudflare, e.g. via Authenticated Origin Pulls or Cloudflare Tunnel.
• No rule inspecting server responses. Make sure it is enabled.

What a WAF won't do

To be fair:

• it won't see traffic that bypasses Cloudflare,
• it has no visibility into PHP's memory and configuration on the server, and some attack variants leave no distinctive trace in HTTP traffic,
• it won't undo what has already been executed on the server,
• it relies on patterns, and attackers change their exploits. Cloudflare keeps updating its rules, but it is always a race.

That is why we treat the WAF as a safety buffer while you update, not as a substitute for updating.

What to do now

1. Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or to your distribution's patched package) and restart all PHP processes.
2. If you can't update right away, apply the mitigations recommended by the PHP team, including disabling session.upload_progress.enabled, limiting request size and blocking multipart forms where the application doesn't need them. Details are in the php.net announcement.
3. Check your Cloudflare configuration: rule mode, exceptions, and whether the server can be reached around Cloudflare.
4. Review logs from October 17 for unusual memory errors, bursts of 500 errors and PHP process restarts.
5. Consider rotating passwords, API keys and tokens on internet-facing PHP servers, because one of the attack variants allows reading fragments of server memory.

How we can help

Free PHP2Shell rule check. We will verify that the Cloudflare rules responsible for blocking these attacks work on your zones as they should: whether they are in block mode, whether exceptions or WAF skip rules disable them, whether the response inspection rule is enabled, and whether attack attempts already show up in your events. All we need is read-only access.

8 additional detection rules for the Enterprise plan, free for ICWT customers. Based on the PHP advisories, independent research and our own tests, we prepared a set of 8 rules that complement Cloudflare's rules with additional signals related to session handling, uploaded files, unusual form structure and server responses. The rules require request body inspection, which Cloudflare offers on the Enterprise plan. We recommend enabling them at least in log mode. That way you will see in Security Analytics whether someone is trying to exploit PHP2Shell in your infrastructure, even if the request was not blocked. After a few days of observation, you can decide which of them to switch to blocking.

We deliberately don't publish the rule contents, so as not to help attackers look for ways around them. We share them with our customers and help with deployment.

If you want to go further, a full Cloudflare configuration audit is part of our standard services.

Book a free PHP2Shell rule check or write to us: [email protected].

Sources

• Cloudflare: WAF protection against the PHP vulnerabilities
• AWS: exploitation detected before disclosure (MadPot)
• PHP Foundation: release notes and timeline

Updates

• 22.10.2026: first version of this post.