PHP2Shell: Two Critical PHP Vulnerabilities That Could Turn a Web Request Into Remote Code…

Inside CVE-2026–109618 and CVE-2026–109619: How memory management flaws in PHP exposed web servers to unauthenticated remote code execution.

October 28, 2026 | Cybersecurity Research | 7 min read

Imagine running a fully patched WordPress website with strong authentication, secure plugins, and carefully configured access controls, only to discover that an attacker might execute code on your server without ever reaching your application's login page.

That's the concern surrounding PHP2Shell, a pair of critical vulnerabilities disclosed in October 2026 that affect PHP itself, rather than a particular website or plugin.

The vulnerabilities, tracked as CVE-2026–109618 and CVE-2026–109619, both received a CVSS v4.0 score of 9.2 (Critical).

What makes them particularly dangerous isn't simply the possibility of remote code execution (RCE). It's where the vulnerabilities exist: inside the PHP runtime's request processing and memory management mechanisms.

In certain configurations, exploitation can occur before the application even starts executing its own code.

Let's break down what happened, why these vulnerabilities matter, and what security teams should be doing about them.

1. What Exactly Is PHP2Shell?

PHP2Shell is the name given to two memory-safety vulnerabilities affecting PHP's internal request lifecycle.

VulnerabilityDescriptionSeverityCVE-2026–109618RCE through out-of-memory handling corruptionCritical (9.2)CVE-2026–109619RCE through stale global stateCritical (9.2)

Both vulnerabilities can potentially allow unauthenticated attackers to execute arbitrary code using the privileges of the affected PHP worker.

The attack surface includes deployments using:

Apache with mod_php
PHP-FPM
php-cgi
FrankenPHP
LiteSpeed

Apache mod_php is considered particularly exposed because of how its request initialization and shutdown mechanisms interact with the vulnerable code.

Unlike a traditional SQL injection or authentication bypass, these issues are not fundamentally caused by mistakes in application-level PHP scripts.

They originate in the underlying runtime.

This distinction is important.

Updating WordPress, installing additional security plugins, or strengthening application authentication does not fix a vulnerable PHP interpreter.

2. Understanding the Root Cause

To understand PHP2Shell, we need to examine how PHP handles requests and manages memory.

When a PHP server receives an HTTP request, the runtime performs several operations:

Initialize the request environment.
Parse HTTP headers and request bodies.
Allocate memory for internal structures.
Execute the PHP application.
Clean up request-specific resources.

Normally, these operations follow a predictable lifecycle.

But what happens when execution is interrupted midway through initialization, or when pointers to request data survive after that data has been freed?

That's where PHP2Shell becomes interesting.

CVE-2026–109618: Out-of-Memory Corruption

PHP uses memory allocation mechanisms to manage request processing. When a memory allocation fails, the interpreter must interrupt the operation and handle the error.

The vulnerability occurs when an out-of-memory condition interrupts internal initialization, leaving certain request data structures in an invalid or partially initialized state.

Later, cleanup code may assume these structures are valid.

Conceptually, the failure looks like this:

HTTP Request
     |
     v
PHP begins request initialization
     |
     v
Internal memory allocation
     |
     v
Out-of-memory condition
     |
     v
Initialization interrupted
     |
     v
Cleanup accesses invalid state
     |
     v
Memory corruption
     |
     v
Potential remote code execution

HTTP Request
     |
     v
PHP begins request initialization
     |
     v
Internal memory allocation
     |
     v
Out-of-memory condition
     |
     v
Initialization interrupted
     |
     v
Cleanup accesses invalid state
     |
     v
Memory corruption
     |
     v
Potential remote code execution

The critical problem is not simply that memory allocation fails.

It's that error-handling and cleanup routines may operate on state that was never safely initialized.

Under exploitable conditions, an attacker can manipulate this behavior to influence execution.

CVE-2026–109619: Stale Global State

The second vulnerability concerns internal global variables that temporarily reference request-specific memory.

PHP processes many HTTP requests over the lifetime of a worker.

Although request-specific memory should be cleaned up after each request, certain global references may not be properly reset.

This creates a dangerous situation:

Request A
   |
   v
Global pointer references request memory
   |
   v
Request A completes
   |
   v
Request memory is freed
   |
   v
Global pointer remains stale
   |
   v
Request B begins
   |
   v
Stale memory reference is accessed
   |
   v
Potential memory corruption / RCE

Request A
   |
   v
Global pointer references request memory
   |
   v
Request A completes
   |
   v
Request memory is freed
   |
   v
Global pointer remains stale
   |
   v
Request B begins
   |
   v
Stale memory reference is accessed
   |
   v
Potential memory corruption / RCE

This is related to a use-after-free condition, where a program continues referencing memory after its lifetime has ended.

Depending on the circumstances, subsequent allocations may reuse that memory.

An attacker who can influence the allocation and request sequence may be able to turn what initially looks like a memory-management bug into a security exploit.

The broader lesson is that request isolation depends on more than application logic. It also depends on correctly managing state across the interpreter's execution lifecycle.

3. Why PHP2Shell Is More Dangerous Than a Typical Web Vulnerability

Most web application vulnerabilities require an attacker to interact with a particular feature.

An SQL injection might require a vulnerable database query. A file upload vulnerability might require access to an upload endpoint. An authentication bypass might depend on an application-specific logic error.

PHP2Shell is different.

Because the vulnerabilities exist inside the PHP runtime, an attacker may be able to target the environment beneath the application itself.

The potential consequences include:

Unauthenticated exploitation: An attacker may not need an account, credentials, or an existing authenticated session.

Remote code execution: Successful exploitation could execute code with the permissions of the PHP worker.

Application-independent exposure: Multiple applications hosted on the same vulnerable PHP infrastructure may be affected.

Sensitive memory exposure: Some exploitation paths may expose information from process memory.

Post-exploitation opportunities: A successful foothold may allow attackers to investigate server configuration, access application data, or attempt lateral movement.

Importantly, RCE does not automatically mean root access.

The initial execution context generally depends on the privileges assigned to the PHP or web server process. Further compromise would depend on permissions, configuration, available credentials, and other weaknesses.

4. Are Attackers Exploiting PHP2Shell in the Wild?

Yes. Public reporting has already identified attempts to exploit the vulnerabilities.

According to Sophos, attackers began targeting PHP2Shell shortly after the vulnerabilities became publicly known, with evidence of attempted exploitation also reported before coordinated disclosure.

Sophos documented attempts involving specially crafted HTTP requests and reported a successful exploitation event associated with delivery of a payload resembling a Mirai-family malware variant.

This distinction matters: an observed successful exploit does not mean every attack attempt succeeds, nor does it establish widespread compromise across all vulnerable PHP deployments.

Still, the combination of public proof-of-concept code, remotely reachable PHP services, and critical memory-management flaws creates a serious risk.

Security teams should treat the issue as an active threat rather than a purely theoretical vulnerability.

5. How Security Teams Can Investigate Exposure

The first step is identifying where PHP is actually running.

A useful starting point on Linux is:

php -v

php -v

This displays the PHP version used by the command-line interpreter.

However, the CLI version may differ from the PHP runtime serving HTTP requests.

Administrators should also inspect web server configurations, PHP-FPM pools, container images, and any vendor-bundled PHP installations.

For systems using PHP-FPM:

ps aux | grep '[p]hp-fpm'

ps aux | grep '[p]hp-fpm'

For Apache deployments, inspect the loaded PHP modules and determine whether mod_php is being used.

Review HTTP and Process Activity

Potential indicators deserving investigation include:

Unexpected multipart/form-data requests.
Repeated application worker crashes.
Unusual memory exhaustion or fatal error patterns.
PHP workers creating unexpected child processes.
Unexpected outbound network connections originating from web server processes.
Suspicious new files in writable application directories.

None of these indicators alone proves PHP2Shell exploitation.

They are investigative leads that should be correlated with application behavior, server logs, endpoint telemetry, and current threat intelligence.

What About a WAF?

A web application firewall may block known exploit patterns.

However, a WAF is not a reliable substitute for fixing a memory-safety defect inside the runtime.

Attack variations, differences in HTTP parsing, and paths that bypass the WAF can all limit the effectiveness of request filtering.

Patching the PHP runtime remains the primary remediation.

6. Which PHP Versions Are Affected?

On October 21, 2026, the PHP project released security updates addressing both vulnerabilities.

The first fixed versions are:

PHP BranchFixed VersionPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35

PHP 8.1 and earlier are end-of-life upstream. Some vendors provide backported security fixes, so administrators should verify their distribution or hosting provider's security advisories rather than relying on version numbers alone.

Organizations should also ensure that updated PHP workers are actually restarted and that old container images or bundled runtimes are replaced.

Installing a security package without replacing vulnerable running processes may leave the environment exposed.

7. What Should Organizations Do Right Now?

If your infrastructure runs PHP, these are the immediate priorities.

First, identify exposure. Inventory all PHP installations, including applications, internal services, containers, and third-party products that embed PHP.

Second, apply security updates. Upgrade supported PHP branches to the patched releases or install vendor-confirmed backports.

Third, verify running services. Restart affected workers and confirm that the web-serving runtime, not just the CLI interpreter, has been patched.

Fourth, investigate suspicious activity. Review relevant HTTP, PHP, and endpoint logs for exploitation attempts, unusual crashes, and post-exploitation behavior.

Fifth, reduce the blast radius. Restrict unnecessary filesystem access, separate application workloads, minimize PHP worker privileges, and monitor unexpected process execution or outbound connections.

If patching cannot happen immediately, the PHP project's advisory describes configuration-specific risk reductions. These measures are incomplete and should only be treated as temporary defenses.

8. The Bigger Security Lesson

What makes PHP2Shell especially important is that it challenges a common assumption about application security.

Developers often focus on sanitizing inputs, protecting authentication systems, preventing injections, and securing business logic.

Those controls matter.

But PHP2Shell illustrates that a securely written application can still inherit critical vulnerabilities from the runtime underneath it.

A security boundary is only as strong as the components enforcing it.

This extends far beyond PHP.

The same principle applies to language interpreters, application servers, dependency libraries, container runtimes, and operating systems.

When critical vulnerabilities exist below the application layer, application-level defenses alone cannot guarantee protection.

Final Thoughts

PHP2Shell is more than another pair of high-severity CVEs.

It demonstrates how subtle memory-management errors, especially during exceptional execution paths, can create serious security consequences in software that supports large numbers of web applications.

Two particularly important concepts emerge from this incident:

1. Error handling is security-critical code. Unusual states such as memory exhaustion must be handled as carefully as normal application execution.

2. Runtime security is application security. Even strong authentication, input validation, and secure coding practices cannot compensate for a vulnerable interpreter.

For security engineers, the lesson is straightforward: monitor the entire technology stack, understand the runtime beneath your applications, and prioritize fixes that eliminate the underlying vulnerability.

Because sometimes, the most dangerous exploit never needs to reach your application code.

References

Disclaimer: This article is intended for cybersecurity education, defensive research, and vulnerability awareness.

Contents