PHP2Shell: Critical PHP Vulnerabilities (CVE-2026-109618, CVE-2026-109619)

Updated October 21, 2026, before PHP published its full technical advisory. Some of the information below comes from independent researchers and is still unconfirmed. We will update this article once the fix is released.

PHP2Shell is the name given to two critical vulnerabilities disclosed in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Early reports say they could let an unauthenticated attacker execute code remotely on a vulnerable web server.

The flaw is not in a WordPress plugin, a Laravel package or a specific CMS but in the PHP runtime. Every application built on that runtime could therefore share the same exposure. The PHP security team has confirmed both vulnerabilities and announced an emergency security release on October 21, 2026 at 14:00 UTC (16:00 Paris time).

PHP2Shell at a glance

An important distinction: the PHP project has confirmed the severity and the emergency release. The CVE identifiers and RCE impact were reported by researchers, including watchTowr. The exact affected versions, exploitation prerequisites and technical mechanism still need confirmation in the official advisory.

How PHP2Shell might work

The most discussed hypothesis involves PHP’s native handling of multipart/form-data requests and its session.upload_progress feature. Unlike a typical application-level flaw, the attack would target processing that happens before Laravel, Symfony, WordPress or your own code gets control.

Suspected processing chain (unconfirmed)

1. Attacker-controlled HTTP request, potentially a crafted multipart request.
2. Web server or reverse proxy: Nginx, Apache, etc.
3. PHP native request processing: multipart parser and upload-progress tracking. This is the suspected vulnerable layer.
4. Application code: authentication, routing, controllers.

Researchers have suggested a use-after-free memory corruption in the upload-progress session handler. Upwind published a detailed version of this theory, but other independent testing has not reproduced the reported RCE mechanism. The root causes, and the difference between the two CVEs, are not confirmed by PHP: treat this explanation as preliminary research, not established fact.

Why it matters

If pre-authentication code execution is confirmed, an attacker could run commands with the PHP worker’s privileges, steal application secrets and database credentials, then attempt lateral movement across your infrastructure. A well-secured Laravel or WordPress application does not necessarily protect you from a flaw in the underlying interpreter.

Affected PHP versions and expected fixes

Tenable reports the following anticipated security releases. They are preliminary and not yet confirmed by the PHP project.

PHP 8.2 through 8.5 are currently supported upstream. Linux distributions may backport security fixes, so an older-looking version string does not automatically mean the installed package is unpatched.

Exploitation status as of October 21, 2026

• Confirmed: two critical vulnerabilities exist. The PHP security team acknowledged them and scheduled an emergency release.
• Research reproduction: partial. watchTowr says it reproduced CVE-2026-109618. That does not prove every public proof of concept works.
• Attacks: early activity reported. Cloudflare CTO Dane Knecht reported emerging attacks and the deployment of temporary WAF rules, including for Free-tier customers. This is not confirmation of widespread successful exploitation.
• Reliable public PoC: unverified. Exploit code is circulating, but Tenable has not validated it. Some files presented as exploits may contain malware: do not run them.

What to do right now

1. Inventory your PHP installations, prioritizing internet-facing servers, containers, managed hosting and third-party applications that embed PHP.
2. Prepare to install the official update as soon as it ships, restart PHP-FPM (or equivalent workers) and verify the runtime that actually serves requests.
3. Temporarily reduce exposure by restricting public access to non-essential PHP applications. For high-risk systems that cannot be patched quickly, consider temporary isolation.
4. Use temporary WAF protections, but do not treat them as a complete fix. Blocking multipart requests globally can break file uploads, checkout flows and other legitimate features.
5. Monitor for suspicious activity: unusual PHP worker crashes, unexpected child processes, abnormal outbound connections and suspicious POST traffic.

The session.upload_progress workaround

A configuration workaround widely shared online is to disable upload-progress tracking:

session.upload_progress.enabled = Off

Researchers and PHP maintainers caution that this is not a reliable standalone mitigation. Updating the PHP runtime remains essential.

Check your PHP versions

On systems you are authorized to administer, these commands are a good starting point:

# Command-line PHP version
php -v

# PHP-FPM version, if installed
php-fpm -v

# PHP packages on Debian/Ubuntu
dpkg -l 'php*'

# PHP packages on RHEL/Fedora
rpm -qa | grep -i php

Note that command-line PHP and the PHP runtime serving your website can be different versions.

SaaS and multi-environment teams: priorities

For teams running several environments, container images and third-party services, the main risk is the blind spot: a base image that is never rebuilt, a legacy service or an exposed internal tool. Rebuild and redeploy your images once the fix ships, verify the version actually served in production and track updates from SaaS vendors that rely on PHP. Continuous security validation then confirms the fix holds over time.

What PHP2Shell means for security assessments

This incident shows why prioritization must be evidence-based. A sound detection strategy separates potential exposure from confirmed vulnerability. Until validated detection methods exist, a scanner should not claim to have proven PHP2Shell from a PHP version banner or an accepted multipart request alone.

At HEXBOX, we prioritize PHP runtime inventory, authenticated package and version checks where possible, vendor patch-status verification and identification of potentially affected internet-facing assets. A finding is upgraded to “confirmed” only with reliable evidence.

Sources worth following

• PHP — official security announcement: the authoritative source for the release, the affected-version matrix and final technical details (php.net).
• CERT-EU — Security Advisory 2026-018: official European advisory covering both CVEs, the risk and immediate defensive recommendations.
• Tenable Research — PHP2Shell FAQ: expected patched versions, exploit claims, early attack activity and mitigations.
• JFrog Security Research: useful for vulnerability management, runtime inventories and evolving detection coverage.
• BleepingComputer: how the embargo was broken and what watchTowr disclosed.

Bottom line

PHP2Shell is a real and urgent security event, but the publicly reported exploit mechanisms are not yet fully verified. Inventory your PHP runtimes now, apply the official release as soon as it ships and confirm the process serving your requests has actually been updated.

Get your PHP exposure checked by HEXBOX