- by x32x01 ||
A newly reported PHP security incident, known as PHP2Shell, has raised concerns about potential vulnerabilities in PHP's core memory management and error-handling mechanisms.
The reports focus on two vulnerability identifiers: CVE-2026-109618 and CVE-2026-109619. Both are described as potentially allowing attackers to exploit memory corruption during fatal errors, with remote code execution (RCE) identified as a possible consequence.
For developers and server administrators, the immediate priority is to verify their PHP installation, check official security advisories, and determine whether their environment requires an emergency update.
Important: The original incident report includes specific CVE identifiers, patched versions, exploitation statistics, and claims about government responses. These details should not be treated as confirmed until they can be matched against authoritative security advisories.
Unlike a typical vulnerability in a website plugin, theme, or application, these flaws exist inside PHP itself. This means even a well-written application can be exposed when running on a vulnerable PHP installation.
Both vulnerabilities have a CVSS v4.0 severity score of 9.2 (Critical).
The vulnerabilities are:
Security researchers have independently reproduced the vulnerabilities, and reports of malicious exploitation attempts have already emerged.
However, the situation changed when information about the vulnerabilities appeared publicly on October 20.
A Hacker News post revealed details about the upcoming disclosure, and exploit-related material began circulating before the planned release.
Security researchers subsequently confirmed that the leaked information concerned genuine PHP vulnerabilities.
The PHP security team responded by accelerating its release schedule.
October 21, 2026: Emergency security updates became available, one day ahead of the original disclosure date.
The early disclosure also prompted security organizations, including the Dutch National Cyber Security Centre (NCSC-NL), to publish operational guidance for affected organizations.
One of these mechanisms involves
Under certain out-of-memory (OOM) conditions, this behavior can leave memory in an improperly initialized state.
When PHP subsequently performs request cleanup, it may process invalid memory.
An attacker can potentially manipulate these conditions to achieve remote code execution.
The important detail is that exploitation can happen before the website's application code begins executing.
Normally, PHP must reset these references when the request finishes.
However, certain error-handling scenarios can leave references pointing to memory that has already been released.
This creates a use-after-free condition.
When the same PHP worker processes another request, it may access stale memory before its internal state has been properly initialized.
Under exploitable conditions, this can lead to remote code execution.
PHP's session upload progress functionality is one relevant attack surface, although disabling it alone does not eliminate the overall vulnerability.
Potentially affected environments include:
Apache mod_php deployments deserve particular attention because researchers have demonstrated exploitation before application-level protections execute.
However, administrators should not assume that other PHP deployment models are safe.
These releases address both CVE-2026-109618 and CVE-2026-109619.
Official fixed versions:
PHP 8.1 and older branches are also affected, but they no longer receive standard upstream security updates.
Some operating system vendors provide security backports for older PHP packages. Administrators using distribution-maintained PHP should verify the package's security status rather than relying exclusively on its displayed version number.
PHP has also published minimal source backports for PHP 7.4, 8.0, and 8.1.
For supported installations, upgrading to the appropriate patched release is the recommended solution.
Installing a patched PHP runtime is the primary remediation.
Administrators should prioritize internet-facing servers, particularly systems processing untrusted HTTP requests.
This displays the version used by your command-line PHP installation.
Keep in mind that your website may use a different PHP version.
For example, a server can run one version through the CLI while Apache or PHP-FPM uses another.
Verify the actual runtime configured for each hosted website.
If you use cPanel, check the PHP version assigned to each domain through MultiPHP Manager or your hosting provider's PHP management interface.
Select the appropriate patched version from the table above.
Before upgrading:
Updating PHP on the host does not automatically update a separate PHP runtime bundled inside a container or third-party application.
However, these are temporary precautions, not complete fixes.
Disable session upload progress
If your application does not require PHP's session upload progress functionality, disable it in the relevant PHP configuration:
This reduces one potential attack surface but does not prevent every PHP2Shell exploitation technique.
Review memory-related settings
Review your current
Avoid blindly applying configuration changes to production servers.
In particular, setting
Restrict unnecessary file uploads
If your application does not require multipart form submissions, consider restricting unnecessary
Test these restrictions carefully because they may interfere with legitimate application functionality.
Reduce public exposure
For critical systems that cannot be patched immediately, consider temporarily restricting public access until remediation is complete.
The PHP security team emphasizes that configuration-based mitigations cannot replace the security update.
Start by reviewing web server logs, PHP error logs, and available endpoint security telemetry.
Potential indicators worth investigating include:
Likewise, the absence of a PHP crash does not establish that exploitation was unsuccessful.
Security researchers have demonstrated that successful exploitation does not necessarily terminate the affected PHP worker.
If compromise is suspected, preserve relevant logs and forensic evidence, investigate potentially exposed credentials, and follow your organization's incident response procedures.
A vulnerability in the underlying runtime can expose applications even when their own code follows established security practices.
With two critical vulnerabilities now publicly disclosed and security patches available, delaying the update creates unnecessary risk.
The priority is simple: identify vulnerable PHP installations, install the appropriate security release, restart affected services, and review your environment for suspicious activity.
Official Security References:
The reports focus on two vulnerability identifiers: CVE-2026-109618 and CVE-2026-109619. Both are described as potentially allowing attackers to exploit memory corruption during fatal errors, with remote code execution (RCE) identified as a possible consequence.
For developers and server administrators, the immediate priority is to verify their PHP installation, check official security advisories, and determine whether their environment requires an emergency update.
Important: The original incident report includes specific CVE identifiers, patched versions, exploitation statistics, and claims about government responses. These details should not be treated as confirmed until they can be matched against authoritative security advisories.
What Is PHP2Shell?
PHP2Shell is the name given to two critical security vulnerabilities affecting PHP's core runtime engine.Unlike a typical vulnerability in a website plugin, theme, or application, these flaws exist inside PHP itself. This means even a well-written application can be exposed when running on a vulnerable PHP installation.
Both vulnerabilities have a CVSS v4.0 severity score of 9.2 (Critical).
The vulnerabilities are:
- CVE-2026-109618: Remote code execution through out-of-memory corruption.
- CVE-2026-109619: Remote code execution through stale global state.
Security researchers have independently reproduced the vulnerabilities, and reports of malicious exploitation attempts have already emerged.
How the PHP2Shell Incident Started
The vulnerabilities were originally scheduled for coordinated public disclosure on October 22, 2026.However, the situation changed when information about the vulnerabilities appeared publicly on October 20.
A Hacker News post revealed details about the upcoming disclosure, and exploit-related material began circulating before the planned release.
Security researchers subsequently confirmed that the leaked information concerned genuine PHP vulnerabilities.
The PHP security team responded by accelerating its release schedule.
October 21, 2026: Emergency security updates became available, one day ahead of the original disclosure date.
The early disclosure also prompted security organizations, including the Dutch National Cyber Security Centre (NCSC-NL), to publish operational guidance for affected organizations.
Understanding the Two PHP2Shell Vulnerabilities
Both vulnerabilities involve PHP's internal memory management, but they exploit different problems during request processing.CVE-2026-109618: Out-of-Memory Corruption
PHP uses internal mechanisms to interrupt execution when a fatal error occurs.One of these mechanisms involves
longjmp(), which can abruptly transfer execution out of the current context.Under certain out-of-memory (OOM) conditions, this behavior can leave memory in an improperly initialized state.
When PHP subsequently performs request cleanup, it may process invalid memory.
An attacker can potentially manipulate these conditions to achieve remote code execution.
The important detail is that exploitation can happen before the website's application code begins executing.
CVE-2026-109619: Stale Global State
The second vulnerability involves global state that temporarily references memory belonging to an individual request.Normally, PHP must reset these references when the request finishes.
However, certain error-handling scenarios can leave references pointing to memory that has already been released.
This creates a use-after-free condition.
When the same PHP worker processes another request, it may access stale memory before its internal state has been properly initialized.
Under exploitable conditions, this can lead to remote code execution.
PHP's session upload progress functionality is one relevant attack surface, although disabling it alone does not eliminate the overall vulnerability.
Which PHP Servers and Websites Are Affected?
PHP2Shell is particularly concerning because the vulnerabilities exist below the application layer.Potentially affected environments include:
- Apache with mod_php
- PHP-FPM
- PHP-CGI
- FrankenPHP
- LiteSpeed
- WordPress
- Drupal
- Magento
- Laravel
- Joomla
- XenForo
Apache mod_php deployments deserve particular attention because researchers have demonstrated exploitation before application-level protections execute.
However, administrators should not assume that other PHP deployment models are safe.
PHP2Shell: Affected Versions and Security Updates
The PHP development team released four patched versions on October 21, 2026.These releases address both CVE-2026-109618 and CVE-2026-109619.
Official fixed versions:
| PHP Branch | Minimum Fixed Version |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Some operating system vendors provide security backports for older PHP packages. Administrators using distribution-maintained PHP should verify the package's security status rather than relying exclusively on its displayed version number.
PHP has also published minimal source backports for PHP 7.4, 8.0, and 8.1.
For supported installations, upgrading to the appropriate patched release is the recommended solution.
How to Protect Your Server Against PHP2Shell
There is no complete configuration-only workaround for these vulnerabilities.Installing a patched PHP runtime is the primary remediation.
Administrators should prioritize internet-facing servers, particularly systems processing untrusted HTTP requests.
Step 1: Check Your Current PHP Version
Connect to your server using SSH and execute: Bash:
php -vKeep in mind that your website may use a different PHP version.
For example, a server can run one version through the CLI while Apache or PHP-FPM uses another.
Verify the actual runtime configured for each hosted website.
If you use cPanel, check the PHP version assigned to each domain through MultiPHP Manager or your hosting provider's PHP management interface.
Step 2: Install the Security Update
Update PHP through your operating system's supported repositories, hosting control panel, or official PHP distribution.Select the appropriate patched version from the table above.
Before upgrading:
- Create a verified backup.
- Check application compatibility with the target PHP version.
- Install the available security update.
- Restart the relevant PHP workers and web services.
- Confirm that your website uses the patched runtime.
- Test essential application functionality.
Updating PHP on the host does not automatically update a separate PHP runtime bundled inside a container or third-party application.
Step 3: Apply Temporary Mitigations if Updating Is Delayed
If you cannot install the update immediately, several measures may help reduce exposure.However, these are temporary precautions, not complete fixes.
Disable session upload progress
If your application does not require PHP's session upload progress functionality, disable it in the relevant PHP configuration:
Code:
session.upload_progress.enabled = 0Review memory-related settings
Review your current
memory_limit and post_max_size values against the official PHP advisory.Avoid blindly applying configuration changes to production servers.
In particular, setting
memory_limit = -1 removes PHP's memory limit and can introduce additional resource-exhaustion risks.Restrict unnecessary file uploads
If your application does not require multipart form submissions, consider restricting unnecessary
multipart/form-data requests at the web server or security gateway.Test these restrictions carefully because they may interfere with legitimate application functionality.
Reduce public exposure
For critical systems that cannot be patched immediately, consider temporarily restricting public access until remediation is complete.
The PHP security team emphasizes that configuration-based mitigations cannot replace the security update.
How to Check for Possible PHP2Shell Exploitation
Updating PHP closes the known vulnerabilities, but administrators should also investigate whether their systems were targeted before patching.Start by reviewing web server logs, PHP error logs, and available endpoint security telemetry.
Potential indicators worth investigating include:
- Unusual or repeated HTTP POST requests.
- Unexpectedly large form submissions.
- Memory exhaustion errors during request initialization.
- Suspicious PHP worker behavior.
- Unexpected shell processes launched by PHP.
- Unexplained changes to application files.
Likewise, the absence of a PHP crash does not establish that exploitation was unsuccessful.
Security researchers have demonstrated that successful exploitation does not necessarily terminate the affected PHP worker.
If compromise is suspected, preserve relevant logs and forensic evidence, investigate potentially exposed credentials, and follow your organization's incident response procedures.
Frequently Asked Questions
-------------------Can PHP2Shell exploit a website without authentication?
Yes. Both vulnerabilities can potentially enable unauthenticated remote code execution. Application-level authentication alone is insufficient because vulnerable PHP processing can occur before application code executes.Does updating WordPress or Laravel fix PHP2Shell?
No. The vulnerabilities exist in the PHP runtime itself. Updating your application is good security practice, but you must also patch the underlying PHP installation.Is disabling session upload progress enough?
No. Disablingsession.upload_progress.enabled may reduce exposure to certain attack paths, but it is not a complete mitigation.Are PHP 7.4 and PHP 8.1 vulnerable?
Yes. Older PHP branches are affected. Administrators should migrate to supported releases or obtain verified security backports from their operating system or PHP vendor.Does Cloudflare completely prevent PHP2Shell attacks?
No. Network-level security controls can provide additional protection, but they should not be considered substitutes for patching PHP.Final Thoughts: Patch PHP Before Attackers Get There
PHP2Shell demonstrates why server security cannot stop at keeping website applications and plugins updated.A vulnerability in the underlying runtime can expose applications even when their own code follows established security practices.
With two critical vulnerabilities now publicly disclosed and security patches available, delaying the update creates unnecessary risk.
The priority is simple: identify vulnerable PHP installations, install the appropriate security release, restart affected services, and review your environment for suspicious activity.
Official Security References:
Last edited: