Critical Security Advisory: PHP2Shell RCE Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)

Executive Summary & Overview

CVSS 4.0: 9.2 / Critical. PHP2Shell covers two groups of memory-safety flaws in PHP itself. Upgrade to a patched runtime even if your application and framework are already up to date.

PHP uses fatal-error handling in the Zend engine to abandon a request. Some paths use zend_bailout() and longjmp() without the normal stack and state unwinding. Incomplete initialization or cleanup can leave memory in an unsafe state, allowing unauthenticated remote code execution (RCE) or disclosure of sensitive process memory.

CVE-2026-109618: Out-of-memory corruption

An out-of-memory (OOM) interruption can leave partially initialized request data reachable. Request shutdown may then read or branch on invalid memory. The failed allocation need not be directly related to that data.

CVE-2026-109619: Stale global state

Worker-global references can outlive the request memory they point to. A later request reaching the same worker can consume that freed memory before normal initialization, creating a use-after-free condition.

Exposure depends on the server interface, build, extensions, configuration, and request lifecycle. The PHP advisories confirm RCE against Apache mod_php, including paths before application code runs, and session-lifecycle RCE against PHP-FPM. Other paths, including OOM-related FPM exposure and FrankenPHP or LiteSpeed LSAPI susceptibility, are qualified by source analysis rather than a complete demonstrated exploit. Do not assume identical exploitability across every deployment.

Researchers report that versions dating back to PHP 5.4 are affected by at least one of these issues. The published CVE records specify the affected supported branches below. This is a runtime issue, not a flaw limited to WordPress, Drupal, Laravel, or any one application.

Affected Versions Matrix

Install at least the patched release for your branch, or a newer supported release. On small screens, scroll the table horizontally to see every column.

Legacy PHP 5.x, 7.x, 8.0, and 8.1 installations need a supported-branch migration. If you depend on Linux vendor extended support, verify that your exact package includes fixes for both CVEs; do not infer protection from a package version alone. A verified vendor backport may retain an older version number.

Mitigation & Immediate Action Plan

Patch first: the only complete mitigation

1. Inventory your fleet. Identify public and internal PHP web workers, embedded runtimes, container images, and deployment pipelines. Record the branch, package provider, server interface, and effective configuration.
2. Upgrade the runtime. Install a patched release from your trusted package provider. Rebuild container images from verified patched base images, then redeploy every instance. Check managed-platform notices rather than assuming your PaaS has updated your runtime automatically.
3. Roll out and verify. Test application compatibility and critical flows, use a staged rollout with a rollback plan, and restart or replace every PHP worker. Verify the runtime and vendor patch status actually serving requests, not only the CLI binary or build image.

Temporary workarounds when patching is delayed

These measures reduce specific attack paths only. They do not make an unpatched runtime safe. Review capacity and application impact before changing production configuration.

• OOM handling: the PHP advisory recommends administratively enforcing memory_limit=-1 as a temporary measure against predictable per-request OOM. Restart every worker and ensure pool, directory, or application overrides cannot restore a finite limit. Removing PHP's memory cap increases resource-exhaustion and availability risk; underlying allocations can still fail.
• Bound memory externally: container or cgroup memory.max limits may provide an alternative boundary, but cannot guarantee allocation success or eliminate RCE. A cgroup OOM kill may terminate the master and all workers unless workers are isolated. Size and test limits carefully. Do not substitute RLIMIT_AS or RLIMIT_DATA: they can cause allocation failures that trigger the vulnerable path.
• Stale-state paths: administratively disable session upload progress; on PHP 8.5, also disable fatal-error backtraces. Restart every worker after applying these settings. They address specific demonstrated paths, not all global or extension state.

; Startup php.ini configuration; restart every worker
session.upload_progress.enabled = 0

; PHP 8.5 only
fatal_error_backtraces = 0

• Reduce request pressure. Keep post_max_size conservative and independently enforce decoded body-size limits at the proxy or WAF. Bound input nesting, input variables, multipart parts and headers, and uploads. Block multipart requests before PHP if the application does not need them. WAF rules are defense-in-depth, not a replacement for patches.
• Audit and monitor. Review startup and cleanup warnings, fatal errors, OOM events, worker crashes, and anomalous multipart traffic. Fix configuration and application error paths, and confirm logging works. Quiet logs do not prove that a worker is safe or uncompromised.

Sources & further guidance

• PHP vendor advisory: OOM corruption (CVE-2026-109618)
• PHP vendor advisory: stale global state (CVE-2026-109619)
• CVE-2026-109618 record and CVE-2026-109619 record
• Wiz Research: PHP2Shell overview and historical exposure