TechSoft

02 Nov 2026 · Engineering

When the Runtime Breaks: Lessons from October’s PHP and Node.js Vulnerabilities

By Tuyen Tran

When the Runtime Breaks: Lessons from October’s PHP and Node.js Vulnerabilities

If your product runs on PHP or Node.js, October 2026 was not a quiet month.

On 21 October, both platforms shipped emergency security releases on the same day. PHP fixed two critical flaws that let an attacker run code on a server without logging in. Node.js fixed ten issues, including one that can lead to remote code execution through ordinary HTTP decompression. Within a week, attacks against both were confirmed.

We work with PHP and Node.js every day, and so do most of our customers. This post explains what happened in plain words, why these waves keep coming, and the short list of things every product team should check this week.

Inside the October 2026 security releases

The October fixes were not in a plugin or one framework. They were in the runtimes themselves, the engine that every PHP and Node.js application sits on. That is why so many products were affected at once.

PHP ("php2shell"). Two critical flaws, both rated 9.2 out of 10, let an attacker run their own code on a server without logging in. Every PHP version back to 5.4 is affected, and WordPress, Drupal, Magento, Joomla, Laravel and Symfony sites are all exposed if they run a vulnerable PHP version. Attempts started on 17 October, four days before the fix was public. Some organizations, including Dutch government services DigiD and MijnOverheid, went offline until the patch was out.

Node.js ("Node2Shell"). Ten fixes, four rated high. The most serious sits in the Brotli decompression library that Node.js bundles. Researchers ran code on a server through an ordinary fetch() call and through an Express app reading a compressed request body. Even services that are not on the public internet can be reached, because the bug also triggers on responses from services you call.

npm supply chain. The runtime bugs come on top of a year of attacks on the packages Node.js apps install. Attackers took over maintainer accounts of popular libraries and published poisoned versions that ran the moment a developer or build server installed them.

Recent examples include Axios, one of npm's most used libraries, which shipped a remote access trojan in March; more than 140 packages of the Mastra AI framework, backdoored in June; and the ChainDrop worm, which spread through more than 1,300 npm package versions in August, stealing developer and cloud credentials as it went.

Confirmed in active use. On 26 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added both PHP flaws to its catalog of actively exploited vulnerabilities, followed by the Brotli flaw on 27 October. For any team running PHP or Node.js, these are no longer routine updates.

Why these waves keep coming?

None of this means PHP or Node.js are bad choices. They power a large share of the web, which is exactly why attackers study them. Four trends make 2026 different from earlier years:

  • AI finds bugs faster, on both sides. The researchers behind php2shell said they used AI models in their work. Defenders use AI to find flaws; attackers can use the same tools to turn a patch into an exploit within hours.

  • The gap between fix and attack is closing. The php2shell details leaked a day early, and attacks began before the official release. The Brotli fix had been public upstream since February 2026, giving attackers months to study it.

  • Old versions stay in production. PHP 8.1 and older, and Node.js 20 and older, received no official fix. Many products still run them because an upgrade was "on the roadmap".

  • Every app depends on hundreds of strangers. A typical Node.js product installs hundreds of packages, each maintained by people you have never met. When one maintainer account is stolen, every team that installs the next version inherits the problem.

There is also a quieter trap: patching the server is not the same as patching the product. Docker images, serverless functions and single-file Node.js builds each carry their own copy of the runtime. They stay vulnerable until they are rebuilt, and running PHP workers keep the old code in memory until they are restarted.

What it means for your business?

A runtime flaw is not only an IT ticket. For a product company it touches customers, contracts and regulators:

  • Data exposure, not just downtime. Researchers showed php2shell can read a server's working memory, where passwords, tokens and API keys live. A server that was exposed should be treated as possibly compromised, and its credentials rotated.

  • Customer trust. Enterprise buyers now send security questionnaires before they sign. "We patched within 48 hours, here is the record" is a sales asset. "We are not sure which version we run" is a lost deal.

  • Regulation in Europe. Since 11 September 2026, the EU Cyber Resilience Act requires makers of products with digital elements to report actively exploited vulnerabilities within 24 hours. Both PHP and Brotli flaws are now on the exploited list.

  • The cost of old versions. Running an end-of-life runtime turns every future security release into an emergency migration. It is cheaper to upgrade on your schedule than on an attacker's.

Seven things to check this week

You do not need a security team to start. Ask your engineers these seven questions, and get a written answer for each:

  1. Do we know every place we run PHP or Node.js? Include servers, containers, staging sites, build servers, developer laptops and serverless functions.

  2. Are we on a fixed version? PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. Node.js 22.23.4, 24.22.1 or 26.12.1 or later.

  3. Did we restart and rebuild? Restart every PHP worker after updating. Rebuild every Docker image and serverless package on a fresh base image.

  4. Are we on a supported version at all? If you run PHP 8.1 or older, or Node.js 20 or older, plan the upgrade now. PHP 8.2 support ends on 31 December 2026, so aim for 8.4 or 8.5.

  5. Do we lock our dependencies? Commit lockfiles, install with npm ci in builds, and wait a few days before adopting brand-new package versions.

  6. Should we rotate secrets? If a server ran a vulnerable version while exposed to the internet, rotate the passwords, tokens and API keys it held.

  7. Who gets the next alert, and how fast? Name one person who follows the PHP and Node.js security announcements, with a target time to patch.

How we handle it at TechSoft?

Security is part of how we deliver, not a separate project at the end. Our Delivery Playbook sets out the habits:

  • One owner for security. Our CTO looks after security and compliance on every engagement, so an alert like php2shell has a named person from the first hour.

  • Quality gates before production. Four gates stand between an idea and a release, including dependency and security checks.

  • AI with rules. We use AI-assisted engineering every day, but every AI-assisted change is reviewed by an engineer who understands it, and AI never approves a release.

  • Long-term care, not one-off builds. Through our product takeover and continuous engineering models, we keep runtimes, frameworks and dependencies current, so a security release is a routine update rather than a rescue.

Read the checklist, and tell us where you stand

If you could not answer every question with confidence, you are not alone. Most teams find at least one forgotten server, old image or outdated runtime when they look.

#Newsletter Subscribe

Subscribe our Newsletter to get more updates