PHP CVE-2026-109618: Critical RCE Leaked, Patch Immediately

Update, October 21, 13:45 UTC: PHP released the fix early, around 00:30 UTC on October 21, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. An earlier version of this post described the release as still pending and said a public proof-of-concept was circulating. Huntress reports no public exploit code, only a short video that was posted and removed, so we have corrected both.

On October 20, 2026, the PHP security team posted an unusual advance notice: an emergency release for two critical vulnerabilities in PHP core, both rated CVSS version 4.0 9.2, scheduled for Wednesday, October 21 at 14:00 UTC. Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws are serious enough that PHP broke its normal pattern and warned the world a day early, reserving the right to ship sooner if details went public or exploitation appeared. Details went public: researchers nicknamed the flaws php2shell, and the SANS Internet Storm Center raised its InfoCon to yellow. PHP did ship sooner: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 landed around 00:30 UTC on October 21.

PHP runs a large share of the web, so a flaw in its core is not a single-vendor problem. It is a problem for nearly everyone who operates a web server. That is exactly why this one deserves a clear-eyed read rather than a panic, and the first job is to separate what PHP has actually confirmed from what is being reported around it.

What PHP has confirmed, and what it has not

The official PHP advisory is short. It confirms that PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two vulnerabilities that can allow unauthenticated remote code execution, that both are rated CVSS v4.0 9.2, and that "there are no complete mitigations, updating is the only safe choice."

Everything beyond that is reported, not official. watchTowr notes leaked claims that the flaw reaches back as far as PHP 5, while cautioning that no vendor advisory has confirmed the scope or the root cause. Huntress says the vulnerable component remains unidentified. Early community analysis has pointed at PHP's handling of multipart form uploads, but that too is unconfirmed. Treat the older-version claims and the root cause as unconfirmed until PHP publishes the technical details.

What is not in dispute: fixes ship only for the supported branches, PHP 8.2 through 8.5, as 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything on 8.1 or older is end of life and will not receive a patch, and PHP 8.2 itself reaches end of life on December 31, 2026. If you are still running an EOL branch, the only real fix is to move forward.

Why a PHP core flaw hits hosting operators harder

Most critical CVEs we cover affect one product you can inventory and gate. PHP is different because it is a dependency of almost everything on a typical web host: WordPress, Magento and other storefronts, Laravel and Symfony apps, control-panel tooling, and countless bespoke sites all sit on the same interpreter. A single server can run several PHP versions at once through per-site handlers, which means the exposure is not one box to patch but a matrix of sites and versions to walk. Command injection and remote code execution already rank second only to cross-site scripting among the bug classes we logged across the events we triaged in the last 90 days, and a flaw in the runtime beneath all of those applications is the broadest version of that pattern.

The practical consequence is that "update PHP" is rarely one action on a real host. It is an update per branch, per site handler, with an application-compatibility check behind each. Walk that inventory today, branch by branch.

What to do now that the patch is out

The patch is the fix, and PHP says there are no complete mitigations. Everything else only shrinks the window until you apply it.

• Update now. Move every PHP branch and every per-site handler you run to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, from php.net or your distribution's channels as their builds land.
• Inventory first. List every server and site running PHP and the exact version each uses, so the rollout is a checklist rather than a hunt. watchTowr's top recommendation is exactly this.
• Reduce reachability. Put internet-facing PHP applications behind a web application firewall and restrict anything that does not need to be public. CloudLinux reports that Imunify360 ruleset 8.83 virtual-patches the reported attack pattern, blocking it on Apache and logging it on LiteSpeed. A virtual patch buys time; it is not a substitute for the upstream fix.
• Do not trust the circulating php.ini workaround. Advice to disable session upload progress in php.ini is making the rounds. CloudLinux states that this suggestion is unconfirmed and that at least one report says it does not work. Skip unverified config tweaks and focus on patching and WAF coverage.
• Hunt for the aftermath, not just the attempt. A PHP worker process almost never has a legitimate reason to launch a shell or a network tool. Huntress flags PHP spawning child processes such as bash, python, curl, or wget, along with reverse-shell markers, as the signal to chase. That detection holds regardless of which component the flaw turns out to live in.

title: PHP runtime spawning a command interpreter
logsource:
  category: process_creation
detection:
  parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php'
      - '/lsphp'
      - '/httpd'
      - '/apache2'
  child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/ncat'
  condition: parent and child
level: high

Tune the parent list to the handlers your fleet actually runs, then alert on any match. The point is the lineage: a legitimate request is served inside the PHP process, so a PHP process that forks a shell has already lost.

Where this stands

As of October 21, neither watchTowr nor Huntress had seen exploitation in the wild, and Huntress was not aware of public exploit code. That is the good news, and it is also the countdown. Huntress expects technical details and proof-of-concept code to follow quickly now that the fix has shipped, and the patch itself gives attackers a precise map. The gap between a published fix and mass scanning has closed in hours for less widely deployed software than PHP. Patch today, watch your PHP process lineage, and do not wait for an exploitation headline to treat this as urgent.