PHP2Shell: Critical PHP RCE Vulnerabilities Explained

Company

Blog

PHP2Shell: Critical PHP RCE Vulnerabilities Explained

Engineering 21 Oct 2026 5 min. read

Patches are now available. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 fix both PHP2Shell vulnerabilities, and the PHP Security Team has confirmed unauthenticated remote code execution. Update immediately. See our update on the official patches for affected environments and interim mitigations.

On October 20, the PHP Security Team did something unusual: it warned developers about two critical vulnerabilities before releasing the patches or even disclosing the technical details.

The official announcement confirmed two vulnerabilities, both rated 9.2 under CVSS v4.0, and scheduled an emergency security release for October 21 at 14:00 UTC. The team also reserved the right to release the fixes earlier if exploit details became public or active exploitation was detected.

The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, are already being discussed under the name PHP2Shell.

According to CERT-EU, early reports suggest the possibility of unauthenticated remote code execution (RCE), with potential exposure extending back to PHP 5. At that point, the official list of affected versions and exploitation requirements hadn't been published.

That distinction mattered. The severity was confirmed early, but until the advisories were published, much of what we knew about the underlying vulnerabilities came from independent security research.

With PHP powering applications across Laravel, Symfony, WordPress, Drupal, and many other platforms, there's good reason for developers and infrastructure teams to pay attention.

Editor's note: Subsequent research has challenged the original cached-pointer use-after-free explanation. See our updated technical findings below. The stale global state vulnerability later confirmed by the PHP Security Team (CVE-2026-109619) shouldn't be read as the same mechanism described in this section. See our update on the official advisories.

One of the more detailed early investigations comes from Upwind's technical assessment.

Their analysis points to a possible use-after-free vulnerability in PHP's session upload progress handling, specifically in php_session_rfc1867_callback() within ext/session/session.c.

PHP has a built-in mechanism for tracking file upload progress through sessions. During multipart HTTP request processing, it maintains information about incoming uploads, including how many bytes have been received.

According to Upwind, certain request sequences may cause PHP to retain references to memory that has already been released. If an attacker can manipulate how that memory is reused, the result could potentially be arbitrary code execution.

The researchers also suggest that the issue may be exploitable with default PHP configurations, particularly because session.upload_progress.enabled is enabled by default.

If confirmed, this would be significant for one particular reason: the vulnerable behavior could occur during PHP's request processing, before application-level code has an opportunity to handle the request.

That means a perfectly maintained Laravel application, with updated dependencies and properly implemented authentication, could still be exposed through its PHP runtime.

It's important not to confuse this with a framework vulnerability. Laravel, Symfony, and WordPress aren't necessarily responsible for the underlying issue, and updating application dependencies alone wouldn't address a vulnerability inside PHP itself.

The PHP Security Team has since published the actual root causes, which we cover in our update on the official patches.

Before the official disclosure, independent researchers had already started publishing technical analyses and proof-of-concept code.

One interesting example is Qi Deng's php2shell-poc repository, published on October 21.

The repository documents three possible attack chains involving PHP session handling:

The researcher claims successful RCE demonstrations for these chains and provides verification scripts, a Docker laboratory, and a technical write-up.

However, there's an important distinction between what the repository claims and what its published test scripts independently establish.

The session injection scenario requires an additional LFI vulnerability. The use-after-free script focuses on demonstrating memory behavior under AddressSanitizer rather than providing a complete remote exploit. The serializer mismatch scenario also depends on particular configuration conditions and an exploitable object or gadget chain.

In other words, the existence of these PoCs doesn't establish that every default PHP installation is vulnerable to unauthenticated RCE through all three methods. Nor has the precise relationship between these chains and the two announced CVEs been officially confirmed.

Another interesting detail is an earlier PHP source code pull request, #22113, originally opened in May 2026. It addresses how PHP's multipart upload progress handler accepts session identifiers from form data even when session.use_only_cookies is enabled.

The PR predates the current disclosure by several months and touches an area now attracting considerable attention. That makes it worth examining, although there's currently no confirmation that it directly fixes either of the new vulnerabilities.

Taken together, these investigations suggest PHP's session handling deserves close attention. But we should be careful not to treat separate research findings as a single, fully verified exploit chain.

The Laravel team has already confirmed that it's working directly with the PHP Foundation and coordinating security updates across Laravel Cloud, Forge, and Vapor.

For Laravel Forge, the plan announced ahead of the release was for customers to apply the patched PHP versions to their servers. The team contacted Forge users and promised further guidance once the releases were published.

Laravel Vapor's PHP runtime layers were also expected to receive updates.

This is an important distinction for teams running Laravel in production. Framework security, dependency management, and runtime security are related, but they're not interchangeable.

Running composer update won't patch PHP itself. Likewise, putting a Laravel application into maintenance mode shouldn't be treated as protection against vulnerabilities that may be triggered before Laravel processes the request.

The good news is that the Laravel team is coordinating directly with the people responsible for the runtime, which should help hosting and application teams respond more quickly once the fixes are available.

Perhaps the most important development so far came from Cloudflare CTO Dane Knecht.

In an October 21 post on X, Knecht confirmed that Cloudflare had already deployed an initial set of WAF rules targeting known exploitation vectors for these vulnerabilities.

The protection is available to all Cloudflare customers, including those on the free plan.

More importantly, he confirmed that Cloudflare is already observing early attacks and updating mitigations as new exploitation methods emerge.

That changes the urgency of the situation. We're no longer dealing exclusively with hypothetical attack scenarios. There is already suspicious traffic associated with these vulnerabilities, although observing attack attempts doesn't necessarily mean successful server compromises have occurred.

Cloudflare's emergency Managed Ruleset update introduces four new anomalous execution detections. Two are configured to block matching requests, while the other two initially operate in logging mode.

A separate update for free customers provides two blocking rules.

Knecht also warned paid customers to verify that their WAF is enabled and that relevant rules haven't been configured to operate only in log mode.

An interesting exchange followed his announcement. Someone proposed a more aggressive emergency protection option that could temporarily block POST requests, form submissions, sessions, or file uploads altogether.

Knecht replied that Cloudflare was considering the idea.

It's an understandable suggestion in a situation where protecting the application might temporarily require restricting functionality. But such measures would come with significant operational trade-offs.

Knecht was also explicit about the limitations of Cloudflare's response: WAF rules are a stopgap, not a replacement for patching PHP.

At Moneo, PHP and Laravel are a significant part of the applications and infrastructure we build and maintain for our clients.

Our main concern in situations like this isn't whether a particular language or framework is secure in general. Vulnerabilities are a reality across programming languages, runtimes, operating systems, and infrastructure platforms.

The important question is how quickly we can understand the exposure and respond without unnecessarily disrupting production systems.

For teams operating PHP applications, there are a few immediate priorities:

One more concern is what happens now that the patches are published.

Attackers can compare vulnerable and patched source code to better understand the underlying defects. This is a normal part of security research, but it also means that systems left unpatched may become easier to target as technical details spread.

That's why identifying the affected runtime and having a reliable deployment process matter just as much as understanding the exploit itself.

The PHP Security Team released the fixes on October 21: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The official advisories confirmed unauthenticated remote code execution and explained the root causes of both vulnerabilities. We cover the details in our update on the official patches.

What we knew before the release was already enough to justify preparation: two critical vulnerabilities rated 9.2, preliminary research pointing toward remote code execution, independent PoCs appearing publicly, and Cloudflare confirming that early attacks were being observed. The official advisories have since confirmed that urgency.

It's also worth recognizing how quickly the ecosystem is responding. The PHP Foundation, Laravel, Cloudflare, and independent security researchers have all contributed different pieces of the response, from coordinated disclosure and runtime fixes to edge protection and technical analysis.

Application security doesn't end with application code. The runtime, web server, network configuration, dependencies, and deployment process are all part of the same system.

The patches and full advisories are now published. The sensible approach hasn't changed: distinguish confirmed facts from early research, understand where PHP is running, and update.

That's far more useful than speculation, and ultimately what matters most for keeping production systems secure.

Note: The findings below apply to the specific public PoCs and early explanations we reviewed. They don't contradict the PHP Security Team's later confirmation of unauthenticated RCE. See our update on the official patches.

Following our initial analysis, we reviewed three additional resources: J4ck3LSyN's investigation, the Zer061 repository, and another publicly available PoC.

The most interesting development isn't a new exploit, but a correction to an earlier one.

J4ck3LSyN revisited the original cached-pointer use-after-free theory and found that PHP's Z_TRY_ADDREF(progress->data) keeps the referenced array alive, invalidating that specific exploit chain. The researcher subsequently reported a different potential use-after-free issue involving serialization state, reproduced under specific conditions using AddressSanitizer. However, remote code execution has not been demonstrated through this alternative mechanism.

We also compared the two GitHub repositories and found that their PoC implementations share substan