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

‍

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