PHP at Risk: Two Critical Vulnerabilities and Potential Exploitation Scenarios

On the evening of October 20, 2026, the PHP security team announced an emergency update to address two critical vulnerabilities, both rated 9.2 under CVSS v4.0. At that time, the root causes, affected components, and exploitation details had not yet been disclosed.

On October 21, the project released the patches and confirmed that CVE-2026-109618 and CVE-2026-109619 could allow unauthenticated remote code execution (RCE) under certain conditions. The vulnerabilities became known as PHP2Shell.

The Cyber Threat Intelligence (CTI) team at QuimeraX and Yokai Research, part of Hakai, are closely following the disclosure, technical analysis of the vulnerabilities, and their potential impact on internet-exposed environments.

What Has Been Confirmed

The official PHP advisory confirms that both vulnerabilities reside in the language's core rather than in a specific application or framework.

The issue is related to memory management during request processing, particularly when fatal errors or out-of-memory (OOM) conditions occur.

Under certain circumstances, PHP may terminate an operation while leaving internal structures in an inconsistent state. These structures may remain accessible after their memory has been freed, allowing memory corruption and, in exploitable scenarios, code execution.

The impact does not necessarily depend on a vulnerability in WordPress, Drupal, Joomla, or Laravel. Even applications with secure code may be exposed if they run a vulnerable version of PHP.

The risk is not limited to a single configuration either. Environments using PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed should be assessed.

The highest-risk scenario demonstrated so far involves Apache with mod_php, where an unauthenticated request can reach vulnerable code before the application itself begins executing.

CVE-2026-109618: Memory Corruption During OOM

The official PHP advisory confirms that both vulnerabilities reside in the language's core rather than in a specific application or framework.

The issue is related to memory management during request processing, particularly when fatal errors or out-of-memory (OOM) conditions occur.

Under certain circumstances, PHP may terminate an operation while leaving internal structures in an inconsistent state. These structures may remain accessible after their memory has been freed, allowing memory corruption and, in exploitable scenarios, code execution.

The impact does not necessarily depend on a vulnerability in WordPress, Drupal, Joomla, or Laravel. Even applications with secure code may be exposed if they run a vulnerable version of PHP.

The risk is not limited to a single configuration either. Environments using PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed should be assessed.

The highest-risk scenario demonstrated so far involves Apache with mod_php, where an unauthenticated request can reach vulnerable code before the application itself begins executing.

CVE-2026-109619: Stale Global State Across Requests

CVE-2026-109619 has been classified as RCE via stale global state.

PHP maintains internal structures used throughout different stages of request processing, including information related to sessions, errors, objects, and extensions.

These structures must be properly reinitialized between requests. However, a fatal error may interrupt this process, leaving references pointing to memory regions that have already been freed.

When the same process (worker) receives another request, certain operations may access these references before normal initialization has taken place.

The result is a use-after-free condition that can be leveraged for memory corruption and remote code execution.

For exploitation to occur, two operations must be combined. The first leaves an invalid reference stored in a persistent structure. The second, performed during another request handled by the same worker, accesses that reference before it has been properly reinitialized.

The advisory confirms multiple paths that can lead to this condition, including session-related operations and configuration diagnostics executed before normal request initialization.

In PHP 8.5, additional conditions involving the storage of backtrace information during fatal errors have also been identified.

The Session Upload Progress Hypothesis

Before the official disclosure, Yokai Research identified the session upload progress mechanism as a potential component involved in the vulnerabilities.

The disclosure confirmed that this feature is involved in certain exploitation paths, but also revealed that the underlying issue is broader than initially hypothesized.

Introduced in PHP 5.4 and enabled by default, this feature processes multipart/form-data upload information before the application's normal initialization.

During this process, the session extension may access internal structures that remained referenced following a previous interruption.

If one request leaves these references in an inconsistent state and another request is handled by the same worker, early upload progress processing may access memory that has already been freed.

This condition makes it possible to construct exploitation chains involving memory corruption and, depending on the characteristics of the environment, remote code execution.

Therefore, session.upload_progress is one of the confirmed exploitation paths, but disabling it does not eliminate all possible exploitation scenarios.

Exploitation and Proofs of Concept

Following the technical disclosure on October 21, functional exploitation scenarios were demonstrated, including unauthenticated remote code execution in environments running popular web applications.

Conditions allowing unauthorized access to PHP process memory were also demonstrated. Depending on the contents of these memory regions, this could expose sensitive information such as credentials, authentication tokens, API keys, and other data processed by the server.

Exploitation does not necessarily involve sending a single malicious request in every scenario.

Some exploitation chains require a combination of conditions, including internal state preparation, memory corruption or reuse, and the execution of specific operations during subsequent requests.

The technical complexity is significant. Both advisories classify the vulnerabilities with Attack Complexity: High and Attack Requirements: Present under CVSS v4.0.

Nevertheless, the existence of functional exploitation chains demonstrates that these conditions can be reached in real-world environments.

With the release of patches and the availability of technical details, the likelihood of exploits being adapted to different versions and configurations also increases.

Affected Versions and Patches

Official patches were released on October 21, 2026.

Versions preceding these security fixes within each PHP version series should be considered vulnerable.

The vulnerabilities also have implications for historical PHP versions. Vulnerable code paths are present in older releases, including implementations dating back to PHP 5.4.

PHP 8.1 and earlier versions are no longer covered by the project's regular support lifecycle. For legacy environments, source-code backports have been made available for 7.4, 8.0, and 8.1, while Linux distribution vendors and extended-support providers may release their own patched packages.

It is important to note that the version displayed by a package manager does not always directly correspond to the upstream version in which a fix was introduced. Linux distributions may backport security patches without changing the installed package's major version number.

For this reason, verification should take into account vendor security advisories and the actual package used by the service.

Updating the PHP core is necessary. Updating only WordPress, Drupal, or another framework does not resolve the issue.

Mitigation and Monitoring

The PHP project explicitly states that updating is the only complete fix.

For environments that cannot be updated immediately, the advisory outlines temporary measures to reduce exposure to specific exploitation paths.

CVE-2026-109618

One recommendation is to configure memory_limit=-1, preventing PHP's own memory limit from triggering the interruption exploited in the demonstrated attack chain.

This change does not eliminate other possible memory allocation failures and requires careful consideration of server resource consumption, as it removes the per-request memory limit enforced by PHP.

Stricter controls for multipart requests are also recommended, including limits on request body size, number of fields, headers, and structural nesting depth.

When an application does not require file uploads or multipart forms, this type of request can be blocked before reaching PHP.

These controls reduce the attack surface but do not replace patching.

CVE-2026-109619

Disabling session.upload_progress.enabled blocks confirmed exploitation paths involving early session processing.

In PHP 8.5 environments, disabling fatal_error_backtraces also reduces exposure to one of the demonstrated exploitation chains.

Another recommendation is to review invalid or obsolete configurations that generate warnings during request initialization. These warnings may contribute to the conditions required to access invalid references.

Suppressing error messages through display_errors, error_reporting, or similar mechanisms does not eliminate the vulnerability, as the internal state may be accessed before the decision to display or log the error is made.

These measures must be applied to the configuration actually used by the service, with worker processes restarted when necessary.

None of these changes should be considered a substitute for applying the security update.

Detection

From a monitoring perspective, certain behaviors may help identify exploitation attempts or activities that warrant further investigation.

These include unusual multipart/form-data requests, recurring out-of-memory errors, consecutive HTTP 500 responses, unexpected PHP process terminations, and anomalies related to session management.

PHPSESSID cookies with unusual content or sizes may also be relevant in certain exploitation chains.

These indicators should be correlated with the PHP version, service configuration, and application and infrastructure logs.

The presence of these indicators alone does not confirm exploitation, but it may justify further investigation, particularly in environments that have not yet received the security update.

For Our Clients

QuimeraX helps shorten this exposure window by leveraging the attack surface it already monitors. Its EASM inventories internet-exposed domains, applications, and services. Using this inventory, the Hakai team integrates a vulnerability detection template into the ASM engine, allowing affected PHP assets to be flagged automatically rather than relying on a manual inventory on the morning of the release.

CTI context is also delivered through the same platform, allowing clients to see which assets need updating at 11:00 AM, which configuration directives can limit exposure until the update is applied, and receive alerts when the EASM engine identifies a vulnerable asset in their environment. Everything is consolidated in a single place.

Schedule a demonstration of the platform today at https://quimerax.com/.