Two of the most widely deployed web runtimes shipped critical fixes on 21 October. PHP2Shell, a pair of unauthenticated remote code execution flaws in the PHP engine, was being attacked before the patch existed, and the Node.js project fixed 10 vulnerabilities the same day, including an out-of-bounds write in its Brotli decoder.
If you run PHP, move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you run Node.js, move to 22.23.4, 24.22.1 or 26.12.1. For containerised workloads that means new base images, a rebuild and a redeploy of every service, and teams still on end-of-life branches such as PHP 7.x or Node.js 18 and 20 have no official fix to install.
What is PHP2Shell?
PHP2Shell is the name given to CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4. They are memory safety bugs in the PHP core. A fatal error, usually an out-of-memory condition, can leave corrupted state behind, and a later request handled by the same worker then uses it.
According to Help Net Security, every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Setups using mod_php are at the greatest risk, and an exploit reportedly needs a single unauthenticated request that fires before any application code runs.
That last point matters. Updating WordPress, Drupal or a framework does nothing here. The bug is in the runtime underneath them.
How did attacks start before the patch?
PHP had planned a coordinated release for 22 October. On 20 October a since-deleted post on Hacker News broke the embargo, and PHP moved the release forward a day, according to a timeline compiled by CybelAngel. Cloudflare's CTO reported early attacks at 07:43 UTC on 21 October. PHP shipped the fixes at about 13:35 UTC, just ahead of its 14:00 UTC schedule.
So attackers had a head start of roughly six hours on everyone who waited for an official release. Cloudflare pushed WAF rules to all plans, including free, but said attackers were already changing payloads to get around them.
Wiz Research, which found the bugs with help from AI models, said a single researcher did in a week what used to take a team months. The researchers built working pre-authentication exploits against the latest container images of WordPress, Drupal and Joomla. If finding and weaponising runtime bugs keeps getting cheaper, the gap between leak and attack will keep shrinking.
Why are end-of-life PHP branches the real problem?
PHP 7.4, 8.0 and 8.1 received only minimal source patches, not official releases. PHP 7.3 and older got nothing.
That would be a footnote if few people ran them. They do. Shodan data gathered on 20 October and analysed by CybelAngel counted about 2.24 million internet-facing hosts advertising PHP. Of roughly 1.5 million that show a version, 883,717, or 59%, run a branch with no official fixed release. That includes 368,570 hosts on PHP 5.x and 329,358 on 7.x.
Some distributions backport fixes, so a version string does not always tell the whole story. But the UK's NCSC advice for systems that cannot be patched quickly was blunt: take them offline.
What did the Node.js release fix?
The Node.js security release on 21 October fixed four high, three medium and three low severity issues.
CVE-2026-111497: an out-of-bounds write in the bundled Brotli decoder. An attacker who can send Brotli data that an app decompresses with
node:zlibcan corrupt memory, which may lead to remote code execution.CVE-2026-105483 and CVE-2026-106069: TLS hostname check bypasses using unusual IP address spellings, such as fullwidth digits or leading zeros.
CVE-2026-105482: DNS lookups that cut hostnames off at a NUL byte, which can defeat allowlist checks.
The release also updates the bundled CA store to drop trust in the compromised eMudhra intermediates. Node.js 18 reached end of life in April 2025 and Node.js 20 in April 2026, so neither got any of this. The project states plainly that end-of-life versions are always affected when a security release ships.
Why patching a runtime means rebuilding every image
On a VM, a runtime patch is a package update and a restart. In containers, the runtime is baked into each image. Nothing changes until every image is rebuilt on a patched base and redeployed.
That turns one CVE into a fleet job. A few habits make it survivable:
Know which base image and runtime version each service runs. Your image scanner or SBOM should answer this in minutes, not days.
Pin base images by digest and let automation open the update pull requests, so a rebuild is a merge rather than a project.
Rebuild Node.js single executable apps and startup snapshots, which carry their own copy of the runtime, as the Node.js advisory notes.
After deploying, check the version running in production, not the one in the Dockerfile.
The services that will hurt are the ones nobody has rebuilt in two years, sitting on PHP 7.4 or Node.js 18. Put a date on retiring them before the next leak does it for you.
Quick answers
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 7.4, 8.0 and 8.1 got only minimal source patches, and 7.3 and older got nothing.
Which Node.js versions fix the October 2026 security release?
Node.js 22.23.4, 24.22.1 and 26.12.1. Node.js 18 and 20 are end of life and received no fixes, and the project says end-of-life lines are always affected.
Is updating WordPress or my npm packages enough?
No. PHP2Shell is in the PHP engine and the Node.js fixes are in the runtime itself, so you need a new runtime. In containers that means a patched base image, a rebuild and a redeploy.
