JRLENZ.COM

Understanding "PHP2Shell": Deep Dive Into the Critical PHP RCE Flaws (CVE-2026-109618 & CVE-2026-109619)

With PHP powering up to 70% of the Web, this is arguably the most sweeping vulnerability disclosure of all time. Patch your systems now.

  • Cybersecurity
  • Security
  • PHP
  • DevOps
  • Patch
  • Zero-day

If you manage web infrastructure, you’ve likely spent the last 48 hours rushing to patch systems or reading alerts. Publicly disclosed in October 2026, PHP2Shell is a pair of critical, unauthenticated Remote Code Execution (RCE) vulnerabilities residing in the PHP core runtime. Affecting a vast array of PHP versions across the 5.4 to 8.5 range, these bugs have put a massive percentage of web infrastructure on high alert.

Here is a breakdown of what PHP2Shell is, how it works under the hood, and what defenders need to do right now.

What is PHP2Shell?

PHP2Shell is the collective moniker given to CVE-2026-109618 and CVE-2026-109619. Assigned a severe CVSS v4.0 score of 9.2 by the PHP development team (with some security firms rating it a full 10.0), these vulnerabilities allow an unauthenticated remote attacker to execute arbitrary code on a vulnerable server.

The flaws were originally uncovered during a security audit of PHP's source code by researchers at Calif utilizing advanced AI-assisted analysis tools, with independent discovery and exploit development soon following from Google’s Wiz security team and other researchers. Unfortunately, details and early exploit primitives leaked prematurely, leading to active scanning and exploitation in the wild by threat actors.

Technical Deep Dive: Under the Hood

Both vulnerabilities deal with edge-case memory handling anomalies and abnormal request terminations within the PHP engine.

1. CVE-2026-109618: RCE via Out-Of-Memory (OOM) Corruption

This vulnerability stems from how PHP manages memory allocation failures during complex request parsing (such as heavily nested arrays or massive multipart data inputs).

  • When a script triggers an allocation error or exhausts its allowed memory limit, PHP initiates a cleanup sequence using longjmp to abort the current execution flow.

  • Under specific conditions, internal pointers and structural references are left in an inconsistent state during this abrupt tear-down.

  • An attacker who carefully crafts malformed serialized payloads or massive POST requests can induce a predictable memory corruption state, eventually gaining control over instruction pointers or manipulating internal type structures to achieve arbitrary code execution.

2. CVE-2026-109619: RCE via Stale Global State

This bug involves request-owned internal states surviving past their lifecycle.

  • Certain persistent or global handlers (such as session tracking mechanisms like session.upload_progress) retain references to internal memory structures across request boundaries.

  • If a request terminates abnormally or leaves behind dangling references, a subsequent request handled by the same persistent worker process (common in environments using PHP-FPM) may inadvertently interact with that stale, freed state before normal initialization routines reset it.

  • By manipulating these race conditions, attackers can trigger use-after-free scenarios, corrupting memory to smuggle and execute arbitrary payloads.

Immediate Remediation Steps

The PHP security team rolled out emergency patches shortly after disclosure. If you haven't updated your environments yet, this should be your absolute top priority.

  1. Update PHP Core Immediately: Upgrade your installations to the patched versions released by the PHP project:

    • PHP 8.5: Update to 8.5.12

    • PHP 8.4: Update to 8.4.27

    • PHP 8.3: Update to 8.3.36

    • PHP 8.2: Update to 8.2.35

    (Note: Check your specific Linux distribution, container base images, or cloud hosting provider for backported packages if you rely on OS-managed runtimes.)

  2. Apply Temporary Mitigations (If Patching is Delayed):

    • If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

      RCE via OOM corruption (CVE-2026-109618):

      • Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.

      • Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.

      • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

      RCE via stale global state (CVE-2026-109619):

      • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.

      • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.

      • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.

      • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.



      Hunt for Indicators of Compromise (IoCs): Review your web server, PHP-FPM, and application error logs for recurring "allowed memory size exhausted" fatal errors paired with abnormal worker segfaults, sudden process recycling spikes, or anomalous PHPSESSID cookie values. Inspect your web roots for newly dropped .php files or unexpected shell spawns.

Sources & Further Reading

All articles