Triskele Labs Blog

PHP Critical RCE (CVE-2026-109618 & CVE-2026-109619)

Written by  Brandon Sawyer | Oct 21, 2026, 10:14:47 PM

Published: Thu 22 October 2026

Prepared by: Brandon Sawyer, Vulnerability Analyst

Purpose

On 21 October 2026, the PHP project released emergency security updates for two critical remote code execution (RCE) vulnerabilities in the core PHP engine, CVE-2026-109618 and CVE-2026-109619, collectively known as "PHP2Shell". Details leaked online on 20 October ahead of the coordinated disclosure, forcing PHP to bring the release forward by a day. The flaws allow an unauthenticated remote threat actor to execute code on any web server running an affected PHP version, regardless of the application running on top of it. watchTowr reports in-the-wild exploitation through its honeypot network as of 21 October, and Rapid7 recommends patching on an emergency basis outside normal cycles.

Vulnerability Details

Both vulnerabilities are memory-safety flaws in how PHP handles fatal errors, particularly out-of-memory (OOM) errors, during request processing. Each carries a CVSS v4.0 base score of 9.2 (Critical), vector string CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, and successful exploitation grants code execution with the privileges of the web worker.

CVE

Description

CVSS v4.0

CVE-2026-109618

RCE via memory corruption during OOM handling; also enables remote disclosure of PHP worker memory

9.2

CVE-2026-109619

RCE via use-after-free of stale global state retained between requests

9.2

According to Wiz Research, which discovered the flaws with the help of frontier AI models, a fatal error can leave corrupted internal state behind when a request ends abruptly. A later request handled by the same worker then reuses that stale state. Crafted multipart (form and file upload) requests can trigger the condition, and the session upload progress feature, enabled by default, can consume the stale state even if the application never calls session_start().

All PHP installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest risk, as exploitation can succeed before any application code runs. Wiz demonstrated pre-authentication RCE against the latest WordPress, Drupal and Joomla container images, and separately showed that passwords, tokens and API keys could be read from process memory without achieving RCE.

Wiz states every PHP version released in the past decade, back to PHP 5.4, is affected by at least one of the flaws. Palo Alto Networks has also confirmed that PAN-OS and Panorama are affected, with fixes pending.

Impact

Successful exploitation grants a threat actor unauthenticated code execution on the web server as the web worker account. Because PHP powers an estimated 70% of websites, including WordPress, Drupal, Joomla and Magento, as well as control panels and vendor software that bundle PHP without advertising it, a compromised server can expose:

  • Passwords, session tokens, API keys and certificates held in PHP process memory, including data from other users' requests
  • Application databases, customer data and business logic behind internet-facing sites
  • A foothold for web shells, persistence and lateral movement into the wider network
  • Website defacement and service disruption

The vulnerable code sits below the application layer, so a fully patched CMS or even a simple application running on an affected PHP version can still be exploited. Internet-facing Linux web servers and shared hosting without endpoint detection are particularly at risk of quiet, unnoticed compromise.

With exploitation already reported, multiple independent reproductions under way and AI lowering the effort needed to adapt exploits across deployments, mass exploitation is probable and swift patching should be prioritised.

Mitigation

Primary Remediation

The primary remediation is to update all PHP installations to the fixed version for their release line, or a vendor package containing both complete patches:

Release Line

Affected Versions

Fixed Version

8.5.x

Before 8.5.12

8.5.12

8.4.x

Before 8.4.27

8.4.27

8.3.x

Before 8.3.36

8.3.36

8.2.x

Before 8.2.35

8.2.35

8.1.x, 8.0.x, 7.4.x

All

No official release; vendor package or PHP source backport

7.3.x and earlier

All

None; upgrade to a supported version

Linux distributions and LTS vendors received patches in advance, so check your vendor for updated packages. Users of the rpms.remirepo.net repository should switch to distribution packages or build from source, as updates there were delayed. Patch internet-facing systems first.

Palo Alto Networks PAN-OS and Panorama are affected and fixes are pending. Until they are released, restrict management interface access to trusted internal IP addresses or a jump box. Threat Prevention signatures 543004, 97622, 97623, 97624 and 97625 provide coverage.

Compensating Controls

Where immediate patching is not possible, PHP's interim configuration changes can reduce exposure to the confirmed attack paths. Each must be set administratively (php.ini, FPM pool or server configuration, not ini_set() or .user.ini) and every worker restarted:

  • Set session.upload_progress.enabled=0 to close the confirmed session lifecycle paths
  • On PHP 8.5, set fatal_error_backtraces=0 to close the fatal error backtrace path
  • Enforce memory_limit=-1 to remove the predictable OOM trigger, while bounding request size at the frontend (post_max_size of 8M, or 32M where uploads are needed) to avoid resource exhaustion
  • Block multipart requests at a WAF or reverse proxy if the application does not use them
  • Isolate end-of-life PHP from the internet, or place it behind a VPN or WAF

These measures are stop-gaps only. They address specific known paths, will not remove any access a threat actor already gained, and an update containing both fixes remains the only complete remediation.

Detection

Indicators and Log-Based Detection

As this is an extremely new and emerging situation, no confirmed indicators of compromise (IOCs) have been published at this time. Because exploitation occurs below the application layer, application logs may hold little context, and suppressing diagnostics does not prevent exploitation, so an absence of log entries should not be treated as proof a server is safe.

In the absence of vendor IOCs, the following hunting leads are derived from Wiz and Huntress reporting and should be treated as a starting point rather than a complete picture:

  • Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
  • Unexpectedly large or malformed PHPSESSID response cookies, which may indicate memory disclosure
  • Unexplained PHP worker crashes or churn
  • PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl) or download tools (curl, wget, nc, certutil.exe)
  • Command lines containing reverse shell patterns such as /dev/tcp/, fsockopen or mkfifo
  • Reconnaissance commands such as whoami, id, uname -a or ipconfig run from the web server

Recommended Detection and Hunting Activities

  • Inventory all PHP installations and confirm versions to scope exposure
  • Review web server, PHP and WAF logs for the indicators above, focusing on the period since 20 October 2026
  • Alert on PHP worker processes launching shells, interpreters or download tools
  • Check web roots for web shells and new files, and review for new cron jobs, scheduled tasks and accounts
  • If any indicator is identified, isolate the server, preserve web server and PHP logs, rotate accessible secrets and engage incident response

This is an emerging situation and details are still developing. Triskele Labs is actively monitoring vendor and researcher updates, and this advisory will be updated as further information, including indicators of compromise and additional patch guidance, becomes available. 

Clients with IR retainer will receive a threat hunt that is being developed specific to CVE-2026-109618 & CVE-2026-109619. 

MDR customers: Triskele Labs will continue tuning detections and analysing IOCs for behaviours consistent with the exploitation of CVE-2026-109618 and CVE-2026-109619 across supported log sources as they are made available.

Vulnerability Management customers: Environments will be assessed for vulnerable versions of PHP affected by CVE-2026-109618 and CVE-2026-109619 once detections are made available. Any findings will be communicated through priority channels.

References