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 AWS WAF and Cloudflare in hand 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.20 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.20 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.21 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

<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>