PHP2Shell and Node2Shell: flaws that are neither new nor old, and why the patch is only the start

Imagine it is the morning of 22 October. The engineering team at an e-commerce company reads about PHP2Shell, updates PHP on the main server to 8.3.36 and reports: patched. A week later they realise three things were missed: the staging container is still built from an old image, a marketing site on shared WordPress hosting still runs PHP 7.4, and the Node.js service that receives webhooks (automated calls from other systems) from the payment gateway has not been touched — even though Node.js shipped an emergency fix that same day.

That scenario is hypothetical, but it is easy to end up in. PHP2Shell is not the kind of vulnerability you close with a single update. It is a reminder that old code is being re-read with new tools, and that patching has to reach every place the software actually runs.

What PHP2Shell is

PHP2Shell is the shared name for two critical vulnerabilities in PHP's own core: CVE-2026-109618 and CVE-2026-109619. A CVE (Common Vulnerabilities and Exposures) is the public identifier for a single vulnerability. Both allow RCE (remote code execution): an attacker sends a request to the server and can make it run their code.

• Where the bugs are: according to the PHP Foundation, both sit in parts nearly every web request passes through — memory management and error handling. These are PHP bugs, not bugs in your application code.
• Severity: PHP rated both 9.2/10 under CVSS 4.0 (Common Vulnerability Scoring System — the standard severity scale); security firm watchTowr rated it 10/10.
• Scope: the PHP Foundation says every PHP installation that handles web requests is potentially affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The bugs are present in nearly every release back to PHP 5.4.
• Side effect: according to write-ups by Tenable and The Hacker News, the flaws can also be used to read the PHP process's memory — which may hold database passwords, API keys and other secrets.
• Fixes: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are end-of-life and get no official fix.

PHP runs behind a very large share of websites — many reports put it around 70% — including WordPress, WooCommerce, Magento, OpenCart, Laravel and most shared hosting plans. So a bug in PHP's core touches almost every business with a website.

Neither new nor old

Calling PHP2Shell a new vulnerability is not quite right: according to Wiz, the underlying bugs had been in PHP's code for decades. Calling it old is not right either: nobody had published a way to exploit it until 2026.

According to international press reports, the bugs were found during an August 2026 code audit by security firm Calif, using OpenAI's GPT-5.6 Sol model, as part of an OpenAI programme that helps researchers find vulnerabilities with AI. Wiz and OpenAI also contributed. Calif said it had not expected to find anything critical, because PHP had already been reviewed thoroughly by many teams, including with AI.

Wiz described the key point: proving the bugs were exploitable required a very complex chain of steps, close to the limit of what human researchers can do by hand, and frontier AI models lowered that barrier substantially. In other words, the code did not change; the tool used to read it did.

The vulnerability is not "new" in the sense of freshly written. It is "new" in the sense of freshly seen — and from now on, things that have sat quietly for years will be seen faster.

How the days unfolded

• August 2026: Calif audits PHP's code with AI assistance and reports the bugs to the PHP team.
• Original plan: coordinated disclosure on 22 October.
• Around 20 October: details leak early; a demonstration video is posted and then removed. The PHP Foundation decides to ship the fix a day early.
• 21 October, 14:00 UTC (21:00 in Vietnam): PHP releases the fix. The same day, Node.js ships its own security release.
• After disclosure: Amazon records exploitation attempts on its MadPot sensor network; Cloudflare reports signs of early exploitation; a report in The Hacker News says someone attempted exploitation four days before disclosure. Public proof-of-concept code appears on GitHub.

Sources do not yet agree on how much real exploitation there has been. Recorded Future says available reporting does not establish how many systems were actually compromised. As of 22 October, CISA (the US cybersecurity agency) had not added either CVE to its Known Exploited Vulnerabilities catalogue. The PHP Foundation also acknowledged that the delay in handling was "a structural failure" of its decision process and its resources.

Why the patch is only the start

As of 22 October there was no public evidence that PHP's official fix can be bypassed; according to PHP2Shell FAQ round-ups, Germany's BSI information security agency refuted rumours that the patches were incomplete. What is incomplete is getting the fix to every place PHP runs. There are five common gaps.

1. An upstream fix is not a fix on your machine

PHP publishes fixed source code. Between that and your server sit several layers: Linux distributions repackaging it (Ubuntu, Debian, Red Hat...), official Docker images and the images your company builds, hosting control panels such as cPanel, HestiaCP or aaPanel. Each layer updates on its own schedule. After installing, the PHP-FPM or Apache processes must be restarted, or memory is still running the old code.

2. End-of-life versions get no official fix

PHP 8.1, 8.0, 7.x and 5.x receive no fix from PHP. For these, the only options are patches from extended-support vendors (TuxCare, for example) or community patches. Community patches need vetting before use on production systems. The durable path is upgrading the application to a supported PHP version.

3. Mitigations only cover part of the problem

Some guides recommend turning off upload progress tracking (session.upload_progress.enabled = Off in php.ini). According to The Hacker News, this blocks the confirmed session-based paths but not other variants. The PHP Foundation is explicit: mitigations reduce exposure but do not make an installation safe. A web application firewall (WAF) should likewise be treated as a temporary shield while you upgrade.

4. Memory may have been read before you patched

Because the flaws can leak memory contents, a server that accepted Internet traffic while unpatched should be treated as possibly having leaked secrets. After patching, you still need to change database passwords, API keys and session signing keys.

5. This may not be the last bug

When an AI-assisted bug-hunting technique pays off on a large project, many teams will apply it to neighbouring code and similar projects. Expect further rounds of fixes, and not only for PHP.

Node2Shell: the same day, in Node.js

Also on 21 October, Node.js shipped a security release fixing 10 vulnerabilities across all three supported release lines. The most notable is CVE-2026-111497, nicknamed Node2Shell: an out-of-bounds write in the Brotli decoder — Brotli being a common compression format on the web.

• Severity: Node.js rates it High; Singapore's Cyber Security Agency (CSA) lists it as 9.8/10 under CVSS 3.1; Google, as the CVE numbering authority, scored it 9.2 under CVSS 4.0.
• Scope: according to Astra Security, any Node.js application that accepts Brotli-compressed input may be affected; the built-in fetch asks HTTPS servers for Brotli compression by default. Beyond Node.js, Bun before 1.4.4, Envoy and several Python packages are also affected.
• The AI angle: the Node.js advisory credits Khai Tran and Sylvie Mayer of OpenAI Codex Security. According to OpenAI, a fix went into Brotli's source in February 2026 but was not classified as a security issue at the time — another example of a flaw that is "neither new nor old".
• Fixes: Node.js 26.12.1, 24.22.1 and 22.23.4. End-of-life lines such as 25.x, 23.x and 20.x get no fix.
• Exploitation status: Imperva researchers say they demonstrated code execution on an official Node.js build in a test environment; at the time the reports were written, no attacks in the wild had been recorded.

The release also includes TLS certificate hostname-check bypasses (CVE-2026-106069, CVE-2026-105483) and a DNS name-truncation bug (CVE-2026-105482), all rated High. For systems that call third-party APIs over HTTPS, that is another reason to upgrade soon.

AI is changing the pace of patching

Two events on the same day show a trend: AI helps find deep bugs in foundational code faster than before. Defenders benefit because the bugs get found and fixed. But the window between disclosure and working exploit code is also shrinking — with PHP2Shell, public proof-of-concept code appeared within days.

For businesses, that means a "patch every quarter" schedule is no longer enough. You need to know exactly which version runs where, and have a process that gets critical fixes into production in days rather than months. We covered this principle in our post on security for AI-enabled systems: automated dependency checks in CI are a minimum guardrail, not an option.

Checklist

Within 24–48 hours

• List every server, container and hosting account with PHP or Node.js; run php -v and node -v on each, including inside containers
• Prioritise services that take requests straight from the Internet: websites, public APIs, webhooks
• Install the fixed release (PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35; Node.js 26.12.1 / 24.22.1 / 22.23.4) or your Linux distribution's matching security update
• Restart PHP-FPM, Apache, LiteSpeed and Node.js services, then check the running version again
• For shared hosting or managed services, ask the provider in writing: patched yet, which version, when

Within the week

• Rebuild every Docker image from a fixed version tag and redeploy, staging and scheduled jobs included
• Rotate database passwords, API keys and session signing keys on PHP servers that were exposed while unpatched
• Review server logs from 17 October onwards: look for repeated abnormal PHP-FPM worker exits, unusual upload requests, or new files appearing in web directories
• Turn off expose_php so the server does not advertise its PHP version in HTTP responses

Within the quarter

• Plan upgrades for every application still on PHP 8.1 or earlier, or Node.js 25.x, 23.x, 20.x
• Add version and dependency vulnerability checks to CI, blocking deploys on critical findings
• Subscribe to security announcements from PHP, Node.js and your Linux distribution; name one person responsible for reading and triaging them

A patch is only worth something once it reaches where the software actually runs. A version inventory matters as much as the patch itself.

How KonexForge can help

KonexForge's Development team helps businesses inventory PHP and Node.js versions across servers, containers and hosting; upgrade applications off end-of-life versions; rebuild images and deployment pipelines; and add dependency checks to CI so the next round does not mean chasing the news.

Conclusion

PHP2Shell and Node2Shell are not freshly written bugs, nor old known ones. They are bugs that sat in the code for years and that AI has just helped bring to light. The fixes have been out since 21 October, but patching is only done when every server, container and hosting account runs a fixed version, possibly leaked secrets have been rotated, and the build pipeline warns you automatically next time.

If you need a quick inventory or an upgrade plan for your PHP and Node.js systems, get in touch with KonexForge.