PHP2Shell: Inside Two Critical PHP Core Vulnerabilities That Enable Unauthenticated RCE

Understanding CVE-2026-109618 and CVE-2026-109619, the memory-management failures behind them, and what defenders should do now.

On October 21, 2026, the PHP development team disclosed two critical vulnerabilities in PHP core: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS score of 9.2 and can potentially allow unauthenticated remote code execution (RCE).

What makes these vulnerabilities especially concerning is that they affect PHP's internal request-processing and memory-management mechanisms. Under the right conditions, an attacker may trigger the flaws through HTTP requests before application-level code executes.

This is not simply another vulnerable plugin or an application-level coding mistake. The issue lies deeper in the PHP runtime itself.

In this article, we'll examine the underlying concepts, the differences between the two vulnerabilities, the potential impact, and practical defensive measures.

What is PHP2Shell?

PHP2Shell is the name used in OffSec's technical coverage of these vulnerabilities.

The two CVEs share a broad theme: PHP can mishandle memory or internal state when an operation is interrupted, leaving data in an inconsistent condition. A subsequent cleanup operation or request may then interact with memory that is no longer valid.

The result can include memory corruption, memory disclosure, and, under demonstrated conditions, remote code execution.

According to the official PHP security advisories, the affected version ranges include releases before:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

These are the corresponding patched releases for the supported branches listed in the advisories. Older end-of-life branches require special attention because fixes may depend on the distribution or vendor.

Important: A PHP version number alone does not tell the whole story for vendor-maintained packages. Verify the package's security status with your operating-system or hosting provider.

Understanding the Root Cause

Before examining each CVE, two memory-safety concepts are worth understanding.

1. Use-after-free

A use-after-free occurs when software continues to access memory after that memory has been released.

Imagine a PHP worker handling an HTTP request. During processing, it allocates memory and stores a pointer to that memory in an internal structure. When the request finishes, the memory is freed.

If another internal structure still holds the old pointer, it may refer to memory that has been released or repurposed.

The dangerous part is that the program may still treat this pointer as valid. Depending on how the memory is subsequently used, the outcome can range from a crash to memory corruption or code execution.

2. Out-of-memory handling

An out-of-memory (OOM) condition occurs when a program cannot allocate the memory it needs.

PHP uses internal mechanisms, including longjmp(), to interrupt execution in certain error situations. If an interruption happens while an internal data structure is only partially initialized, the normal cleanup process may encounter inconsistent state.

In other words, an error-handling mechanism intended to stop a failing operation can expose a memory-safety problem if the surrounding code does not correctly account for the interruption.

That is the central theme behind the two vulnerabilities.

CVE-2026-109618: RCE Through OOM Memory Corruption

The first vulnerability concerns memory corruption associated with PHP's out-of-memory handling.

The official PHP advisory describes a problem in which request memory can be left in an invalid state if allocation fails while PHP is processing data that has not yet been fully initialized.

The shutdown or cleanup process can subsequently interact with that inconsistent data.

OffSec's analysis discusses how malformed multipart HTTP requests can contribute to an OOM condition. Multipart requests are commonly used for form submissions and file uploads, so the issue is particularly relevant to PHP deployments that process HTTP request bodies.

At a high level, the sequence is:

1. PHP begins processing an incoming request.
2. An allocation failure interrupts an operation while internal request data is in an incomplete state.
3. PHP's cleanup logic encounters inconsistent memory or bookkeeping information.
4. The resulting memory corruption may be exploitable.

The security impact is potentially severe because the demonstrated attack can progress to remote code execution without authentication.

This does not mean every PHP application is automatically exploitable in an identical way. Runtime version, deployment architecture, memory behavior, and request-processing details can influence exploitability.

Severity: Critical
CVSS: 9.2
Primary issue: Memory corruption during OOM handling
Potential impact: Unauthenticated remote code execution

Official advisory: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

CVE-2026-109619: RCE Through Stale Global State

The second vulnerability involves stale internal state that persists across request boundaries.

PHP workers can retain certain internal structures between requests. However, data owned by one request must not remain accessible after the memory associated with that request has been released.

If PHP fails to reset a reference before freeing its underlying memory, a later operation may access that stale reference.

The critical sequence is:

1. An operation stores request-specific information in internal state.
2. An error or another interruption prevents the expected reset from completing.
3. PHP releases the request's memory while a persistent reference remains.
4. A subsequent request reaches an operation that uses the stale state.
5. Under exploitable conditions, the resulting use-after-free can lead to memory corruption and remote code execution.

The PHP advisory describes several possible sources of stale state, including error handling, session-related operations, and other internal processing paths.

One important detail is that the producing operation and the later consuming operation may occur in separate HTTP requests handled by the same worker. Consequently, worker lifecycle and request handling can affect whether a particular attack path is reachable.

This is why investigating the runtime and server configuration matters. A generic claim that every PHP deployment has the same exploitability would be inaccurate.

Severity: Critical
CVSS: 9.2
Primary issue: Use-after-free involving stale global state
Potential impact: Unauthenticated remote code execution under demonstrated conditions

Official advisory: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

Why These Vulnerabilities Matter

Remote code execution can turn a vulnerable web-facing service into an entry point for a wider compromise.

Depending on the privileges of the PHP worker and the surrounding environment, a successful attacker might be able to:

• Execute commands with the privileges of the affected service account.
• Read sensitive application files accessible to that account.
• Access application configuration and credentials.
• Interact with databases or internal services reachable from the server.
• Attempt privilege escalation or lateral movement.

These are potential consequences, not proof that every deployment exposes all these outcomes. Actual impact depends on the worker's privileges, application architecture, network segmentation, secrets management, and other security controls.

Nevertheless, an unauthenticated RCE vulnerability in a widely deployed server-side runtime deserves urgent attention.

Detection and Investigation

Detection is challenging because the vulnerable behavior occurs inside PHP's core request-processing mechanisms. Ordinary web application logs may not provide enough information to establish whether exploitation occurred.

Security teams should consider reviewing:

• PHP error logs for unexpected memory exhaustion or fatal errors.
• Web server and reverse-proxy logs for unusual multipart requests or repeated malformed submissions.
• Application and service logs for unexpected failures around request processing.
• Changes to files, processes, accounts, scheduled tasks, and outbound connections that may indicate post-compromise activity.
• Runtime versions and package inventories across production servers, containers, and staging environments.

Memory exhaustion errors can have legitimate causes, so a single error is not proof of exploitation. Likewise, the absence of obvious errors does not prove that a system is safe.

Detection rules should be developed and tested against the official advisories and trusted vendor guidance. Avoid relying on one request pattern or one log message as a definitive indicator.

Mitigation: Patch First

The PHP development team identifies updating to a release containing the fixes as the reliable remediation.

The relevant patched releases are:

These versions reflect the PHP project's October 21, 2026 security release.

Recommended actions:

1. Inventory PHP deployments.
Identify PHP versions across web servers, PHP-FPM pools, containers, hosting platforms, and applications that bundle their own runtime.

2. Apply the appropriate security update.
Use a patched PHP release or a verified vendor package containing the relevant fixes. Plan upgrades carefully, but treat internet-facing affected systems as a priority.

3. Restart or redeploy affected workers.
Ensure running PHP processes actually use the patched runtime. Updating files without refreshing the active processes may leave old code running.

4. Review temporary mitigations.
Configuration changes discussed in security advisories can reduce exposure to particular attack paths, but they are not a replacement for patching. Follow the official guidance for each CVE rather than assuming that one setting addresses both.

5. Add defense in depth.
Enforce sensible request-size limits, review multipart upload handling, restrict unnecessary outbound network access, and run application workers with the minimum privileges necessary. These measures reduce risk but do not eliminate the underlying vulnerability.

6. Investigate potentially exposed systems.
If a vulnerable server was internet-facing before patching, review available telemetry and consider whether incident-response procedures should be initiated.

Official PHP release information: https://www.php.net/

Final Thoughts

PHP2Shell is a useful reminder that application security does not stop at the application layer.

Even carefully written application code depends on the safety of its language runtime, memory-management routines, request-processing pipeline, and deployment configuration.

CVE-2026-109618 highlights the risks associated with memory corruption during error handling. CVE-2026-109619 demonstrates how stale internal state can become dangerous when request boundaries are not handled correctly.

For defenders, the immediate priority is straightforward: identify affected deployments, apply verified security updates, ensure workers are running patched code, and investigate suspicious activity where warranted.

For security researchers, these issues also reinforce the importance of understanding memory safety, error-handling paths, and the interaction between HTTP request processing and runtime internals.

Patch the runtime, verify the deployment, and do not treat temporary workarounds as a complete fix.

References

1. OffSec — PHP2Shell: Critical Vulnerabilities in PHP Core
   https://www.offsec.com/blog/php2shell-critical-vulnerabilities-in-php-core/
2. PHP Security Advisory — CVE-2026-109618
   https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
3. PHP Security Advisory — CVE-2026-109619
   https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
4. PHP official website and security releases
   https://www.php.net/
5. CERT-EU — Critical Vulnerabilities in PHP
   https://cert.europa.eu/publications/security-advisories/2026-018/

Disclaimer: This article is for educational and defensive security purposes. Validate affected versions and remediation guidance against official advisories and your software vendor's documentation.