PHP Emergency Security Release: How to Respond to Two Critical RCE Vulnerabilities

1. Vulnerability Overview

On October 21, 2026, the PHP project disclosed two Critical-severity remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The security community has named the incident php2shell, reflecting its threat profile:

• Disclosure date: 2026-10-21;

• Severity: Critical;

• Attack prerequisite: No authentication required;

• Primary impact: Remote code execution.

An unauthenticated remote attacker can craft malicious HTTP requests to trigger memory errors and, under specific conditions, achieve denial of service, sensitive data theft, and remote code execution on the target server. Technical details and PoCs are already widely circulating.

2. Root-Cause Analysis

2.1 CVE-2026-109618: Memory Corruption from Premature Exit on OOM

PHP uses longjmp() to abandon a request when handling out-of-memory (OOM) exceptions. In certain contexts, however, the request's memory becomes accessible before initialization completes. If an allocation fails at that point, PHP fails to correctly handle this premature exit, leaving the request memory in an invalid state. If the subsequent request-shutdown path reads that invalid state, memory corruption occurs and can lead to remote code execution.

Officially listed trigger paths include:

• multipart requests lacking a valid Content-Length, which bypass the initial post_max_size check;

• a single part carrying an unbounded number of headers, whose in-memory footprint inside PHP significantly exceeds its on-the-wire size.

A key point: under mod_php, the request-shutdown process runs unconditionally even when request startup fails, and this stage executes before any application code. Application-level authentication therefore cannot serve as an effective defense.

2.2 CVE-2026-109619: Stale Cross-Request Global State Consumed Early

PHP worker processes retain global state — errors, sessions, objects, and extensions — that points to memory owned by a particular request and must be reset before that request's memory is freed. If a fatal error (including OOM) interrupts the reset flow, or if diagnostic information repopulates already-cleared error state during shutdown, then after the request memory is released the worker's global fields still reference that region. A subsequent request reading that stale state before normal initialization constitutes a use-after-free. An attacker can control the trigger order via carefully crafted heap layout to achieve unauthenticated remote code execution.

Two consumption paths are confirmed:

• Session upload progress: introduced in PHP 5.4 and enabled by default, this feature touches session-handling logic before normal session initialization, without the application needing to call session_start() explicitly;

• The fatal_error_backtraces mechanism: introduced in PHP 8.5.

3. Affected Scope

Affected and patched versions by branch:

• PHP 8.2: affected < 8.2.35, patched ≥ 8.2.35;

• PHP 8.3: affected < 8.3.36, patched ≥ 8.3.36;

• PHP 8.4: affected < 8.4.27, patched ≥ 8.4.27;

• PHP 8.5: affected < 8.5.12, patched ≥ 8.5.12.

Official verification by SAPI (server API):

• Apache mod_php: RCE confirmed for both vulnerabilities;

• PHP-FPM: RCE confirmed for CVE-2026-109619; CVE-2026-109618 is assessed as affected via source-code analysis;

• FrankenPHP: likely affected;

• LiteSpeed (LSAPI): not yet verified.

Businesses running an Nginx + PHP-FPM architecture are likewise affected; CMS and frameworks such as WordPress, Drupal, Magento, and Laravel may be indirectly affected.

Two points deserve special attention.

First, end-of-support branches. PHP 8.1 and earlier are past official general security support, and the PHP project is not expected to provide fixes. Some distributions and LTS providers may backport patches — confirm with your vendor proactively. Environments still running PHP 5.x, 7.x, or 8.0/8.1 should migrate to a supported PHP 8 branch as soon as possible, or be taken offline or network-isolated.

Second, containerized deployments. Containerization is an easily overlooked area in triage. Version consistency across Docker PHP-FPM images and environments, as well as whether scaling pulls stale images, must all be included in the audit scope.

4. Remediation Recommendations

4.1 Upgrade to a Patched Version (the Only Complete Fix)

The PHP project explicitly states that upgrading to a patched version is the only complete fix. Evaluate business impact promptly and upgrade to the patched versions listed above. When using PHP provided by a distribution, container image, or managed service, apply a security update the vendor explicitly marks as fixing the relevant CVEs.

Before upgrading, complete backups and compatibility validation; after upgrading, restart all PHP worker processes and confirm that the processes serving web traffic have loaded the patched version. For containerized deployments, update images and replace old instances in sync.

4.2 Temporary Mitigations (Not a Substitute for Upgrade)

For CVE-2026-109618:

• Force memory_limit=-1 at the administrator level and confirm that process-pool, directory, or application configuration does not restore a finite memory cap. This removes the predictable per-request memory ceiling but is incomplete — low-level allocation failures such as mmap() may still enter the risk path;

• At the web server or reverse proxy, limit the decoded request body size, the number of input variables, the number of multipart parts, the number of headers per part, and the number of uploaded files. The limits should cover requests lacking a valid Content-Length;

• Lower max_input_nesting_level; businesses that do not use multipart forms can block such requests directly at the front end.

Note: do not use RLIMIT_AS or RLIMIT_DATA as a substitute control — once the limit is reached, mmap() failure triggers the risk path.

For CVE-2026-109619:

• Set session.upload_progress.enabled=0; on PHP 8.5, additionally set fatal_error_backtraces=0;

• If performance permits, set pm.max_requests=1 to break cross-request state reuse;

• Eliminate reachable fatal errors in attack-accessible paths, including uploads, imports, error pages, destructors, serialization, output handling, and plugin/extension layers.

4.3 Reduce Exposure and Strengthen Monitoring

Exposure reduction:

• Inventory all PHP hosts and container instances serving external traffic and establish a version ledger, prioritizing internet-facing web services;

• Tighten access control on internet-exposed PHP systems, and converge unnecessary externally reachable interfaces and debug endpoints;

• Run PHP service processes under the principle of least privilege.

Behavior monitoring: Strengthen web-server log and host-behavior monitoring, focusing on abnormal child processes spawned by web processes, unexpected file writes, and suspicious outbound connections. Based on known exploitation behavior, typical indicators include:

• php-fpm, httpd, or other worker processes spawning shell or network-tool child processes;

• command lines containing reverse-shell patterns such as /dev/tcp/, fsockopen, or mkfifo;

• reconnaissance commands such as whoami or id.

Note that the configurations above are targeted mitigations for confirmed attack paths; the PHP project has stated that no complete generic configuration mitigation exists for CVE-2026-109619. All configurations must take effect before request parsing (do not rely on ini_set() or .user.ini) and require restarting all PHP worker processes.

5. Detection Capabilities of Our Security Products

For this vulnerability incident, our security products already provide the following detection and protection capabilities:

• Vulnerability detection: the security platform supports scanning for these CVEs, locating affected assets, and outputting remediation advice;

• Asset inventory: continuous discovery of internet-exposed domains, IPs, and port services via traffic-probe mirroring, supporting PHP asset-ledger buildout;

• Behavior monitoring: recognition of exploitation indicators such as abnormally spawned child processes from web processes, suspicious outbound connections, and anomalous file writes; alerts are de-noised through AI-graded triage and can be linked to firewalls for blocking;

• Expert support: cloud security experts and a dedicated service channel provide remote assistance for triage, remediation, and incident response.

It should be emphasized that tooling cannot replace patching. Users should treat upgrading to a patched version as the primary action while carrying out asset triage and behavior monitoring in parallel, forming a "remediate + monitor" response loop.

6. Conclusion

What makes php2shell distinctive is that the affected component is the PHP runtime itself, not an optional dependency — any request path that reaches the interpreter is potentially exploitable under specific conditions. Before patches were available, enterprises could not easily build precise detection signatures. We recommend proceeding in the following order:

1. Complete asset inventory and version-ledger buildout first, prioritizing internet-exposed web services;

2. Upgrade to patched versions as soon as possible and restart all PHP worker processes;

3. Maintain continuous monitoring of abnormal web-process behavior and suspicious outbound connections throughout.

If you need help deploying these detection capabilities or assistance with asset triage and remediation, please contact us.

---

References

1. PHP official security advisory (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

2. PHP official security advisory (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

3. PHP official release archive: https://www.php.net/archive/2026.php