Mitigating PHP2Shell Now: Everything You Need to Know

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

PHP has shipped fixes for PHP2Shell, but only for its four newest versions, and upgrading every application takes time. Miggo Security customers had multi-layer protection (Edge and runtime) before the patch was public, and every AWS WAF customer can now add the same protection through Miggo Rulesets for AWS WAF.

PHP has now published fixes for PHP2Shell, the two critical remote code execution vulnerabilities that leaked online on October 20. For many organizations, the work has only started. The fixes cover only PHP's four newest versions, and patching every application that runs PHP can take days for some teams and months for others. Miggo began working on protections as soon as PHP announced the release, and Miggo runtime protection and Miggo WAF Copilot customers had rules for customers across multiple WAF vendors before the patch went public. This post explains what the patch covers, why patching alone is not enough this week, and how to keep your applications protected until every system is upgraded.

If you are catching up, start with our first post, PHP2Shell: What We Know and What to Do Before the Patch, which covers the leak, the disclosure timeline and the early guidance.

The Patch Is Out, but the Exposure Is Not Over

On October 21, PHP published security advisories and fixed releases for both vulnerabilities:

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w)
CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp)

Both are rated 9.2 under CVSS v4.0, and neither requires authentication or user interaction. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP's advisories are clear that updating is the only complete mitigation, and that the interim configuration changes they describe are partial measures rather than substitutes for patching.

PHP has not announced fixes for 8.1 or older, which are end of life. That leaves a large share of the web without an upstream patch. A Miggo search of Shodan found more than 2.2 million internet-facing hosts reporting PHP, and many of them run versions that this release does not cover. The concern is not theoretical. On the day of the release, organizations across Belgium and the Netherlands, including government services, a hospital and major media groups, took websites offline as a precaution.

Why Patching Alone Is Not Enough This Week

Even for teams on supported versions, a patch is the start of a process. Each application has to be tested and redeployed, and teams that rely on Linux distribution or hosting provider packages may wait for backports that trail the upstream release. For teams on end-of-life versions, there is no patch to apply at all. Upgrading an older PHP application can mean rewriting code and retesting dependencies, which takes weeks or months.

The risk also rises once the fix is public. Attackers can compare the patched and unpatched code to see exactly what changed, and use that to build working exploits. The days after a patch ships are when most organizations are still exposed and when attackers have the most information.

This is the gap that Miggo is built to close. We believe the right response is to mitigate now and patch on a timeline your teams can manage.

What to Do Now

Whether or not you use Miggo, these are the steps we recommend:

Mitigate immediately:
- Deploy a WAF rule to block exploitation. Miggo customers can use the WAF Copilot rule today to generate a custom rule for all WAF vendors
- High Emerging Threat Ruleset (HET) for AWS WAF. AWS WAF customers can subscribe through their WAF console to the Miggo HET ruleset. The rule will be available under the specific version name v1.22 and forward. The rule will be deployed in Count mode by default, allowing customers to monitor potential matches and assess the impact before enabling blocking. (How to subscribe.)
Patch. Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, starting with internet-facing systems. If you rely on distribution or hosting provider packages, confirm when their fixed builds are available.If you run PHP 8.1 or older, plan the upgrade, and in the meantime put the application behind a WAF rule or take it off the public internet.
Watch for exploitation. Alert when PHP workers such as php-fpm, php-cgi, httpd or apache2 launch shells, interpreters or download tools. If you suspect a compromise, isolate the server and preserve your logs before investigating.
Treat configuration workarounds as temporary. PHP's advisories describe interim settings that reduce risk, but they are partial and do not replace patching.

How Miggo Responded: From First Signal to Protection in Hours

Vulnerabilities no longer have a single disclosure date. They arrive in three stages: the leak that signals something is coming, the patch that shows attackers and defenders the same code, and the CVE details that follow hours or days later. Waiting for the third stage means acting after the first wave of attacks. Miggo acts at the first signal, ships a first protection as soon as we understand the attack, and refines it as the picture sharpens.

Mitigations Immediately Provided by Miggo

At the Edge

WAF Copilot builds and manages WAF rules for the vulnerabilities that matter in each customer's environment. For PHP2Shell, our research team built a rule that blocks the request pattern on which the attack depends, and we made it available for both AWS WAF and Cloudflare, among other WAFs.

Customers can deploy the rule across their whole WAF. It matches only traffic to PHP applications, so it does not need to be limited to specific hosts or paths, and it will not affect applications built on other technologies.

Instant Protection for Every AWS WAF Customer

You do not need to be a Miggo customer to get this protection. Miggo’s High Emerging Threat (HET) Ruleset is a managed ruleset for AWS WAF that any AWS WAF customer can subscribe to, and version 1.22 adds a rule for PHP2Shell. Once you subscribe, the rule runs in your existing web ACL, and we will keep updating it as our research team refines the protection.

To enable it:

Subscribe to Miggo’s HET Ruleset in AWS Marketplace
Add the ruleset to your web ACL and select the latest version (v1.22 at the time of this blog's latest update).
Recommend setting the rule on Count, review matches, and then switch to Block.

Protection Inside the Application With Miggo's Runtime Sensor

A WAF rule stops the attack at the edge. Miggo's runtime sensor adds a second layer inside the application, which matters if traffic reaches the server by another route or an attacker finds a way past the rule.

PHP2Shell is harder to detect than most PHP vulnerabilities because the exploitation happens inside the PHP engine itself rather than in application code. Instead of relying on a signature for one exploit, the sensor watches for a behavior that legitimate PHP never shows: the PHP engine launching a new process while handling a request, without the application's own code being involved. Because the detection is based on that behavior, it should also catch future attacks that work the same way, even if they use a different exploit.

Mitigate Now, Patch Later

The patch sets the floor for PHP2Shell, but most organizations will need weeks to get every PHP application onto a fixed version, and some will need much longer. Miggo customers had WAF protection before the fix was public, and any AWS WAF customer can now add the same protection through Miggo Rulesets for AWS WAF. For teams that can patch today, patch. For teams that cannot patch everything today, Miggo keeps your applications protected until you can. You do not have to choose between waiting for an upgrade and staying protected.

Book a demo to see which of your exposed services run PHP, and protect them today.

Sources

PHP, Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
PHP, Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
Miggo, "PHP2Shell: What We Know and What to Do Before the Patch": https://www.miggo.io/post/php2shell-what-we-know-and-what-to-do-before-the-patch
The Brussels Times, "Major websites go offline as critical PHP vulnerability triggers security fears": https://www.brusselstimes.com/belgium/2371464/major-websites-go-offline-as-critical-php-vulnerability-triggers-security-fears

FAQ's

This page brings together the guidance for PHP2Shell in one place.

Am I Vulnerable?

PHP Branch	Vulnerable Versions	Fixed In	Status
8.5	Before 8.5.12	8.5.12	Patch available
8.4	Before 8.4.27	8.4.27	Patch available
8.3	Before 8.3.36	8.3.36	Patch available
8.2	Before 8.2.35	8.2.35	Patch available
8.1, 8.0, 7.x, 5.x	All	No official release; PHP published source patches	End of life

PHP Branch:
8.5

Vulnerable Versions:
Before 8.5.12

Fixed In:
8.5.12

Status:
Patch available

PHP Branch:
8.4

Vulnerable Versions:
Before 8.4.27

Fixed In:
8.4.27

Status:
Patch available

PHP Branch:
8.3

Vulnerable Versions:
Before 8.3.36

Fixed In:
8.3.36

Status:
Patch available

PHP Branch:
8.2

Vulnerable Versions:
Before 8.2.35

Fixed In:
8.2.35

Status:
Patch available

PHP Branch:
8.1, 8.0, 7.x, 5.x

Vulnerable Versions:
All

Fixed In:
No official release; PHP published source patches

Status:
End of life

If you get PHP from a Linux distribution or a hosting provider, check their advisories for backported fixes, which may use different version numbers.

‍

What Is PHP2Shell?

PHP2Shell is the name researchers gave to two critical remote code execution vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619. They can let an attacker run code on a server that runs PHP, without logging in. PHP itself has not used the name.

What Is the Impact, and Who Is Vulnerable?

PHP runs a large share of the web, including WordPress, many e-commerce platforms and many internal tools. Any internet-facing application on an unpatched PHP version may be exposed. A Miggo search of Shodan found more than 2.2 million internet-facing hosts reporting PHP. Whether a specific server can be exploited depends on its version, configuration and deployment, as PHP's advisories explain.

What Is the Timeline?

Details leaked on October 20, and PHP announced an out-of-cycle release the same evening. PHP published fixes and advisories on Oct 21, 2026.

What About PHP 8.1 and Older?

These versions are end of life, and PHP has not announced fixes for them. Plan the upgrade, check whether your Linux distribution or hosting provider offers a backported fix, and in the meantime protect the application with WAF rules and runtime detection, or take it off the public internet.

What Should Security Teams Do Immediately?

Patch, starting with internet-facing systems. Deploy WAF rules to mitigate while you patch. Add runtime detection for PHP workers launching unexpected processes. Review your logs for unusual form submissions and unexpected processes on PHP servers.

Does a WAF Protect You?

A WAF reduces risk, but it is not enough on its own. The attack targets how PHP processes a request, and a WAF does not see the request the way PHP does, so generic rules can be bypassed by reshaping the request. Rules that block the feature involved can also affect legitimate uploads. Use WAF rules as one layer, keep them updated, add runtime detection, and patch.

Can Attackers Get Around WAF Rules, including Miggo's?

Any WAF rule can be bypassed, including ours. Now that the patch is public, attackers can study what changed and reshape their requests until a rule no longer matches. Generic rules written before the technical details were public are the easiest to get around.

The difference is what happens next. WAF protection for a threat like this cannot be a one-time rule. The core of Miggo's autonomous mitigation is a continuous protection loop: our research team tests our rules against new proofs of concept and bypass techniques as they appear, and we keep updating the rules for as long as the threat keeps evolving. AWS WAF customers get these updates as new versions of Miggo's HET Ruleset.

In addition to the WAF, Miggo's runtime sensor detects the attack by its behavior inside the application, so it does not depend on recognizing a specific request.

Why Did Websites in Belgium and the Netherlands Go Offline?

On October 21, several organizations, including government services, a hospital and major media groups, took websites offline as a precaution while they assessed their exposure. Their notices described the outages as maintenance. Source: The Brussels Times

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>