PHP2Shell: Mitigating the Critical PHP RCE Before the Patch

Update — October 21, 2026, 3:44 PM CEST

Given the current situation, several companies have decided to take their websites offline rather than risk a potential compromise.

Gina Peter Banyard, a PHP core developer, made a pretty clear statement on Mastodon:

The only mitigation is patching / upgrading PHP. I sadly know too much.

That last sentence is particularly concerning, especially coming from someone with direct knowledge of the vulnerability.

Temporary mitigations like WAF rules might reduce the attack surface, but they should not be considered reliable protection against this vulnerability.

Please assess the risk carefully and inform your clients if necessary. Taking a website offline might be inconvenient, but a compromised production environment is significantly worse.

One more thing: Once the official patch is released, we should expect attackers to reverse-engineer it, potentially leading to active exploitation shortly afterward.

Be prepared to patch immediately.

— — —

Yesterday, two critical vulnerabilities in PHP itself were disclosed: CVE-2026–109618 and CVE-2026–109619, both rated 9.2 on CVSS 4.0.

The vulnerabilities potentially allow unauthenticated remote code execution. Official patches are expected today, October 21, at 14:00 UTC.

Until then, there are a few things we can do to reduce the attack surface.

What's the issue?

According to Jackalsyn's research, one of the vulnerabilities is related to a use-after-free in PHP's session upload progress implementation.

The affected code is located in ext/session/session.c, specifically in php_session_rfc1867_callback.

During multipart uploads, PHP keeps references to internal data structures used for tracking upload progress. Under certain conditions, these structures can be freed while PHP still holds pointers to them.

By manipulating the memory that gets reused afterward, an attacker may be able to achieve arbitrary code execution.

Session upload progress is enabled by default, even though most applications probably don't use it.

The research also describes another potential attack path involving PHP's multipart parser, which means disabling upload progress alone won't necessarily eliminate the risk.

Disable session upload progress

The most straightforward mitigation is to disable PHP's built-in upload progress tracking if your application doesn't need it.

session.upload_progress.enabled = Off

session.upload_progress.enabled = Off

For Docker-based PHP installations, this can be added directly to the Dockerfile:

RUN echo "session.upload_progress.enabled=Off" \
    > /usr/local/etc/php/conf.d/security.ini

RUN echo "session.upload_progress.enabled=Off" \
    > /usr/local/etc/php/conf.d/security.ini

Make sure to rebuild and redeploy the container afterward.

This should mitigate the attack path involving session upload progress, but shouldn't be considered a complete fix for both vulnerabilities.

Restrict multipart requests

Since the second suspected attack path involves multipart request parsing, it might also make sense to restrict multipart requests at the reverse proxy or WAF level.

If your application doesn't need multipart uploads, you can temporarily block requests using multipart/form-data.

Nginx

For example, with Nginx:

map $http_content_type $block_multipart {
    default 0;
    ~*^multipart/form-data(?:\s*;|$) 1;
}
server {
    # Existing configuration
    if ($block_multipart) {
        return 403;
    }
}

map $http_content_type $block_multipart {
    default 0;
    ~*^multipart/form-data(?:\s*;|$) 1;
}
server {
    # Existing configuration
    if ($block_multipart) {
        return 403;
    }
}

Cloudflare

If you're using Cloudflare, you can achieve something similar using a custom WAF rule.

Navigate to Security → WAF → Custom Rules and create a rule using the following expression:

http.request.method eq "POST"
and
any(
  http.request.headers["content-type"][*] contains "multipart/form-data"
)

http.request.method eq "POST"
and
any(
  http.request.headers["content-type"][*] contains "multipart/form-data"
)

Set the action to Block.

This will reject POST requests containing a matching Content-Type header before they reach your origin server.

If you only want to protect specific applications, you can additionally restrict the rule to their hostnames:

http.host in {"app.example.com" "api.example.com"}
and
http.request.method eq "POST"
and
any(
  http.request.headers["content-type"][*] contains "multipart/form-data"
)

http.host in {"app.example.com" "api.example.com"}
and
http.request.method eq "POST"
and
any(
  http.request.headers["content-type"][*] contains "multipart/form-data"
)

Keep in mind that this will also block legitimate multipart form submissions and file uploads.

If your application requires them, consider limiting the restriction to endpoints that don't need multipart requests.

These rules are temporary attack-surface reductions, not guaranteed protection against every exploitation method.

Update PHP as soon as possible

The actual fix is to install the patched PHP releases once they're available.

Make sure to check all PHP runtimes, including containers and PHP-FPM pools. Especially in larger environments, the PHP version reported by php -v isn't necessarily the one your application is running.

Also, don't forget to rebuild container images and restart PHP workers after updating.

Conclusion

Until the patches are available, disabling session upload progress and restricting unnecessary multipart requests seem like reasonable precautions.

Neither should be treated as a complete solution, but both can help reduce the exposed attack surface.

Once the official PHP releases are available, updating the runtime should take priority.

References: Jackalsyn's technical analysis · PHP security announcements

Contents