.avif)
%201.svg){kind=small}
On October 21, 2026, the PHP project patched PHP2Shell: two critical remote code execution (RCE) vulnerabilities in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619. Both score 9.2 on CVSS v4.0, need no privileges or user interaction, and put web-serving PHP installations at risk regardless of the CMS or plugins running on top. The first exploitation attempt was observed four days before the fix was released.
Below: how the flaws work, which PHP versions fix them, what to look for in your environment, and what to do about the credentials a PHP worker could reach before the patch.
What is PHP2Shell?
PHP2Shell refers to two critical vulnerabilities in the PHP runtime that can enable unauthenticated remote code execution (RCE). Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws stem from memory-safety failures involving out-of-memory conditions, fatal-error handling, and internal state that can remain inconsistent after request processing is interrupted.
Wiz Research, Calif, and OpenAI reported the vulnerabilities to the PHP security team (Calif and OpenAI on August 11, Wiz on August 24). Their research demonstrated unauthenticated RCE against WordPress, Drupal, and Joomla, along with disclosure of sensitive PHP worker memory. These applications illustrate the impact, but the vulnerabilities reside in PHP itself, not in any particular CMS or plugin.
The PHP project released security fixes on October 21, 2026. Both vulnerabilities carry a CVSS v4.0 base score of 9.2 (Critical). The fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP states that updating is the only complete remediation.
Exploitation did not wait for disclosure. Amazon Threat Intelligence identified an exploitation attempt against its MadPot honeypot on October 17. This establishes pre-disclosure activity, but does not prove that every targeted system, or any particular production system, was successfully compromised. After the October 21 release, Amazon, Cloudflare, and watchTowr reported further exploitation attempts.
What security teams should do now:
- Inventory exposed PHP runtimes.
- Deploy and verify the appropriate security updates.
- Investigate potentially compromised systems where exposure or suspicious activity warrants it.
Patching closes the known vulnerability path. It does not remove persistence or reverse credential theft that may already have occurred.
CVE-2026-109618 and CVE-2026-109619 at a glance
PHP2Shell root cause: where PHP's memory handling breaks
PHP2Shell encompasses multiple memory-safety defects grouped under two CVE identifiers. The common failure pattern involves how PHP handles exceptional conditions and request-owned memory. When an operation terminates unexpectedly, internal state may retain references to memory that has been released or was never fully initialized.
CVE-2026-109618: Out-of-Memory Corruption
PHP uses internal error-handling mechanisms to abort request processing when an out-of-memory (OOM) condition occurs. In vulnerable execution paths, an allocation failure can interrupt processing while request data is only partially initialized. Subsequent cleanup may then interpret invalid state as valid.
Certain multipart request patterns can reach the vulnerable condition within the configured PHP limits. The resulting memory-safety failure can enable corruption and remote code execution.
Wiz also demonstrated unauthenticated disclosure of PHP worker memory. This is where the risk extends beyond the server itself: depending on the application's workload, process memory may contain authentication tokens, API keys, credentials, or other sensitive information. Wiz attributes the memory disclosure to CVE-2026-109618, while PHP's advisory for CVE-2026-109619 also lists memory disclosure among its confirmed impacts, so the CVE-level mapping differs between sources.
The official PHP advisory confirms unauthenticated RCE in mod_php with default PHP input and memory limits. It also identifies PHP-FPM as susceptible in some conditions, although a complete FPM exploit for this particular CVE was not demonstrated in the advisory.
CVE-2026-109619: Use-After-Free and Stale Global State
PHP workers retain internal state across requests. That state must be reset before the memory belonging to a completed request is released. If an exceptional condition interrupts the reset process, a later request handled by the same worker may encounter a stale reference before normal initialization replaces it.
This is a use-after-free condition: the runtime attempts to use memory after the associated allocation has been released.
The research also describes an OPcache-related type-confusion issue, in which inconsistent internal state can cause a memory reference to be interpreted as an unexpected type. Together, these defects create primitives that can be chained into remote code execution under the relevant conditions. PHP's advisory confirms RCE through two paths: the PHP 8.5 fatal-error backtrace path against mod_php, and a session upload-progress path against both mod_php and PHP-FPM.
The attack depends on a vulnerable state-producing operation and a subsequent operation that consumes that state. The exact requirements differ according to the internal state involved and the deployment configuration.
How the two CVEs differ
CVE-2026-109618 centers on out-of-memory handling and invalid request state during cleanup. CVE-2026-109619 concerns stale internal state that can survive between requests, including fatal-error and OPcache-related paths.
Both can lead to RCE, but their exploit prerequisites and demonstrated execution paths are not identical. Security teams should assess both advisories rather than assuming that a control addressing one attack path fully addresses the other.
PHP2Shell timeline: exploitation attempts began before disclosure
Why October 17 matters
The October 17 observation predates public disclosure, which means attackers were probing before defenders had a patch. However, a honeypot exploitation attempt does not by itself establish a successful compromise of a production system.
After disclosure, publicly available technical details and proof-of-concept material lowered the barrier to opportunistic scanning. Organizations should investigate activity from before disclosure as well as the period following the patch release.
A separate advisory: CVE-2026-115560
CVE-2026-115560 is a separate issue and should not be conflated with the two original PHP2Shell CVEs. It requires an application to set session.serialize_handler to php_binary or php_serialize and then switch it to php at runtime with ini_set() before session_start(), a setup PHP considers unlikely in practice. PHP's October 23 guidance recommends setting session.upload_progress.enabled=0 until the relevant regular bug-fix release for the specific configuration described in that advisory.
Affected PHP versions and fixed releases
The PHP project released the following fixed upstream versions on October 21, 2026.
PHP identifies web-serving installations as being at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Its advisory considers mod_php particularly high risk because a demonstrated attack can occur before application code runs.
Older branches need special attention. PHP 8.1 and earlier no longer receive official releases from the PHP project, but the PHP security team published minimal source-only backports (no binaries) for 7.4, 8.0, and 8.1. Some distributions and long-term support vendors provide backported security fixes. Administrators should verify the actual package and vendor advisory rather than relying only on the upstream version number.
Where to look
- Internet-facing PHP applications and virtual hosts.
- WordPress, Drupal, Joomla, and custom PHP applications.
- PHP-FPM pools and Apache mod_php installations.
- Container images, virtual machines, and embedded runtimes.
- Administrative services and applications that package their own PHP runtime.
A common blind spot: updating a CMS or its plugins does not fix a vulnerability in the PHP engine. Each deployed runtime must be identified and independently verified.
PHP2Shell impact and detection signals
A successful PHP2Shell exploit can allow code execution under the privileges of the affected PHP worker. That makes the worker's access the real blast radius: depending on the deployment, accessible resources may include application files, database credentials, API keys, and other secrets.
Excessive filesystem permissions, weak container isolation, and broad network access can increase the consequences. Potential follow-on activity includes unauthorized file modifications, web shell deployment, credential misuse, and access to connected systems. These are possible consequences of RCE, not proof that every PHP2Shell incident involved them.
Detection signals
Investigators should correlate web server, PHP, endpoint, and network telemetry. Useful investigative leads include:
- Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
- Unexpectedly large or malformed PHPSESSID response cookies.
- Unexplained PHP worker crashes, restarts, or churn.
- PHP workers spawning unexpected child processes.
- Unexpected file modifications in application or web-accessible directories.
- Unusual outbound connections or suspicious use of application credentials.
These signals are not definitive PHP2Shell signatures. Legitimate uploads and application failures can produce similar events, so findings should be validated against process, filesystem, and network evidence.
Clean logs are not a clean bill of health. Memory disclosure may leave different evidence from code execution, and application logs may not capture activity occurring before normal application initialization.
How to remediate PHP2Shell
Patch, then verify what is actually serving
Installing the applicable fixed release or a verified vendor backport is the primary remediation. PHP states that updating is the only complete fix for the two original vulnerabilities.
- Inventory all PHP runtimes and serving configurations.
- Apply the appropriate fixed release or vendor-supported security package.
- Restart or reload relevant services where required.
- Verify the PHP runtime actually serving requests, not just the command-line version.
- Validate container images and deployment artifacts to prevent vulnerable versions from being redeployed.
Treat temporary controls as a bridge, not a fix
Where patching cannot happen immediately, the official PHP advisories describe configuration-specific measures that can reduce exposure to certain attack paths. These measures are incomplete and should not be treated as equivalent to patching.
For CVE-2026-109618, the advisory recommends setting and enforcing memory_limit=-1 administratively (for example through php_admin_value) and restarting all workers, along with conservative request-size and multipart-processing limits. This is not a complete mitigation, because an underlying allocation failure can still reach the vulnerable path. These changes require careful evaluation, because removing the memory limit lets a single request consume all available memory, which can affect availability.
For CVE-2026-109619, disabling session upload progress and restarting workers blocks confirmed session-related paths. PHP 8.5 also provides a setting (fatal_error_backtraces=0) that removes the producer used in the confirmed fatal-backtrace RCE. PHP states there is no complete generic configuration mitigation for this CVE.
Follow the full official PHP advisory for exact configuration requirements. Temporary controls should not delay patch deployment.
Assume exposure until the evidence says otherwise
Patching alone does not establish that a previously exposed server is clean. Preserve relevant logs and endpoint telemetry, investigate anomalous processes and file changes, and assess whether secrets accessible to the PHP worker may have been exposed.
Rotate affected credentials and revoke tokens where warranted. If system integrity cannot be established, contain the host and consider rebuilding from trusted sources. Validate the patched runtime and monitor for recurring suspicious activity.
The runtime is the attack surface
PHP2Shell shows how memory-safety failures in a widely deployed runtime can expose applications even when their own code contains no directly vulnerable component. CVE-2026-109618 and CVE-2026-109619 can enable unauthenticated remote code execution, with the first vulnerability also supporting disclosure of sensitive PHP worker memory.
The immediate priorities are to identify vulnerable PHP installations, apply the correct security updates, verify the runtime actually serving requests, and investigate systems that may have been exposed before patching. Temporary configuration changes can reduce certain risks but do not replace the official fixes.
For security teams, effective remediation means more than closing a vulnerability ticket. It requires verified patch deployment, proportionate forensic investigation, protection of potentially exposed credentials, and controls that limit the impact of future runtime vulnerabilities.
Where identity governance fits
A PHP worker that was exposed before patching may have had access to database credentials, API keys, and tokens. Each of those belongs to an identity, often a service account or other non-human identity. Once the patch is in, the question that remains is what those identities can still access.
Unosecur is an identity security platform built around a Unified Identity Fabric. It gives security and identity teams runtime visibility into human and non-human identities across multi-cloud, SaaS, identity provider, and on-prem environments.
For teams responding to PHP2Shell, that visibility answers the post-patch question directly. It shows what the identities behind potentially exposed credentials can reach, including excessive privileges and risky access combinations, so you can prioritize which credentials to rotate first and which access to restrict. It complements patching and forensic investigation and does not replace them.
A patch closes the way in. It cannot tell you what the credentials that already left can open. The identity layer has to.
Talk to the Unosecur team about an identity security assessment across your human and non-human identities.
%201.svg){kind=small}
.webp)
.avif)
.webp)
