PHP2Shell: What We Know So Far

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, with an emergency security release scheduled 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. However, the official list of affected versions and exploitation requirements hasn't been published yet.

That distinction matters. The severity is confirmed, but much of what we're learning about the underlying vulnerabilities still comes 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.

What might actually be happening inside PHP?

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 exact root cause, though, still needs confirmation from the PHP Security Team.

Independent researchers are already publishing PoCs

While the official disclosure is still pending, independent researchers have 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:

1. Session file injection combined with LFI: Manipulating session data through upload progress handling, then exploiting an application-level local file inclusion vulnerability to execute the injected content.
2. Use-after-free during deserialization: Exploring memory corruption involving unserialize(), object destructors, and PHP's internal memory management.
3. Session serializer mismatch: Investigating situations where different session serialization configurations could lead to unexpected object deserialization and potentially dangerous destructor execution.

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.

How Laravel is responding

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 current plan is for customers to apply patched PHP versions to their servers once they're available. The team has already contacted Forge users and promised further guidance when the releases are published.

Laravel Vapor's PHP runtime layers are 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.

Cloudflare confirms attacks are already emerging

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.

What this means for production environments

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:

• Identify the PHP versions actually running in production. That includes PHP-FPM processes, containers, virtual machines, and separate runtime environments. The CLI version reported by php -v may not be the version serving web requests.
• Review session upload progress configuration. Disabling session.upload_progress.enabled may reduce exposure to the suspected attack path if the application doesn't require it. This hasn't been confirmed as a complete mitigation for both vulnerabilities.
• Verify WAF protection and origin access. Cloudflare's emergency protections are useful, but they won't help if an attacker can bypass Cloudflare and reach the origin server directly.
• Watch for unusual activity. Unexpected PHP-FPM worker crashes, unusual multipart requests, and unexplained HTTP 5xx responses deserve investigation. None of these alone proves exploitation.
• Prepare to deploy the official patches. Prioritize internet-facing services, verify the fixed runtime is actually in use after deployment, and plan upgrades for unsupported PHP versions that may not receive security fixes.

One more concern is what happens after 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.

What happens next?

At the time of writing, the PHP Security Team's emergency release is scheduled for October 21 at 14:00 UTC.

We still need the official affected-version matrix, technical details, and fixed releases before drawing firm conclusions about the complete scope of these vulnerabilities.

What we do know is 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 are being observed.

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

For us, the takeaway is straightforward.

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.

We'll have a clearer technical picture when the PHP patches and full advisories are published. Until then, the sensible approach is to distinguish confirmed facts from early research, understand where PHP is running, and be ready to update.

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