October 24, 2026
PHP2Shell Explained: When PHP’s Memory Management Becomes an Attacker’s Playground
Inside CVE-2026–109618 and CVE-2026–109619, two PHP runtime flaws that could lead to Remote Code Execution
By Aakriti Mishra
5 min read
The security of a web application depends on more than just the code written by its developers. It also depends on the underlying technologies that process user requests, manage memory, and execute application logic.
When one of those underlying technologies is flawed, even a carefully written application can be exposed. Consider a simple scenario: someone sends a single HTTP request to your website. There is no vulnerable plugin, no exposed admin panel, and no authentication bypass. There is only a request reaching a vulnerable runtime.
That is what makes runtime-level vulnerabilities so concerning. PHP powers millions of websites and processes every one of their requests. So what happens when the bug is not in the website, but in PHP itself?
That is where PHP2Shell comes in.
PHP2Shell is the name used here for two critical vulnerabilities in the PHP runtime:
• CVE-2026–109618: Out-of-Memory (OOM) memory corruption
• CVE-2026–109619: Stale global state, leading to Use-After-Free (UAF)
Both are memory-management flaws, and both may potentially lead to Remote Code Execution (RCE). Let's break them down with analogies, diagrams, and a practical defense checklist.
First, What Is PHP Actually Doing?
PHP (PHP: Hypertext Preprocessor) is a server-side scripting language used to build dynamic websites. Unlike JavaScript in your browser, PHP runs on the server.
When you log in to a site, PHP might process your credentials, manage your session, query a database, and build the page you see. A tiny example:
Simple. But behind every response, the runtime is allocating memory, parsing requests, managing internal structures, and running application logic. When something breaks inside those mechanisms, the impact can reach far beyond a single app.
Why PHP2Shell Is Different
A bug in a login page affects one application. A bug in the runtime can affect every application running on it.
In some scenarios, the vulnerable behavior can occur before your application's own authentication logic even runs. That means login pages and access controls alone may not protect a vulnerable server.
• CVE-2026–109618: Out-of-Memory memory corruption, with potential RCE
• CVE-2026–109619: Stale global state / Use-After-Free, with memory corruption and potential RCE
Vulnerability #1: CVE-2026–109618 (Out-of-Memory Memory Corruption)
When PHP runs out of memory, what happens next?
Every request needs memory: for parameters, internal structures, and temporary data. Sometimes an allocation fails. This is an Out-of-Memory (OOM) condition.
A well-built runtime handles this safely. It stops the operation and cleans up anything half-built. CVE-2026–109618 involves a request-processing path where allocation failures may be handled incorrectly.
The problem isn't that PHP runs out of memory. The problem is what happens afterward.
If internal structures are left partially initialized, and the cleanup or error-handling code treats them as if they were complete, memory corruption can occur. Under certain conditions, an attacker may be able to influence that corruption and gain control over execution.
PHP stops at the failed allocation, but the cleanup path treats half-built structures as complete.
Vulnerability #2: CVE-2026–109619 (Stale Global State / Use-After-Free)
Released memory should never be touched again
To understand this one, you need to know Use-After-Free (UAF): a program accessing memory after it has been released.
*int ptr = malloc(sizeof(int));
*ptr = 10;
free(ptr);
*/ Unsafe: memory has already been released / printf("%d", ptr);
The pointer still exists, but the memory behind it is no longer valid. If that memory gets reused for something else, the program may read or write unexpected data. The results can include memory corruption, information disclosure, or even code execution.
How this applies to PHP
PHP keeps internal global structures to manage request-related data. Some of them may reference memory tied to a specific HTTP request.
The vulnerability involves internal state that retains a reference to memory that has already been freed. Because that state may persist across requests handled by the same PHP worker, a later operation can touch memory that is no longer valid.
The memory is freed when Request 1 ends, but the internal state still points at it.
How the Two Bugs Connect
The root causes differ: one is a failed allocation, the other is access after release. But both target the same surface, PHP's internal request-processing and memory handling, and both can leave PHP's internal state corrupted.
Either flaw can corrupt PHP's internal state; what follows depends on whether the attacker can steer it.
One important caveat: triggering a memory bug does not automatically mean RCE. Exploitation depends on the PHP version, deployment configuration, memory layout, and whether an attacker can actually control the resulting corruption.
From Request to Remote Code Execution: The Four Stages
1. Finding a vulnerable install. Attackers look for apps running affected PHP versions. Deployments vary: Apache mod_php, PHP-FPM, PHP-CGI, FrankenPHP, LiteSpeed. Real risk depends on version, configuration, and whether the vulnerable path is reachable.
2. Triggering the flaw. A specially crafted request is sent to cause an OOM condition or force access to stale internal state.
3. Shaping the corruption. Triggering is only half the battle. The attacker must influence the resulting corruption so that it affects program execution. If successful, code can run with the privileges of the PHP process.
4. Post-exploitation. If RCE is achieved, the fallout can include:
• Access to config files and database credentials
• Exposure of sensitive application data
• Modification of application files
• Web shells and malicious scripts
• Pivoting to internal services
• Availability disruption
How bad it gets depends largely on how locked down the PHP process is.
How to Protect Yourself
The short version: upgrade PHP. Because this is a runtime flaw, updating your framework or plugins is not enough.
1. Upgrade to a fixed release
Use the fixed version listed in the official PHP security advisory for your branch. If you are on an unsupported branch, plan a migration to a supported one.
2. Verify the version your web server actually uses
php -v
Careful: this shows the command-line PHP, which can differ from the version running behind your web server (for example via PHP-FPM). Always check the runtime your application actually uses.
3. Audit every PHP deployment
• Production servers
• Dev and staging environments
• Containers
• Shared hosting
• PHP-FPM and Apache mod_php installs
• PHP bundled inside third-party products
Updating WordPress, Drupal, or Joomla does not patch the underlying PHP runtime.
4. Apply temporary mitigations if you can't patch yet
• Restrict access to exposed PHP services
• Disable unnecessary PHP services
• Apply appropriate WAF rules
• Monitor suspicious HTTP requests and PHP error logs
• Restrict outbound network access from PHP workers
• Run PHP with minimal privileges
These reduce exposure. They are not a substitute for patching.
5. Monitor for exploitation
Watch your web server access logs, PHP error logs, process execution logs, EDR alerts, and network egress logs. Red flags include unexpected child processes spawned by PHP workers, unusual outbound connections, and unexplained changes to application files.
Only an upgraded runtime closes the hole; the review and monitoring steps catch what slipped through.
Final Thoughts
PHP2Shell is a reminder that the most dangerous bugs often live underneath your application, in the layers you assume are solid.
CVE-2026–109618 and CVE-2026–109619 are two different memory-management failures, one around failed allocations and one around stale references to freed memory. Both can potentially lead to RCE, and both live in the component that handles every web request your server receives.
The key point: PHP2Shell is a runtime-level vulnerability, not a flaw in one particular website or plugin. Find your PHP installs, patch the runtime, check your configurations, and keep watching your logs.
References
Disclaimer: This article is for educational and defensive purposes only. Exploiting vulnerabilities on systems without explicit authorization may violate the law.