PHP2Shell: What We Know and What to Do Before the Patch

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

We will update this post as PHP publishes details and Miggo's research team verifies them.

Details of two critical remote code execution flaws in PHP leaked online on October 20, ahead of coordinated disclosure. PHP ships the fix today at 14:00 UTC. If you run PHP 8.1 or older, there is no confirmation from PHP that an official patch is coming.

The short version: inventory your PHP, be ready to patch at 14:00 UTC, and get any PHP-powered application off the public internet or behind a WAF.

What We Know

On October 20 at 19:33 UTC, the PHP security team announced an out-of-cycle release for two critical vulnerabilities, both rated 9.2 under CVSS v4.0. The fix is scheduled for today, October 21, at 14:00 UTC (10:00 ET), a day ahead of the original embargo. PHP may release earlier if details go public or exploitation starts, and will publish full details, affected versions and fixed versions with the release.

watchTowr says the flaws allow remote code execution and that it has reproduced CVE-2026-109618. That ID and CVE-2026-109619 are in wide use, but PHP's notice does not name them yet.

Under PHP's support policy, only 8.2, 8.3, 8.4, and 8.5 will get the fix. PHP 8.1, 8.0, 7.x, and 5.x are end-of-life, and whether they get a fix is not yet confirmed.

As of 09:30 UTC, there is no confirmed exploitation in the wild. CERT-EU advisory 2026-018 recommends considering isolating internet-facing applications from public networks until a fix is available.

Some claims are still unverified. The leaked post put the score at CVSS 10.0 and said every version since PHP 5 is affected. PHP has confirmed neither, and no one has officially described what configuration, if any, exploitation requires. GitHub repositories offering exploits, checkers and emergency patches are also circulating. Miggo has not validated any of them: don't run them against production, and don't treat a "not vulnerable" result as clearance. The same caution applies to configuration workarounds. PHP has endorsed none, and some, such as blocking multipart/form-data POST requests, break legitimate features like file uploads.

Why the Timing Is Tight

On October 21, there are 2.2 million internet-facing hosts whose Shodan banners report PHP, most of which report version 8.1 or older. Banner counts do not confirm vulnerable systems, but they show how many teams need a plan beyond "apply the patch".

Speed matters as much as scale, we expect mass exploitation within a very short time of the release. Once the patch is public, comparing it with the old code shows attackers exactly where the bugs are.

What to Do Now

1. Find every PHP runtime in your application landscape. Include PHP bundled in appliances, 3rd-party software like WordPress, and hosting panels such as cPanel. Record the version and whether it faces the internet.

2. Stage the patch. On 8.2 to 8.5, prepare the update now and roll it out to internet-facing systems first at 14:00 UTC. If you rely on distribution or hosting-provider packages, check when their backports will land; they may trail the upstream release.

3. Watch for exploitation. Alert when PHP workers (php-fpm, php-cgi, httpd, apache2) spawn shells (sh, bash), interpreters (python, perl) or download tools (curl, wget). If you suspect a compromise, isolate the server, preserve web and PHP logs, and look for web shells, new files in the web root, new cron jobs or scheduled tasks, and new accounts.

4. Treat today's WAF rules as a stopgap. WAF vendors are already shipping generic rules. Cloudflare published an emergency release today that adds four "Anomalous Execution" rules to its Managed Ruleset. Its changelog does not name PHP2Shell or either CVE.

What Miggo Is Doing

Our research team is running a dedicated response to PHP2Shell.

Exposure. We are identifying which customer services run PHP, and on which versions, and contacting customers with internet-facing end-of-life PHP directly. Miggo customers can see all running PHP services in the Services inventory view.

Detection. Miggo's runtime sensor flags PHP workers that spawn shells or write tools to disk, the most reliable sign of successful exploitation, whatever the bugs turn out to be. The research team is actively monitoring after PoCs are published to ensure full coverage.

WAF rules. We are building rules from our own research and working on them directly with customers. As the situation evolves, we will publish specific rules for individual WAF vendors.

We will update this post as each protection ships. Miggo customers with questions about their exposure can contact their Miggo team.

Sources

PHP, "Upcoming Critical PHP Security Release," October 20, 2026: https://www.php.net/archive/2026.php#2026-10-20-1
CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018
The Hacker News, "PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert" (Mallory exposure figures): https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html
Cloudflare WAF changelog, October 21, 2026 emergency release, Managed Ruleset: https://developers.cloudflare.com/changelog/post/2026-10-21-emergency-waf-release-cfmr/

‍

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>