PHP2SHELL: Critical PHP RCE Flaws Threaten Web Infrastructure Amid Active Exploitation (CVE-2026-109618 & CVE-2026-109619)

Executive Summary

Update 1 (October 23rd, 2026) As of the time of this update, broad exploitation attempts against CVE-2026-109618 and CVE-2026-109619 have been reported, including by Cloudflare starting October 21st, but we are not aware of any confirmed mass exploitation of PHP2Shell at this time. Exploitation is not straightforward, and no single exploit works across all PHP versions and configurations. However, VulnCheck reports a working exploit for CVE-2026-109618 that bypasses Address Space Layout Randomization (ASLR) on x86-64 systems with standard production settings, against unpatched PHP 8.4 releases. Currently, Proof of Concept (PoC) exploits that work against a broad range of targets are not publicly available, however, Beazley Security expects attackers to continue building reliable exploitation capabilities against common PHP deployment scenarios in the coming days and weeks. Updating PHP remains the only complete fix.

In addition, multiple sources claim that the original patches for CVE-2026-109619 could be bypassed. PHP has confirmed a separate vulnerability, CVE-2026-115560, in its session upload progress feature. PHP will publish a full advisory with its next regular release. Until then, PHP recommends also disabling upload progress by setting session.upload_progress.enabled=0, a step they first listed as a mitigation in its original advisory for CVE-2026-109619 and it is included in our mitigation recommendations below. The PHP project considers exploitation of this (new) vulnerability unlikely, as it takes an unusual combination of (default) server settings and application code. Beazley Security's guidance is unchanged: update PHP immediately. See Mitigations and Technical Details below.

On October 21st, 2026, the PHP project released fixes for two critical vulnerabilities in the PHP runtime that are under active exploitation. Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws let an unauthenticated, remote attacker execute code as the web server worker by sending crafted requests that corrupt PHP's internal memory when request handling fails.

On October 20th, 2026, the PHP security team gave advance notice of a security release addressing two critical vulnerabilities. PHP is the server-side language behind WordPress, Drupal, Magento, and a large portion of shared hosting on the internet. Because these vulnerabilities affect PHP itself, updating applications alone may not eliminate exposure. Details and proof-of-concept (PoC) exploit code leaked before the release of patches, increasing the risk of widespread exploitation and urgency to patch.

On October 21st, Cloudflare reported early exploitation attempts against both flaws signaling attackers are already weaponizing these flaws in the wild. Given the reach of PHP, the leaked exploit details, and reported attacks, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.

Affected Systems or Products

The NCSC in the Netherlands have compiled a list of software products that use PHP. Additional details are available in the Appendix section of this advisory.

Mitigations / Workarounds

Update 1 (October 23rd, 2026): PHP has confirmed a separate vulnerability, CVE-2026-115560, in its session upload progress feature, and will publish a full advisory with its next regular release. Until then, PHP recommends setting session.upload_progress.enabled=0 in addition to applying the October 21st updates. This setting was already listed as a mitigation in PHP’s advisory for CVE-2026-109619. For CVE-2026-115560, PHP says it fully protects against the vector. For CVE-2026-109619 it blocks only the confirmed session paths, so it does not replace patching. This setting mitigates the attack vector in the most commonly produced exploits and proof of concept examples we have observed since publication.

The PHP project states that updating to a release containing the fixes is the only complete mitigation, and that configuration workarounds do not provide complete protection. A single upgrade to a fixed release addresses both vulnerabilities. The two flaws have different root causes, so a measure aimed at one does not protect against the other, and the interim steps below block only specific confirmed paths.

If patching cannot be immediately applied, the following may help to temporarily reduce risk:

• 

  Restrict PHP applications that do not require public access to trusted networks or a VPN. When taking a service offline, use a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials.

• 

  Update and deploy WAF rules to restrict malformed or excessive multipart HTTP requests related to the flaw. CloudFlare has also published specific rules in its blog that may help block attack traffic. WAF protections may reduce exploitation attempts but should not be considered a substitute for patching.

• 

  Inventory every server, container image, and appliance that runs PHP, including PHP bundled inside third-party products, and record the version each runs. Commands listed below may help with discovery.

Discovery - Unix Hosts

# Binaries on PATH and across the filesystem
which -a php php5 php7 php8 php-cgi php-fpm 2>/dev/null
find / -xdev -type f -iname "php*" -perm -u+x 2>/dev/null

# Version for each binary found
for bin in $(find / -xdev -type f -iname "php*" -perm -u+x 2>/dev/null); do
  echo "$bin: $($bin -v 2>/dev/null | head -1)"
done

# Package manager records
dpkg -l | grep -i php          # Debian/Ubuntu
rpm -qa | grep -i php          # RHEL/CentOS/Fedora
brew list | grep -i php        # macOS/Homebrew

# Web server wiring
grep -r "php" /etc/apache2/sites-enabled/ /etc/nginx/sites-enabled/ 2>/dev/null
find /etc -iname "*fpm*" -path "*php*" 2>/dev/null

# Running processes and listening sockets
ps aux | grep -i php
ss -tlnp | grep php-fpm

Discovery - Windows Hosts

# Search common install locations and PATH
Get-Command php -ErrorAction SilentlyContinue
where.exe php.exe 2>$null

# Filesystem sweep (slow on large disks)
Get-ChildItem -Path C:\ -Include php.exe,php-cgi.exe,php-win.exe -Recurse -ErrorAction SilentlyContinue -Force

# Common manual-install locations
Test-Path "C:\php", "C:\xampp\php", "C:\wamp64\bin\php", "C:\wamp\bin\php", "C:\Program Files\PHP", "C:\inetpub\php"

# Version per binary found
Get-ChildItem -Path C:\ -Include php.exe -Recurse -ErrorAction SilentlyContinue -Force | ForEach-Object {
    $ver = & $_.FullName -v 2>$null | Select-Object -First 1
    [PSCustomObject]@{ Path = $_.FullName; Version = $ver }
}

Patches

The PHP project has released fixed versions for every supported branch, linked from its security advisories for CVE-2026-109618 and CVE-2026-109619, and its security team has made minimal source backports available for the end-of-life 7.4, 8.0, and 8.1 branches as an exception for source builders.

Distribution and vendor packages may carry backported fixes without a new upstream version number, so confirm with the package maintainer that the installed build addresses both CVEs, then restart all PHP workers so that requests are served by the patched runtime. The PHP security team states that the volunteer-maintained rpms.remirepo.net repository will not carry the updates on release day.

Indicators of Compromise

On October 21st, 2026, Cloudflare indicated detecting early attacks targeting the two flaws, and Cloudflare proactively deployed web application firewall (WAF) rules for the known exploit vectors. Neither Cloudflare nor the PHP project has published atomic indicators of compromise at the time of writing.

Exploitation occurs below the application layer, so PHP exploitation attempts may not appear in application logs. Review the following sources for signs of exploitation:

• 

  Web server, reverse proxy, and WAF logs: unusual POST or multipart/form-data requests, including to endpoints that do not normally accept uploads; requests with excessive fields or headers, missing or malformed content lengths, deeply nested field names, or anomalous body sizes; references to PHP_SESSION_UPLOAD_PROGRESS where request-body inspection is available; and repeated HTTP 500 responses following such requests.

• 

  Response headers, where logged: unexpectedly large or malformed PHPSESSID response cookies, which Wiz identifies as a sign of the memory disclosure path.

• 

  PHP, PHP-FPM, and system logs: memory-limit errors, fatal errors, execution timeouts, worker crashes, unexpected restarts, out-of-memory (OOM) killer activity, and unexplained PHP worker churn, particularly when correlated with suspicious HTTP traffic.

• 

  Host and endpoint telemetry: child processes launched by PHP or web server workers, unauthorized changes to web files or scheduled tasks, unusual outbound connections, and suspicious access to credentials.

Preserve web, PHP, application, and host logs before restarting or rebuilding a suspect system. Because the memory disclosure path can expose passwords, authentication tokens, API keys, and certificates from other requests, treat secrets held by an affected PHP process as potentially exposed when these signs appear.

Technical Details

Update 1 (October 23rd, 2026) PHP has confirmed a separate vulnerability, CVE-2026-115560, in its session upload progress feature and will publish a full advisory with its next regular release. Until then, PHP recommends setting session.upload_progress.enabled=0 to fully protect against this unlikely RCE vector.

PHP states the issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration, then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. For this issue, applications that never change the serialize handler at runtime can keep the feature enabled.

On October 21, 2026, the PHP development team released a security advisory addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that could allow unauthenticated remote code execution (RCE). Wiz Research combined the flaws into an exploit chain dubbed php2shell and demonstrated unauthenticated remote code execution (RCE) against current WordPress, Drupal, and Joomla container images. Because the flaws reside in PHP itself, even basic applications running vulnerable versions may be exposed.

Both vulnerabilities stem from PHP improperly handling memory exhaustion, potentially leaving corrupted memory that subsequent HTTP requests can exploit. Apache mod_php is particularly exposed due to its persistent worker processes, while exploitability varies across other PHP configurations

The exploit chain works as follows in the Wiz example:

• 

  An attacker sends crafted multipart HTTP requests designed to trigger an out-of-memory (OOM) condition or fatal error, leaving internal PHP request state partially initialized.

• 

  PHP terminates the request and frees its memory, but certain internal pointers continue referencing the freed memory.

• 

  A subsequent request handled by the same worker accesses the stale state, potentially disclosing process memory through a PHPSESSID response cookie, or executing malicious code injected to the affected memory.

Researchers note that exploitation requires adaptation to the target's PHP version, configuration, underlying OS architecture, and memory layout, a process researchers can accellerate using frontier AI models.

CVE-2026-109618: Remote Code Execution via Out-of-Memory Corruption

This vulnerability stems from PHP's handling of OOM (Out-of-Memory) errors, when php attempts to allocate more memory than is available or limited in configuration. When memory allocation fails, PHP uses longjmp() to abort execution, potentially bypassing initialization and leaving internal request state invalid. Subsequent request shutdown operations may access this corrupted state, resulting in memory corruption and possible RCE.

Attackers can trigger these conditions through crafted multipart requests that bypass or exhaust PHP's configured resource limits. Techniques include manipulating content-length handling, supplying excessive multipart headers, abusing empty file uploads, and submitting deeply nested field names. Application-specific memory exhaustion paths may also be exploitable.

The PHP project confirmed unauthenticated RCE against Apache mod_php running standard prefork configurations. Exploit reliability depends on worker distribution, PHP extensions, memory allocation behavior, and server configuration.

The remediation replaces longjmp()-based OOM handling with a controlled shutdown mechanism, allowing PHP to terminate safely before invalid request state can be processed.

CVE-2026-109619: Remote Code Execution via Stale Global State

This vulnerability involves PHP retaining references to request-specific memory after that memory has been freed. Subsequent requests handled by the same worker can access these stale pointers before they are reset, creating use-after-free conditions that may lead to information disclosure or RCE.

Unauthenticated RCE has been demonstrated against Apache mod_php, while the session upload-progress path has also been validated against PHP-FPM under suitable application conditions. Wiz additionally demonstrated that memory disclosure alone may expose sensitive information, including credentials, session tokens, and API keys, without achieving code execution.

PHP vulnerabilities have previously been exploited in ransomware campaigns, and Beazley Security expects threat actors will rapidly weaponize these flaws to target vulnerable internet-facing PHP implementations.

How Beazley Security is responding

Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.

We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.

Appendix

The NCSC has published a GitHub repository cataloging hundreds of software products and libraries that use PHP.

The list underscores PHP’s widespread adoption and the potential reach of these vulnerabilities, spanning hundreds of popular web applications and libraries. Even the top 30 include products that power much of the internet:

• 

  WordPress

• 

  WooCommerce

• 

  Composer

• 

  Laravel

• 

  Symfony

• 

  phpMyAdmin

• 

  Drupal

• 

  Joomla

• 

  cPanel EasyApache / MultiPHP

• 

  Plesk (Linux + Windows)

• 

  Docker Official PHP images

• 

  Nextcloud Server

• 

  Nextcloud

• 

  PHPUnit

• 

  Doctrine ORM / DBAL

• 

  Twig

• 

  Monolog

• 

  Adobe Commerce / Magento

• 

  MediaWiki

• 

  Moodle

• 

  PrestaShop

• 

  Matomo On-Premise

• 

  TYPO3

• 

  Roundcube Webmail

• 

  phpBB

• 

  XAMPP

• 

  Zabbix web frontend

• 

  AWS SDK for PHP

• 

  CloudLinux Alt-PHP

• 

  Shopware 6

Sources

• 

  NVD: CVE-2026-109618

• 

  NVD: CVE-2026-109619

• 

  PHP: RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)

• 

  PHP: RCE via stale global state (GHSA-6wmf-4rv5-p3rp)

• 

  Wiz: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet

• 

  PHP Security Notification

• 

  NCSC-NL GitHub: php2shell software list