Introduction
An easy-to-understand guide to CVE-2026–109618 and CVE-2026–109619, the memory-management flaws behind PHP2Shell, and what developers and security researchers can learn from them.
Imagine running a website that handles thousands of visitors every day. Your login system works, your passwords are hashed, and your application validates user input.
Then, someone sends a specially crafted HTTP request to your server. They do not need to log in. They do not need to upload a traditional PHP web shell. In certain vulnerable configurations, the request can exploit a flaw inside PHP itself and potentially allow the attacker to execute commands on the server.
That is the security concern behind PHP2Shell, the name used for two critical vulnerabilities disclosed in PHP on October 21, 2026.
The vulnerabilities are tracked as CVE-2026–109618 and CVE-2026–109619. Both received a CVSS v4.0 severity score of 9.2 out of 10. They can potentially allow remote code execution (RCE) without authentication on affected systems.
The official PHP project released security updates for both vulnerabilities, and proof-of-concept details have begun circulating publicly. This makes understanding and patching the issue particularly important.
Sources: Official PHP security announcement | TryHackMe’s PHP2Shell technical analysis
1. First, what is PHP2Shell?
Before looking at the vulnerabilities, let us understand the technology involved.
PHP is a programming language used by websites to perform tasks such as processing login requests, displaying dynamic content, handling file uploads, and communicating with databases.
Platforms and applications such as WordPress, Drupal, and Joomla can use PHP to run their server-side functionality.
When someone visits a PHP-powered website, the server processes the request using the PHP runtime. The runtime is the software that executes PHP code and handles the internal work required to process each request.
PHP2Shell is not simply a vulnerable WordPress plugin or a poorly written PHP script. The original PHP2Shell vulnerabilities affect PHP’s underlying request-processing and memory-management behaviour.
The name describes the potential result: an attacker may turn a specially crafted web request into the ability to execute code on the server.
In simpler terms, an attacker might not need to find a vulnerable application function. They may be able to target the software responsible for processing the request before the application even begins its normal work.
That distinction is important because application-level protections cannot reliably fix a vulnerability in the underlying PHP runtime.
2. Why are these vulnerabilities dangerous?
Three terms help explain the risk.
Remote code execution (RCE) means an attacker can cause a vulnerable system to execute code remotely. Depending on the vulnerability and the attacker’s level of control, that code might run operating-system commands or access application data.
Unauthenticated means the attacker does not need to successfully log in before attempting the attack.
Memory corruption means a program has incorrectly handled the memory it uses to store information. The result might be a crash, unexpected behaviour, disclosure of data, or code execution.
PHP2Shell involves problems with how PHP handles memory when requests fail or when information from an earlier request remains in memory longer than it should.
To understand this, we need to look at the two vulnerabilities separately.
3. CVE-2026–109618: What happens when PHP runs out of memory?
The first vulnerability involves an out-of-memory condition, commonly abbreviated as OOM.
What does out of memory mean?
Every running program needs memory to store information and perform operations.
For example, when a website processes a form, PHP may allocate memory to store the submitted fields, file metadata, and other request information.
PHP also has a memory_limit setting that limits the amount of memory a PHP request can consume.
If the request requires more memory than PHP is permitted to use, PHP may encounter a fatal out-of-memory error.
Under normal circumstances, this should cause the operation to fail safely.
But what if the failure happens at precisely the wrong moment?
How the vulnerability works
According to the official PHP advisory, PHP can interrupt request processing when an allocation fails. In certain circumstances, some internal request information may not yet be fully initialized.
The request then moves into cleanup, where PHP releases resources and processes the state left behind by the failed operation.
The problem is that cleanup can encounter information that is not in the state it expects.
Under exploitable conditions, this can result in memory corruption and remote code execution.
Think of it like assembling a machine. A worker begins connecting several components, but the process is interrupted halfway through. Another worker arrives to clean up and assumes every component was installed correctly. That assumption leads to the cleanup process handling an incomplete assembly incorrectly.
The analogy is not technically exact, but it captures the core problem: an unexpected failure leaves internal state in a condition that later operations do not safely handle.
Researchers demonstrated remote code execution against Apache installations using mod_php. The relevant request-processing path can be reached before the website's own PHP application code executes.
That matters because the vulnerable code may run before the application’s normal authentication or input-validation logic has an opportunity to intervene.
The key lesson: a memory limit does not automatically make a program safe when memory allocation fails. The program must also handle the failure correctly.
4. CVE-2026–109619: The danger of using memory that has already been freed
The second vulnerability involves a different memory-safety problem: use-after-free.
What is use-after-free?
Programs allocate memory when they need to store information. When the information is no longer required, that memory can be released and reused.
A use-after-free vulnerability occurs when a program continues to use a reference to memory after that memory has been freed.
Imagine writing an important phone number on a sticky note, then throwing the note away. Later, someone reuses the same space for a different note, but another person still believes the old phone number is there.
They read the wrong information because their reference is outdated.
Something similar can happen inside a program when a pointer still refers to memory that has already been released.
How PHP2Shell uses this weakness
PHP workers may process multiple web requests during their lifetime.
Information belonging to one request should be reset before its memory is released and the worker moves on to another request.
However, PHP has internal global state associated with errors, sessions, objects, and extensions. Under certain conditions, an error or another interrupted operation can leave that state pointing to request memory that has already been freed.
A later request handled by the same worker may encounter this stale state before PHP fully initializes the new request.
The resulting use-after-free can allow memory disclosure or, under exploitable conditions, remote code execution.
In simple terms:
PHP processes a request and stores internal information.
An unexpected failure interrupts part of the normal cleanup process.
Memory is released, but a reference to that memory remains.
The same worker processes another request.
An operation encounters the stale reference before normal initialization has corrected the state.
The exact conditions depend on the internal state involved, the PHP build, and the request-processing environment.
The official CVE-2026–109619 advisory describes the issue in detail.
What about fatal_error_backtraces?
PHP can retain information about the call stack associated with a fatal error. A call stack, or backtrace, helps developers understand which functions were active when something went wrong.
The PHP research identifies a path involving fatal-error backtraces: attacker-controlled input can contribute to an error condition, and stale internal state may subsequently be consumed under the required conditions.
This is one example of how diagnostic and cleanup behaviour can become security-sensitive.
The important point is not that backtraces are inherently dangerous. It is that internal state must be managed correctly even when an operation terminates unexpectedly.
5. What could an attacker achieve?
Remote code execution is serious because it can allow an attacker to do more than view a website’s public pages.
Depending on the privileges of the affected PHP process, the accessible files, application configuration, and network permissions, a successful compromise could potentially enable an attacker to:
Read sensitive application files and credentials accessible to the PHP worker.
Modify website content or application files that the worker is permitted to change.
Execute additional commands under the permissions of the compromised process.
Access data available to the affected application.
Establish a foothold for further attacks if other weaknesses are present.
However, there is an important distinction: remote code execution does not automatically mean root access.
For example, PHP may run under a restricted service account such as www-data on some Linux systems. If code execution occurs under that account, the attacker initially inherits its permissions, not necessarily those of the root user.
The actual impact depends on how the server and application are configured.
This is why running web applications with minimal permissions is an important security practice, even when the underlying runtime is fully patched.
6. A realistic example: A vulnerable WordPress website
Imagine a small online store running WordPress on a Linux server.
The owner has installed security plugins, uses HTTPS, and requires strong passwords for administrator accounts. However, the server is running a vulnerable PHP release.
An attacker discovers that the underlying PHP runtime has not been updated.
In an applicable vulnerable environment, the attacker may attempt to trigger the memory-handling flaw through a crafted HTTP request without logging in.
If the attack succeeds, the attacker may gain code-execution capability under the permissions of the PHP process.
If that process can read the site’s configuration file, the attacker might be able to obtain database credentials. If it can modify website files, the attacker might be able to alter pages or insert malicious code.
If the same server also contains unrelated applications with weak isolation, the initial compromise could create opportunities for further attacks.
This example illustrates potential consequences, not a claim that every WordPress installation is exploitable.
WordPress plugins are not necessarily responsible for the original defect. The vulnerability is in PHP itself, so updating plugins alone does not repair the affected runtime.
The correct response is to identify the PHP version used by the website, check the hosting provider’s security updates, and apply the appropriate fix.
7. Understanding the attack flow in a controlled lab
I recently explored PHP2Shell in a TryHackMe learning environment. Hands-on labs are useful because they show how a vulnerability moves from a technical explanation to a reproducible security problem.
For this type of lab, it helps to separate the attack into its main stages.
Stage 1: Identify the target
The researcher starts with the IP address or URL of the intentionally vulnerable machine provided by the lab.
The goal is to understand the target environment rather than blindly send requests to an unknown system.
Stage 2: Understand the vulnerable component
The researcher reviews the PHP runtime, request-processing environment, and relevant vulnerability details.
Version information helps with initial assessment, but a version string alone cannot establish every aspect of exploitability. Vendors may also backport security patches without changing to the upstream version number listed in an advisory.
Stage 3: Understand the failure condition
The exercise demonstrates how specially constructed requests can trigger unexpected behaviour in PHP’s request processing or memory management.
The important concept is that the failure happens inside the runtime, rather than necessarily in a vulnerable application function.
Stage 4: Validate the result
In a dedicated lab, the researcher follows the room’s instructions and verifies the demonstrated impact using the lab’s intended method.
The purpose is to understand what the result proves, identify the relevant process permissions, and distinguish successful code execution from a simple error response.
Stage 5: Connect the attack to remediation
Finally, the researcher identifies the affected runtime, reviews the official advisory, and determines which patch or other approved remediation is appropriate.
This final stage is just as important as demonstrating the vulnerability. A successful lab exercise should teach you how to recognize and prevent the same class of issue in real environments.
What about the payload and attacking commands?
The exact PHP2Shell proof-of-concept depends on the vulnerable path and target environment. I am not reproducing a weaponized, copy-paste RCE payload in this public article because it could be reused against real internet-facing systems.
For practical testing, use the payload and exploit instructions supplied by your authorized TryHackMe exercise, and run them only against the target assigned to that lab.
For defensive investigation on a system you administer, the following commands can help establish the local PHP CLI version and its configuration:
php -v
php --iniTo check whether a training web server is reachable, you can use a normal HTTP request:
curl -I http://<LAB_TARGET>/Replace with the assigned lab address. This is a connectivity check, not an exploit or a vulnerability test.
Important: the PHP CLI configuration may differ from the configuration used by a public-facing website. Checking php -v on a server does not, by itself, prove that its web-serving PHP runtime is patched.
The correct workflow is to verify the version and security package actually used by the affected web service.
8. Which PHP versions are affected?
PHP published fixes for the two original PHP2Shell vulnerabilities on October 21, 2026.
The upstream patched versions are:
PHP branchFirst patched versionPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35
Installations running earlier releases within these branches should be treated as affected unless their vendor confirms that the required security fixes have been applied.
PHP 8.1 and older branches are end-of-life and do not receive ordinary upstream security releases for these vulnerabilities. Some distributions or commercial vendors may provide backported fixes, so administrators should verify their specific packages rather than rely exclusively on the displayed version number.
You can follow the official PHP security announcement for release information.
9. How can administrators protect their servers?
The most important action is to update PHP to a release that contains the original PHP2Shell fixes.
1. Patch the actual web-serving PHP runtime
Identify whether the application runs PHP through Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed, or another deployment.
Check the package and runtime used by the actual web application. Where applicable, restart the relevant services and workers after updating.
2. Do not depend on one configuration change
Disabling session upload-progress tracking can reduce exposure to a particular attack path, but it does not repair the original out-of-memory flaw.
Temporary configuration mitigations must be evaluated against the relevant PHP advisory. They should not be treated as a substitute for the security update.
3. Review web and PHP logs
Look for unusual request patterns, unexpected multipart upload activity, repeated memory-related errors, abnormal PHP worker behaviour, and unexpected child processes or outbound connections.
These indicators are investigative leads, not proof of exploitation. The absence of suspicious logs does not prove that a server is safe.
4. Reduce the impact of a compromise
Run PHP workers with the minimum permissions necessary. Avoid storing secrets in locations readable by unrelated applications, restrict unnecessary outbound connections, and maintain appropriate isolation between sites.
These measures do not fix PHP2Shell, but they can limit the damage if an application or runtime is compromised.
5. Investigate potential compromise
If there is evidence of exploitation, preserve relevant logs, follow the incident-response process, and assess whether credentials accessible to the affected process need to be rotated. Patching alone does not remove an attacker’s persistence if the system was already compromised.
10. What PHP2Shell teaches us as security researchers
PHP2Shell is a useful case study because the vulnerabilities do not depend solely on a classic web-application mistake such as SQL injection, cross-site scripting, or an insecure file-upload function.
Instead, they demonstrate how errors in lower-level memory management can undermine the security of applications built on top of a runtime.
They also highlight several lessons.
First, unexpected failures must be handled safely. A program should not assume that internal data is fully initialized just because a previous operation began successfully.
Second, memory cleanup is part of security. Releasing memory without resetting references to it can create use-after-free vulnerabilities that later operations may expose.
Third, patching the underlying runtime matters. A website may use secure application code and still be affected by a vulnerability in its execution environment.
Finally, a proof of concept and a complete remediation plan are different things. Demonstrating an exploit helps establish impact. Defenders still need to identify affected deployments, apply the correct updates, verify the result, and investigate any evidence of compromise.
For anyone learning penetration testing, TryHackMe-style labs can help turn these concepts into practical experience. But the real value comes from understanding why the attack works and how to prevent it — not simply obtaining command execution.
Conclusion
PHP2Shell shows how a flaw deep inside a widely used programming-language runtime can have consequences across many different websites and applications.
CVE-2026–109618 involves unsafe memory handling when PHP encounters out-of-memory conditions. CVE-2026–109619 involves stale internal state that may be used after its associated memory has been released.
Under the required conditions, both can potentially lead to unauthenticated remote code execution.
The practical response is clear: identify affected PHP deployments, apply the appropriate security updates, verify the runtime used by the web application, and investigate suspicious activity where necessary.
For security researchers, this incident is also a reminder that some of the most important vulnerabilities are not visible in the application code we inspect every day. Sometimes, the critical failure happens in the runtime underneath it.
References and Further Reading
PHP — Official security announcements and patched releases
https://www.php.net/archive/2026.phpPHP Security Advisory — CVE-2026–109618: RCE via OOM corruption
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79wPHP Security Advisory — CVE-2026–109619: RCE via stale global state
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rpTryHackMe — The PHP Patch Is Out. The Bug Wasn’t Where Anyone Thought
https://tryhackme.com/resources/blog/php2shell-patchTryHackMe — PHP2Shell: Tracking an Unpatched RCE Scare in Real Time
https://tryhackme.com/resources/blog/php2shell-updateGoogle Cloud — Responding to core PHP vulnerabilities
https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619UK National Cyber Security Centre — Critical security issue affecting PHP
https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
Connect & Contact
Buy Me a Coffee: buymeacoffee.com/jaseervk
GitHub: github.com/jaseervk
Portfolio: www.jaseervk.com
Blog: blog.jaseervk.com
LinkedIn: linkedin.com/in/jaseer-vk-
Medium: medium.com/@jaseervk321