PHP2Shell: Why a Hardened CMS Still Leaves Your Server Exposed

A hardened WordPress install, a curated plugin list and two-factor authentication will not stop PHP2Shell. The two vulnerabilities patched on 21 October 2026 live inside the PHP interpreter, which parses every request before a single line of application code runs. Fixes shipped in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, tracked as CVE-2026-109618 and CVE-2026-109619 and rated 9.2 under CVSS 4.0.

• Every SAPI is exposed: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed all serve vulnerable requests, with mod_php carrying the highest risk.
• No credentials needed: one crafted HTTP request can achieve remote code execution, leak tokens and private keys from process memory, or kill workers outright.
• Patching is the beginning: end-of-life branches get no official fix, and admins must restart services and hunt logs for earlier intrusions.

The engine, not the CMS, is the attack surface

CVE-2026-109618 abuses out-of-memory handling: when a request crosses its memory limit, PHP aborts mid-operation, leaves request data partially initialized and later treats that broken state as valid. CVE-2026-109619 is a use-after-free where request-scoped globals survive the freeing of their memory and are read by a later request on the same worker. A crafted multipart upload — a part with a huge number of headers, or many empty file fields — forces the first condition while staying inside normal upload limits.

Because the flaw sits beneath the application, the stack above it is irrelevant. Researchers demonstrated exploits against WordPress, Drupal, Joomla, Magento, Laravel, Nextcloud, phpMyAdmin, MediaWiki, Roundcube, Symfony and WHMCS; even a bare “Hello World” script is exposed. Updating a CMS never updates PHP — the interpreter arrives from the distribution package, the host image or the container base layer.

Code execution, memory leaks and downtime

The headline impact is unauthenticated remote code execution with the web worker’s privileges. Under mod_php, PHP’s own worst-case scenario, the attack fires before application code runs, so strong passwords and second factors never come into play. Less dramatic but equally damaging: the upload-progress handler can hand freed worker memory back to a client, exposing passwords, session tokens, API keys and TLS certificates belonging to other requests.

“These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history.”

Wiz, which found the bugs using its Atlas tooling and frontier models, compared the leak to Heartbleed and warned it works even when an application never uses sessions; a stolen PHPSESSID cookie skips the login form entirely. The same corruption paths can also terminate workers, enough to knock a store offline mid-trade. Palo Alto Networks’ Cortex Xpanse counted more than 22.6 million internet-facing instances potentially exposed.

Patch, restart, then check for intruders

Disclosure ran on a compressed schedule. On 20 October, around 15:00 UTC, the identifiers began circulating with fabricated release times and inflated scores, and one reporting firm mistakenly published a proof-of-concept video; the PHP Foundation pulled the release forward to 14:00 UTC on 21 October. Cloudflare had WAF rules live from 03:02 UTC, free tier included, after spotting attack traffic earlier that morning. Dutch services DigiD and MijnOverheid disconnected as a precaution, payroll provider BambooHR halted service in the US, Canada and Ireland, and researcher Kevin Beaumont called it one of the biggest vulnerabilities in years.

Distribution packages for AlmaLinux 8, 9 and 10 reached production repositories within hours; the volunteer-run Remi repository had nothing on release day. PHP 8.1 and earlier receive no official patch, 8.2 loses support on 31 December 2026, and minimal source backports exist for 7.4, 8.0 and 8.1. Interim mitigations — disabling session upload progress, setting memory_limit to -1, or rejecting multipart/form-data at the web server — narrow specific paths and break file uploads. Core developer Gina Peter Banyard insisted the only real mitigation is updating PHP, while the UK’s NCSC suggests taking systems offline when nothing else is possible.

After upgrading, restart Apache, PHP-FPM and long-running PHP processes or the old binary keeps answering. Confirm the version from a PHP response rather than the command line, then reconcile memory_limit and post_max_size with what the application actually needs, since the patch now kills any process that hits the cap. Hunt logs for multipart requests followed by memory-limit errors, repeated HTTP 500s, oversized PHPSESSID cookies and unexplained worker restarts.

The strategic lesson is uncomfortable. Memory-safety exploitation in PHP once demanded rare expertise; Wiz credits frontier models with compressing months of research into about a week, dragging the gap between patch and attack down to hours. A site with every plugin current but an unpatched interpreter is not secured — it is a reinforced door on an open foundation, and the foundation is exactly what attackers target.