PHP2Shell: the hole is in PHP, not in your WordPress theme

On 21 October 2026 the PHP security team published two advisories. Not a forgotten plugin. Not a pirate theme. The engine. Two identifiers — CVE-2026-109618 and CVE-2026-109619 — rated CVSSv4 9.2 by PHP itself. The nickname going around, php2shell, is the outcome: an HTTP request, no password, and the PHP worker can run code. Or read process memory.

Figures first, jargon second.

The figures, with sources

W3Techs, October 2026: PHP is used by 69.2% of websites whose server-side language is known. WordPress sits on 39.5% of all websites (58.3% of tracked CMS). Drupal, Joomla, Laravel, Magento, PrestaShop, MediaWiki: same stack. Wiz, which took part in the research, talks about an engine that “powers 70% of the Internet”. Same order of magnitude. This is not a niche CMS.

On raw exposure these are estimates, not a census: one researcher (Silas Cutler) puts over 1.3 million internet-facing hosts in play; a Shodan count cited by Tenable tops 1.9 million visible PHP hosts. That is not 1.9 million breaches. It is a wide surface that will not wait for your next steering committee.

CISA pushed the patch on advisory day, and added both CVEs to its KEV catalogue on 26 October 2026 — flaws whose exploitation in the wild is treated as established. Amazon Threat Intelligence saw an attempt on its honeypot network on 17 October, four days before the public note. Then “broad exploitation attempts”. Cloudflare was already talking about early attacks on the 21st, with the WAF as a stopgap.

The bill if it lands: IBM’s Cost of a Data Breach 2025 (Ponemon) puts the global average at USD 4.44 million. France sits around USD 3.73 million. Vulnerability exploitation, in the same report, is not the cheap scenario: USD 4.24 million on average. That is not the price of a WordPress site. It is investigation, downtime, counsel, and a run you have to rebuild.

• 69.2% of sites with a known server-side language run PHP (W3Techs, Oct 2026).
• 9.2 CVSSv4, both CVEs, PHP security team’s score — not the leaked 10.0.
• 17 Oct first attempt seen by Amazon TI, before the 21st advisory.
• $4.44M average breach cost, IBM 2025. France: about $3.73M.

What it is (and what it is not)

Calif and Wiz describe two defects in the runtime, old ones — the incriminated path goes back at least to PHP 5.4. One (109618) shows up when an allocation exceeds memory_limit: cleanup treats half-born structures as valid. The other (109619) is leftover state between two requests on the same worker: freed memory, still pointed at, later re-read. PHP confirms, for 109619, memory disclosure on top of code execution.

Anything serving HTTP in PHP is in scope: mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. PHP rates the risk highest on mod_php. Researchers showed unauthenticated code execution on current WordPress, Drupal and Joomla images. Trail of Bits later confirmed working exploits against unpatched PHP 8.2 to 8.5, including MediaWiki, Symfony, Laravel, phpBB. The CMS is not the bug. It is the scenery.

Fixed versions, PHP advisory 21 October 2026: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Below that (8.1, 8.0, 7.x), no official release; minimal source backports exist for 7.4–8.1, for the distro vendor to glue in. Windows had a second train of builds (bundled Brotli, another CVE). Debian, Ubuntu, RHEL packages: read the vendor note, not only php.net.

Impact, in practice

With no account and no vulnerable plugin, an internet-facing PHP site can be an entry point. The process often runs as www-data or apache. That is not root on day one. It is already:

• reading secrets that sit in memory (tokens, database passwords, API keys) — Wiz showed this without going as far as execution;
• dropping an implant in the web tree, hence the name php2shell;
• encrypting, exfiltrating, or bouncing into the MySQL, SMTP or file share the app is allowed to see;
• in cases reported by security press (Dream Research, 26–28 October), chaining another system flaw to aim at root — including on exposed appliances. This is not a recipe. The point is: the first shell is not the end of the film.

For a mid-market firm, the business stops when the shop front, Moodle, PrestaShop or the WordPress intranet dies — or, worse, still answers and serves something else. NHS England rated the threat high on the 21st, naming WordPress, Drupal and Joomla as integration examples, not exceptions.

A useful assessment here is not “pentest the theme”. It is knowing which PHP version actually faces the internet, who patches it, and what you restore if you pull the plug.

How an attack can unfold

Not a how-to. A sequence, as public advisories describe it.

1. Target. A host speaking HTTP and PHP, often for years, sometimes on shared hosting. The attacker does not need a wp-admin login. They do not need your plugin to be rotten. They need the PHP binary to sit in the pre-21 October window — or on a dead branch.

2. Contact. One or more HTTP requests, unauthenticated. On mod_php, PHP says this can fire before application code. Meaning: WordPress’s index.php has not decided yet. The worker has.

3. Internal state. Depending on the CVE, either a memory condition (limit hit, half-initialised structures) or leftover state from a previous request in the same process. This is not “a PHP file uploaded badly”. It is the engine’s cleanup getting it wrong.

4. Result. Execution as the worker, or a read of what was sitting in RAM. Then, in public observations: an interpreter spawned from the PHP process, tools downloaded, sometimes a second stage. CISA explicitly asks to watch for PHP workers launching a shell or downloading tools.

5. After. If nobody watches processes or files in the web root, the incident lasts. IBM repeats it year after year: cost follows time to detect and contain, more than the CVE name.

Two cautions for teams: “PoCs” that show up after a CVE-id leak are often hostile to whoever runs them. The PHP team wrote they had not seen a working exploit at publication; other labs later confirmed chains that worked against pre-patch versions. That is not an invitation to collect them. It is a reason to assume the window has been open since at least 17 October.

What to do (defensive)

Patch. Restart. Inventory. CISA is blunt: find PHP everywhere — including when it is buried in a product (firewall, NAS, admin console) — and put internet-facing first. A WAF helps for the length of the patch train. It is not the fix.

Check the version being served, not the one on the contractor’s laptop. phpinfo in prod is not a strategy; a header, a package, a ticket to the hoster, if need be.

Dead branches (8.1, 7.4 still visible at some vendors): migrate or take the vendor backport. Staying on EOL in 2026 is not debt. It is a choice.

100% security does not exist

You will patch PHP2Shell. There will be another one. The engine is decades old; research now also uses models to push chains nobody had the hours to finish by hand — Calif and Wiz say so themselves. Believing a green scan score means an untouchable SI is exactly the reflex these two CVEs break: the application was “clean”. The runtime was not.

So you do not rest on the absence of a bug. You rest on three less glamorous things.

The recovery plan. Backups off the same disk, actually restored in the last twelve months, with a delay the board has heard. Who pulls DNS. Who tells customers. A PrestaShop or WP back in four hours is not magic. It is a drill. Without that, Friday night’s patch is a hope.

Fast detection. Web logs, processes (PHP with no business spawning a child interpreter), web-root integrity, odd outbound traffic. CISA already wrote the operational signature: worker launching a shell, worker downloading. If nobody reads that at the weekend, the attacker has a two-day head start — and IBM bills you the average.

Watch on the projects, not only “the CMS”. PHP version of the base, the container, the Docker image copied 18 months ago, the business-software module that ships its own lib. Subscribe to PHP advisories, distro packages, CISA KEV. A SRE run with a spine holds that without twenty tools. A maintenance contract that never looks at the runtime sells cosmetics.

At IT Empower we do not promise invulnerability. We promise a map: which stack, which version, which backup, who is awake at 02:00. If the list does not exist, it comes out of a fixed-price assessment. The deliverable is not “you are safe”. It is: here is what breaks, here is what we restore, here is what we watch until the next advisory.

PHP2Shell does not invent the lesson. It invoices the people who thought the theme and the plugins were enough.