PHP2Shell: Inside Two Critical PHP RCE Vulnerabilities — and the Public Exploit Landscape

How memory corruption in PHP's request lifecycle can bypass application-level defenses, why public PoCs change the threat picture, and what defenders should know now.

On October 21, 2026, two critical vulnerabilities in PHP core became public: CVE-2026–109618 and CVE-2026–109619.

Both carry a CVSS v4.0 score of 9.2 and can allow unauthenticated remote code execution. Collectively known as PHP2Shell, they affect the runtime beneath countless web applications rather than a single CMS or framework.

What makes these vulnerabilities particularly concerning is where they occur.

PHP processes HTTP requests before the application executes its own code. If a vulnerability can be triggered during this early processing stage, application-level authentication, input validation, and business logic may never get the opportunity to protect the application.

This is not simply another vulnerable WordPress plugin. It is a problem in the runtime that makes WordPress, Drupal, Joomla, and many other applications work.

I spent time reviewing the technical analysis published by Wiz Research and Datadog Security Labs, the official PHP security information, and the public exploit reports appearing around the disclosure.

The result is a closer look at how the two vulnerabilities work, what the public exploit landscape currently tells us, and why defenders should treat this disclosure as an urgent infrastructure-level issue.

1. The root cause: when PHP's internal state becomes unsafe

To understand PHP2Shell, it helps to look beyond the application layer.

PHP receives a request, parses its contents, allocates memory for request parameters, initializes internal data structures, and eventually executes the application code.

Throughout this process, PHP maintains state in memory. Some structures belong to an individual request; others persist across requests handled by a worker.

The vulnerabilities arise when an operation fails partway through and PHP's internal state is not left in a safe condition.

Two concepts are central to understanding the issue:

Use-after-free (CWE-416) occurs when software continues to access memory after it has been released. If an attacker can influence what occupies that memory afterward, the stale reference may become a memory-corruption primitive.

Incomplete initialization after a fatal error occurs when an operation updates internal bookkeeping but fails before all the associated data has been initialized. If cleanup subsequently trusts that bookkeeping, it may process invalid data as though it were legitimate.

These are different manifestations of a broader memory-safety problem.

Wiz Research identified multiple exploitable paths in PHP's core, grouped under the two CVEs. Their research also demonstrated that memory disclosure could expose sensitive process data independently of achieving remote code execution.

Source: Wiz Research — PHP2Shell technical analysis

2. CVE-2026–109618: Memory corruption during request initialization

The first vulnerability involves PHP's handling of memory exhaustion and incomplete initialization.

How the failure occurs

When PHP parses submitted form data, it creates internal structures to represent the received parameters. These structures contain metadata describing the entries that have been allocated and initialized.

During a vulnerable insertion path, PHP updates its internal entry counters before completing the allocation of the associated key.

If that allocation fails because of a memory limit, PHP raises a fatal error and abandons the operation.

The problem is that the internal structure may now describe an entry that was never fully initialized.

When PHP subsequently cleans up the failed request, it can interpret the incomplete entry as valid data. Under suitable conditions, an attacker can influence the contents of the affected memory and turn this cleanup operation into a controlled memory-corruption primitive.

Datadog Security Labs independently reproduced this behavior and demonstrated a path from the memory-corruption condition to command execution.

Why application authentication does not necessarily help

The vulnerable processing takes place during request initialization.

PHP can encounter the flaw while parsing the request, before the target application executes its authentication middleware or application-specific input validation.

Consequently, adding an authentication check inside a PHP application does not necessarily protect the vulnerable code path.

The same principle applies to applications that otherwise appear simple or secure. The underlying runtime, not the application's business logic, is the relevant attack surface.

What the impact looks like

The demonstrated exploitation chain can result in remote command execution with the privileges of the affected PHP worker.

Depending on the deployment, those privileges might belong to a dedicated web service account or another account configured to run PHP.

Wiz Research also demonstrated an unauthenticated process-memory disclosure path associated with this vulnerability. Memory exposure can be significant even when an attacker does not immediately obtain command execution, because application secrets and other sensitive data may reside in the worker's address space.

It is important to distinguish the demonstrated outcomes from a guarantee that every vulnerable installation is equally exploitable. Memory layout, PHP configuration, request limits, and deployment architecture influence the practical exploitation conditions.

Sources:

• Datadog Security Labs — CVE-2026–109618 analysis
• Wiz Research — PHP2Shell

3. CVE-2026–109619: Stale state surviving across requests

The second vulnerability concerns state that survives longer than the memory it references.

PHP workers can process multiple requests over their lifetime. Some internal variables are maintained at worker scope, while the objects they reference belong to a particular request.

That difference in lifetime is critical.

How the failure occurs

A fatal error can interrupt PHP while it is resetting internal state. The request's memory may then be released while a worker-level variable still holds a pointer to that memory.

A later request handled by the same worker can encounter the stale reference before PHP has properly reinitialized the associated state.

At that point, the worker may interpret memory from an earlier request as a valid internal object.

This is a use-after-free condition. Under suitable circumstances, attacker-controlled data can be placed where the stale reference will access it, creating an opportunity for memory corruption and potentially code execution.

Two important technical paths

The research describes related issues involving fatal-error backtraces and request processing.

• Fatal-error backtrace state: PHP can retain internal backtrace information after a fatal error. If the referenced request memory has been freed, subsequent diagnostic processing may encounter stale state.
• Request and upload processing: PHP's early upload-processing paths can interact with session or decoder state before normal initialization is complete. A later request handled by the same worker may encounter references left behind by an earlier failure.

The official PHP advisory describes the vulnerability's affected paths and remediation. The exact conditions differ between PHP versions and execution architectures.

Why worker reuse matters

A request does not necessarily exploit the vulnerability in isolation.

The attack may depend on earlier processing leaving unsafe state behind and a later request reaching the same worker before the state is reset.

This is why worker architecture, request routing, and the sequence of events can influence exploit reliability.

It also explains why a simple scan that sends one request and observes no crash is not sufficient to establish that a deployment is safe.

Source: PHP security advisory — CVE-2026–109619

4. Why the combination matters

The two vulnerabilities should not be treated as interchangeable bugs.

CharacteristicCVE-2026–109618CVE-2026–109619Core issueMemory corruption following interrupted initializationStale request-owned state reused across request boundariesRelevant internal behaviorForm-data parsing and cleanupFatal-error state and request/upload processingPotential impactRemote code execution and memory disclosureRemote code execution through use-after-free pathsAuthentication boundaryVulnerable processing can occur before application codeVulnerable processing can occur before normal application handlingDefensive priorityPatch PHP and investigate abnormal request processingPatch PHP and investigate worker state, request sequences, and suspicious execution

Both vulnerabilities illustrate the same architectural lesson: internal memory-safety guarantees matter just as much as the security controls implemented by the application.

A properly authenticated application can still be exposed if its runtime processes attacker-controlled data through a vulnerable path before authentication occurs.

5. Public exploit landscape: what is available?

This is the part defenders should pay particular attention to.

As of October 21, 2026, public proof-of-concept code for PHP2Shell is available.

One example is the repository published by syrex1013:

GitHub — syrex1013/php2shell

The repository describes proof-of-concept code for both CVEs, including a lab for reproducing a use-after-free condition and a claimed remote-code-execution chain.

The repository is publicly accessible, so defenders should assume that potential attackers can study the same material.

However, there are three different questions that should not be conflated:

1. Does public proof-of-concept code exist?
2. Does that code successfully exploit the vulnerability under particular conditions?
3. Is the vulnerability being exploited in real-world attacks, and on what scale?

Evidence for one does not automatically answer the others.

What do the security reports say about exploitation?

The available reporting is not entirely consistent.

The Canadian Centre for Cyber Security reported that public PoC information was available but that it had not identified active exploitation at the time of its alert.

Datadog Security Labs, meanwhile, reported receiving multiple reports of active exploitation and observing broad, untargeted scanning as of October 21.

These statements reflect different reporting observations and potentially different visibility into the threat landscape. They should not be presented as equivalent claims.

My assessment is therefore:

• Public PoC: Confirmed to exist.
• Practical exploitability: Researchers have demonstrated remote code execution in controlled environments.
• Active exploitation: Reported by Datadog, but the Canadian advisory had not identified it at the time of publication.
• Scale of exploitation: Not established by these reports alone.

This is an evolving situation. The absence of confirmed activity in one source does not establish that exploitation is absent everywhere.

Equally, the presence of public exploit code is not evidence that every vulnerable server is currently under attack.

For defenders, the sensible response is to prioritize remediation and review available telemetry without waiting for a universally confirmed campaign.

Sources:

• Canadian Centre for Cyber Security — Alert AL26–026
• Datadog Security Labs — PHP2Shell
• Public PHP2Shell PoC repository

6. What should defenders look for?

The vulnerability is triggered in PHP's request-processing layer, so an investigation should not depend exclusively on application logs.

A useful approach combines three sources of evidence.

HTTP and reverse-proxy telemetry

Look for unusual request patterns, particularly multipart form submissions, abnormal request sizes, and suspicious sequences of requests.

Other signals described by researchers include repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and abnormal PHP worker behavior.

None of these indicators is conclusive on its own. Large uploads and memory-exhaustion errors can occur during legitimate application activity.

The objective is to identify deviations from the normal request patterns of the affected application and correlate them with other evidence.

PHP and web server logs

Review PHP-FPM, Apache, Nginx, and application logs around the suspected activity.

For CVE-2026–109618, memory-exhaustion errors during request initialization can be useful investigative leads.

However, successful exploitation does not necessarily crash the worker. A successful HTTP response also does not prove that a request was harmless.

Endpoint telemetry

Look for web server or PHP processes spawning unexpected shells, scripting interpreters, or download utilities.

Investigate whether those processes create files, access unusual locations, or communicate with unfamiliar external infrastructure.

On systems monitored by Microsoft Defender XDR, DeviceProcessEvents, DeviceFileEvents, and DeviceNetworkEvents can help reconstruct this activity, provided the relevant telemetry is collected.

Correlate endpoint events with request timestamps and web server logs. A suspicious process alone does not identify either CVE, but a suspicious process chain immediately following anomalous PHP request activity is much more significant.

7. Remediation: patch the runtime

The PHP project released security updates for the following branches:

PHP branchFixed releasePHP 8.28.2.35PHP 8.38.3.36PHP 8.48.4.27PHP 8.58.5.12

Older PHP versions are also affected. PHP 8.1 and earlier are outside the project's normal support lifecycle, although certain vendors may provide backported fixes.

Do not assume that upgrading the host's primary PHP installation updates every embedded runtime, container, or third-party appliance. Check the actual software components that serve requests.

Temporary configuration changes can reduce some exposure, but they are not equivalent to applying the security fix. Researchers have specifically warned that disabling session upload progress alone does not fully remediate both vulnerabilities.

The recommended order of operations is:

1. Identify affected PHP runtimes, including bundled and containerized deployments.
2. Prioritize internet-facing systems.
3. Apply the appropriate upstream or vendor-supported security update.
4. Restart or replace affected workers and redeploy updated containers where necessary.
5. Review logs and endpoint telemetry for suspicious activity before and after remediation.
6. Investigate and contain any suspected compromise according to your incident-response procedures.

Official remediation guidance:

• PHP security advisories
• NCSC-NL — PHP2Shell operational guidance
• Canadian Centre for Cyber Security — PHP2Shell alert

Final thoughts

PHP2Shell is a reminder that application security depends on the runtime beneath the application.

Both CVE-2026–109618 and CVE-2026–109619 demonstrate how interrupted initialization and stale memory references can turn internal implementation flaws into remotely exploitable vulnerabilities.

The availability of public PoC code makes this disclosure more urgent, even though the extent of real-world exploitation remains uncertain and reports differ.

For defenders, the priorities are clear: patch affected PHP installations, identify exposed runtimes that may be hidden inside containers or third-party products, and correlate suspicious HTTP activity with PHP errors and endpoint behavior.

The most important lesson is not to wait for a perfect indicator of compromise.

When a critical vulnerability exists below the application's authentication layer, remediation and investigation need to happen in parallel.

Further reading

• Wiz Research — PHP2Shell: Technical analysis
• Datadog Security Labs — Vulnerability analysis and detection
• NCSC-NL — PHP2Shell operational repository
• Public proof-of-concept repository
• Canadian Centre for Cyber Security — Official alert

Research status: October 21, 2026. Exploit availability and reports of in-the-wild activity can change rapidly. Verify the latest official advisories before making operational decisions.