• Severity: CVSS v4.0 9.2 (Critical) for each CVE
  • Affected: PHP 5.4 onward, including unpatched 8.2–8.5 installations; exposure depends on runtime and configuration
  • Patched: October 21, 2026 (PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) · Exploitation: Working researcher exploits demonstrated; Unit 42 reports in-the-wild activity

Introduction

Hey everyone, it’s been a while. Some projects have kept us busy, and vulnerability deep dives took a back seat for a couple of months. But when two bugs in PHP itself start making headlines for unauthenticated remote code execution, well, that is one way to get us back to the keyboard ;D

PHP2Shell: CVE-2026-109618 and CVE-2026-109619, two critical memory-safety vulnerabilities fixed by the PHP project on October 21, 2026. Both carry a 9.2 CVSS v4.0 score and involve unsafe memory handling around request failures or cleanup. Their weakness classes include CWE-416 (Use After Free) and CWE-755 (Improper Handling of Exceptional Conditions).

And here’s where things get interesting: the vulnerable code paths can be traced back to PHP 5.4.0, released on March 1, 2012. That’s more than 14 years of potentially exploitable code hiding inside one of the web’s most widely used programming languages. PHP has gone through multiple major releases since then, yet these underlying memory-handling problems survived.

This is not a WordPress plugin bug. The vulnerable component is the PHP runtime underneath applications such as WordPress, Drupal and Joomla. A site without a vulnerable PHP runtime, or one using a verified patched vendor build, is not exposed to these specific PHP flaws. Conversely, upgrading a CMS alone will not fix an unpatched PHP engine.

Attribution note: Wiz Research discovered and demonstrated the vulnerabilities and worked with the PHP team on coordinated disclosure. Our breakdown draws on their original research and the PHP project’s advisories.

What Happened?

PHP is supposed to release request-owned memory cleanly, then begin the next request with a fresh internal state. These two bugs show what happens when that assumption falls apart.

CVE-2026-109618 - RCE via out-of-memory corruption. PHP uses longjmp() to abort certain operations when memory allocation fails. If that interruption occurs while internal request data is only partly initialized, cleanup may treat invalid data as legitimate. The result can be memory corruption and, under exploitable conditions, remote code execution. The PHP advisory confirms RCE against Apache mod_php with default input and memory limits.

CVE-2026-109619 - RCE via stale global state. A PHP worker may keep a global reference to memory owned by a request. If an error interrupts cleanup, or a late diagnostic repopulates state after it was cleared, the request memory can be freed while the reference survives. A later request handled by the same worker can use that dangling reference before normal initialization resets it: a classic use-after-free. Researchers validated RCE in mod_php and a conditional PHP-FPM scenario.

Wiz also demonstrated process-memory disclosure through related vulnerable paths. Their tests achieved unauthenticated RCE against representative WordPress, Drupal and Joomla deployments; these are examples, not prerequisites. See the 109618 advisory and 109619 advisory.

A perfectly ordinary-looking web request should not get to rearrange your PHP worker’s memory. Yet here we are.

Attack Sequence

For CVE-2026-109618, an attacker targets an accessible PHP request-processing path and induces a memory-allocation failure at a sensitive moment. PHP exits through its out-of-memory handling, but part of the request state remains invalid. Shutdown then encounters that state, potentially turning a failed request into memory corruption and code execution. The exact reliability depends on the PHP build, modules, allocator and frontend handling.

CVE-2026-109619 involves a different failure across request boundaries. An initial operation leaves request-owned state accessible from worker globals. The original request ends, its memory is released, and the worker survives. When a later request reaches the matching operation before the state is reset, PHP touches a reference to freed memory. Exploitation requires a reachable producer, a consumer, and worker reuse; PHP-FPM exposure varies with application and configuration.

The diagram below is a memory-state lifecycle, not a ready-made exploit recipe. It illustrates why worker reuse matters to CVE-2026-109619.

CVE-2026-109619 memory-state lifecycle

Fig 1: The dangling-reference lifecycle across PHP requests. Mermaid source is supplied separately.

Why This Is Especially Dangerous

  • No authentication is needed for the demonstrated vulnerable routes. The bug lives below the application’s login logic.
  • Remote code execution happens with PHP worker privileges, potentially exposing application files, environment secrets and database credentials.
  • Memory disclosure is also possible, including data from PHP worker memory that an application never intended to return.
  • It is not limited to one CMS. Every PHP-backed deployment must be assessed at the runtime level.
  • Internet-facing Apache mod_php deserves immediate attention. PHP identifies it as the highest-risk setup, although PHP-FPM and other SAPIs cannot be assumed safe.

And this is not only a lab concern: Palo Alto Networks Unit 42 reports having seen exploitation in the wild and identified over 22.6 million potentially vulnerable exposed instances in its telemetry. That exposure estimate does not mean 22.6 million systems were compromised.

Affected Versions

The PHP project released the following upstream fixes on October 21, 2026:

BranchVulnerable VersionsFix Available
PHP 8.58.5.0–8.5.118.5.12
PHP 8.4Earlier than 8.4.278.4.27
PHP 8.3Earlier than 8.3.368.3.36
PHP 8.2Earlier than 8.2.358.2.35
PHP 5.4-8.1Older, affected releases; no new upstream PHP security releaseUpgrade or obtain a verified vendor backport

Not affected: installations running these fixed versions or a vendor package confirmed to contain both backported patches. Systems that do not run PHP are not affected by these PHP-runtime flaws. PHP versions before 5.4 were not established as safe by the research; don’t treat an older version string as proof of immunity.

Some Linux distributions and hosts backport fixes without changing the upstream-looking version number. Follow your operating-system or hosting provider’s security bulletin, not just php -v. For example, Ubuntu has published updated packages, while cPanel lists patched cPanel/WHM and EasyApache4 releases.

PHP2Shell remediation decision tree

Fig 2: A patch decision tree for upstream PHP, vendor backports and unsupported branches. Mermaid source is supplied separately.

Mitigations

1. Patch the PHP runtime immediately.

Deploy 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a verified distributor/hosting-vendor build fixing both CVEs. Prioritize public-facing deployments. PHP explicitly states that there is no complete configuration-only mitigation.

2. Inventory the PHP your web server actually runs.

php -v
php --ini
php-fpm -v   # If PHP-FPM is installed; the binary name may vary

The CLI version can differ from the runtime serving HTTP requests. Check FPM pool configuration, Apache modules, containers, managed hosting and embedded PHP installations. Rebuild and redeploy application container images when their PHP base image changes.

3. Restart or redeploy workers after updating.

A package update is not enough if old PHP processes remain alive. Restart the applicable Apache or PHP-FPM service, or replace application pods/containers, then verify the web-serving runtime is patched.

For cPanel/WHM with EasyApache4, the vendor documents this update command:

sudo /scripts/rpmup

4. Reduce exposure if patching is blocked.

Temporarily restrict access to affected applications or take them offline. For CVE-2026-109619, disabling session.upload_progress.enabled (if unused) and restarting all workers removes one demonstrated route, not the whole vulnerability. The PHP advisory also documents limited, configuration-specific steps for fatal_error_backtraces and early INI diagnostics. Do not mistake these for a full fix.

For CVE-2026-109618, the official advisory describes memory_limit=-1 as a partial mitigation for predictable PHP-level OOM triggers, but warns that underlying allocation failures can still reach the vulnerable path. Do not apply memory-limit changes casually on shared production infrastructure; favor patching or isolation.

Indicators of Compromise

As of October 22, 2026, 2:30 AM UTC, the primary advisories reviewed here do not supply a validated universal list of attacker IPs, domains or file hashes. Unit 42’s reported in-the-wild exploitation makes behavioral investigation important, but these signals are hunting leads, not proof of PHP2Shell compromise.

On the server: Look for PHP/Apache worker processes launching unexpected shells, download utilities or interpreters; unfamiliar scripts or scheduled tasks; unexplained PHP child-process crashes and abnormal fatal errors.

In HTTP and traffic logs: Look for unusual multipart uploads, bursts of failed or oversized requests, repeated 5xx responses followed by successful requests, and unexpected outbound connections originating from web-server processes.

Configuration integrity: Check for unexpected edits to PHP INI files, Apache .htaccess files, PHP-FPM pools, upload-related settings, newly added extensions, and changes in web-root files or service accounts.

Review Apache, PHP-FPM, reverse-proxy and EDR telemetry together. PHP warns that some relevant state transitions produce no reliable log entry, so clean-looking logs do not prove a host was never exposed. Recheck the PHP advisories and Unit 42’s threat brief for later indicators.

Final Thoughts

PHP2Shell is a good reminder that a secure application cannot outrun an insecure runtime. You can update every WordPress plugin, lock down your admin panel and put a WAF in front of the site, but none of that repairs a use-after-free inside PHP itself.

Wiz’s AI-assisted discovery is also worth watching: these bugs lived deep in a mature codebase, and the research shows how quickly complex memory-safety findings can become practical exploit demonstrations.

Patch the engine. Verify the workers. Hunt for signs of abuse. We may have been away from the blog for a while, but this is definitely not the kind of comeback story we wanted PHP to write :/

References