PHP2Shell: two critical flaws in the code every request runs.

The two vulnerabilities

PHP’s security advisory states the problem without hedging: the four releases “fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.” The flaws are widely called php2shell — the name CISA uses in its alert.

The PHP Foundation’s account of what was demonstrated is the clearest statement of severity. For CVE-2026-109618: “On Apache with mod_php, an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings. Remote code execution was also confirmed on PHP-FPM through application-level code paths.” For CVE-2026-109619, a worker crash was confirmed and the reporter demonstrated code execution “against a real-world application running on Apache with mod_php”.

Who is exposed

PHP lists “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, and adds: “We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

And it is not only websites that call themselves “PHP sites”. CISA’s alert makes the point that “PHP is often a component of other software and prevalence may not be directly observable” — admin panels, monitoring consoles, appliances and vendor products ship their own PHP.

Fixed versions — and the end-of-life question

CISA is blunt about unsupported versions: organisations that cannot update, “or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated.”

The backport trap: a lower version number can be the patched one

Linux distributions received the patches in advance and fix their own packages without changing the upstream version number. A version-only check will therefore get these hosts wrong in both directions.

The reverse case matters just as much. PHP from a third-party repository — Ondřej Surý’s builds being the commonest on Debian and Ubuntu — follows upstream numbering, so on those hosts a version below the fixed release really is vulnerable, even though the package name looks like the distribution’s own. Sury published fixed builds for PHP 7.4 through 8.5 on 21 October.

How to find every PHP that is serving requests

Three facts make PHP inventory harder than it looks. The CLI on the PATH is not necessarily the PHP that serves the web. One server often runs several PHP-FPM versions side by side. And a patched package does nothing until every worker has been restarted.

Two shortcuts to avoid. The X-Powered-By header shows a version only when expose_php is on — most hardened servers turn it off, and on distribution builds it shows the misleading upstream number anyway. And a Composer config.platform.php value describes what the project was resolved against, not the runtime it is running on.

If you cannot update immediately

PHP’s position is unambiguous: “while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.” In summary:

For CVE-2026-109618

• Set memory_limit=-1 in a way applications cannot override (php_admin_value in the FPM pool or Apache configuration), and check that no pool, directory or application setting puts a finite limit back. PHP notes an underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size: 8M where uploads are not needed, 32M where they are, with upload_max_filesize below it.
• Enforce request limits at the web server or proxy — decoded size, input-field count, multipart part count, header count and nesting depth — including for requests without a usable Content-Length.
• Use a container or cgroup memory limit as an availability boundary. PHP warns specifically not to substitute RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure.

For CVE-2026-109619

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration — not with ini_set() or .user.ini — and restart every worker. PHP: “This blocks the confirmed session paths but not other variants.”
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks one confirmed path only.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialisation. Suppressing diagnostics with error_reporting, display_errors or @ does not help.
• Fix the fatal-error conditions and execution time-outs an attacker can reach — in callbacks, upload and import processing, and cleanup.

A web application firewall can buy time. Cloudflare enabled rules for all plans, including free, from 03:02 UTC on 21 October, and AWS published AWS WAF guidance. Cloudflare itself reported attackers mutating payloads to get past its rules, and CISA says only that a WAF “may provide some protection”. It is a bridge to the update, not a replacement for it.

A disclosure that did not go to plan

Exploitation status, as of 23 October 2026

The public record says two different things, and both are accurate. Attempts are enormous. Cloudflare’s chief executive, Matthew Prince, said on X that the company saw thousands of exploitation attempts in the ten hours before the announcement, tens of thousands within 45 minutes of disclosure, hundreds of thousands within two hours, and millions since (as reported by The Register). CERT-In’s note states that “multiple reports confirm large scale exploitation in the wild”.

Confirmed successful compromise is less clear. CISA wrote that it “has not observed successful exploitation of these vulnerabilities in the wild as of the time of publication”, and neither CVE was in its Known Exploited Vulnerabilities catalogue on 23 October. The gap between “attempted” and “confirmed” usually closes in days, not weeks. Treat any unpatched, internet-facing PHP as presumed targeted, and follow CISA’s advice to watch for “PHP worker processes launching shells or downloading tools”.

CVE-2026-115560: the third vector the patch does not fix

On 23 October PHP published an informational advisory: “We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector.” It affects fully patched releases, including 8.5.12.

The preconditions are narrow. An application must set session.serialize_handler to php_binary or php_serialize in configuration, then switch it to php at runtime with ini_set() before calling session_start() — with session upload progress still enabled. Applications that never change the serialize handler at runtime are not affected. PHP will publish a full advisory with the next regular release. If you already applied the CVE-2026-109619 mitigation, it covers this too.

How SemperWise helps