PHP ships emergency patches for PHP2Shell RCE flaws as experts dispute exploitability

PHP pushes emergency fixes for PHP2Shell

On October 21, 2026, the PHP project shipped emergency security releases for two flaws in the runtime itself, tracked as CVE-2026-109618 and CVE-2026-109619 and quickly nicknamed PHP2Shell. According to a write-up from penetration testing firm Raxis, both bugs carry a CVSS v4.0 score of 9.2 and allow remote code execution without authentication. Because the vulnerabilities sit in PHP rather than in any application built on it, even sites with carefully audited code are exposed.

The Hacker News, cited by Raxis, reports that nearly every PHP release back to 5.4 is affected, including servers running Apache mod_php or PHP-FPM. Mod_php is the worst case, since a single request can trigger the bug before any application code runs. A dev.to post by Kyle Clouthier, who built a public version checker the morning the patch landed, notes that PHP's guidance also lists php-cgi, FrankenPHP and LiteSpeed as affected. Researchers separately demonstrated that the bugs can leak live worker memory, which could expose passwords and API keys belonging to other users' requests.

Exploitation reported before the patch

Cloudflare observed exploit attempts before the fixes were public, according to The Hacker News, and Raxis points to a CISA advisory urging immediate patching. Clouthier adds that technical details leaked the day before the release, that exploit code was circulating by the time the patch arrived, and that government sites in the Netherlands and Finland had already gone offline. The Dutch national CERT, NCSC-NL, is maintaining a guidance page for operators.

What to install, and the restart gotcha

The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Raxis recommends running php -v on every server and comparing against that list, with one caveat: Linux distributions often backport security fixes while keeping the old version string, so searching the package changelog for the CVE identifiers is more reliable. Containers and appliances that bundle their own PHP need checking too, and shared-hosting customers should ask their provider directly.

Installing the package is not the whole job. Clouthier highlights that PHP-FPM pools and Apache with mod_php keep the old binary in memory until they are restarted, and that control panels such as cPanel and Plesk frequently run several PHP versions side by side, each requiring its own update. Running composer update accomplishes nothing here, because the bug is in the runtime rather than in dependencies.

Where immediate patching is impossible, The Hacker News describes interim measures such as disabling session.upload_progress and enforcing request size limits at the web server or proxy. These reduce exposure without closing it; PHP itself says no configuration change is a complete fix, and Cloudflare calls its own protective rules a stopgap.

The end-of-life tail

Official fixed releases exist only for the 8.2 to 8.5 branches. Older branches get no packaged update — Clouthier reports only minimal source patches for people who compile PHP themselves — and PHP 8.2 reaches end of life on December 31, 2026, which is why Raxis recommends planning a move to 8.3 or newer. The tail is large: Detectify estimates that roughly half of PHP sites run versions that no longer receive patches, and of the 85 sites that exposed their version to Clouthier's checker on its first day, 30 were on end-of-life releases with nothing official to install.

Disagreement over how exploitable it really is

A widely shared blog post by Elias Taylor, which reached the Hacker News front page, pushes back on the alarm. He reports that the thousands of proof-of-concept exploits that appeared on GitHub within hours fail against a stock PHP installation, and that many depend on a pre-existing local file inclusion weakness, effectively requiring the target to already have a second vulnerability. He attributes the wave of broken exploits to LLM-generated code and argues the bug is not comparable to Log4Shell, noting that a PHP core developer's prediction of working exploits within minutes of the release had not materialised into a universal exploit in the first hours.

The accounts are not necessarily contradictory: Cloudflare's telemetry and the outage reports show real-world probing, while Taylor's argument is that reliable exploitation of an unmodified server is harder than the CVSS score implies. Either way, the practical advice from every source is the same: patch, restart, verify.

Why it matters

PHP2Shell is a reminder that the runtime underneath an application is part of its attack surface, and that responsibility for fixing it falls on hosts, platform teams and image maintainers rather than application developers. It also exposes how much of the web still runs on PHP branches that receive no security releases at all, making full remediation unlikely no matter how urgent the advisory. Finally, the episode is an early live test of exploit intelligence in the LLM era, where thousands of plausible-looking proofs of concept, most of them non-functional, can muddy the picture within hours of disclosure. For operators the calculus is unchanged: install the fixed release, restart every PHP worker, and inventory anything still on an unsupported branch.