Blog

Node2Shell: Node.js Would Like an Update Too

Node.js security releases fix a Brotli remote code execution flaw and several DNS, TLS, HTTP, cryptography, and permission-model vulnerabilities.

Dmytro
nodejs node2shell cve-2026-111497 brotli

Node2Shell: Node.js Would Like an Update Too

The Node.js project has published security updates for ten vulnerabilities, including several high-severity issues and a Brotli decoder flaw that can lead to remote code execution.

The most attention is going to CVE-2026-111497, already nicknamed Node2Shell. The name may sound like a sequel released unusually quickly, but the fix is very real: update Node.js to 22.23.4, 24.22.1, or 26.12.1, depending on the supported release line you use.

This applies whether Node.js runs directly on a VDS or dedicated server, inside a container, as part of a development platform, or quietly inside another product whose interface never mentions JavaScript.

A compressed route to memory corruption

Brotli is a compression format commonly used to reduce the size of web traffic and other data. Node.js includes a native Brotli decoder and exposes it through node:zlib. Applications may call it directly, but they can also reach it indirectly when processing compressed HTTP data.

The vulnerability is an out-of-bounds write. A malformed Brotli stream can put the decoder into an invalid state that it mistakes for a request for more input. Processing continues, and bytes may be written beyond the end of a small internal buffer. The result can be a process crash, disclosure of process memory, or execution of attacker-controlled code with the permissions of the Node.js process.

There are several practical routes to the vulnerable decoder:

  • an application explicitly decompresses untrusted data through node:zlib;
  • middleware such as Express 5 or body-parser 2.x accepts a request body with Content-Encoding: br and decompresses it;
  • the built-in fetch() function receives a Brotli-compressed response from an external or compromised server.

A plain Node.js HTTP server does not automatically decompress every incoming Brotli body. That detail affects exposure, but it does not make running a vulnerable runtime a sensible long-term plan. Dependencies and application behavior change, and the October release also fixes vulnerabilities unrelated to Brotli.

Imperva’s researchers demonstrated code execution using the official Node.js 24.22.0 Linux arm64 image. They tested both incoming Brotli request bodies and compressed responses consumed by fetch(). Their exploit did not succeed on every attempt, but the same input was rejected by the fixed Node.js 24.22.1 release.

That is enough evidence to skip the traditional meeting about whether the patch can wait until next month.

More than one bug was fixed

Node2Shell is the most dramatic item, but the October 21 Node.js security release contains several other important fixes.

Three high-severity issues affect hostname handling and certificate validation. One allows a NUL character in a name passed to dns.resolve*() to truncate the actual DNS query after application validation. Two others involve unusual representations of IP addresses, including fullwidth digits and leading-zero forms, which can cause Node.js to validate a TLS certificate against a different interpretation of the address.

The release also corrects problems involving HTTP keep-alive response handling, repeated random values in startup snapshots and single executable applications, ZIP validation, and filesystem restrictions in the Node.js Permission Model. Bundled dependencies including c-ares, OpenSSL, SQLite, Undici, and the root certificate store were updated where applicable.

In other words, even an application that never touches Brotli still has good reasons to install this security release. The Centre for Cybersecurity Belgium likewise recommends patching affected Node.js installations immediately and checking systems for suspicious activity.

Which versions contain the fixes?

Install at least the following version for the release line in use:

  • Node.js 22.x: 22.23.4
  • Node.js 24.x: 24.22.1
  • Node.js 26.x: 26.12.1

Node.js 22 and 24 are LTS lines, while 26 is the current release line at publication time. Node.js 25, 23, 20, and older lines are end of life and did not receive these releases. If an application still depends on one of them, move it to a supported line rather than looking for a reassuring version number that does not exist.

If Node.js came from a Linux distribution repository, install the security update supplied by that distribution. Some distributions build Node.js against their system Brotli library and may backport the correction without using the upstream Node.js version number. Check the distribution’s security advisory and complete package revision.

If you use nvm, fnm, Volta, or another version manager, remember that each user and project may have its own runtime. Updating the system package does not replace versions installed in a home directory or downloaded during a CI job.

Containers need updates, not encouragement

A container does not make a vulnerable runtime safe. It limits some consequences when isolation is configured correctly, but code execution inside the application container can still expose its data, credentials, network access, mounted volumes, and connected services.

Check the version inside the image and the running container:

node --version
docker run --rm --entrypoint node your-image --version
docker exec your-container node --version

Update the base image to a fixed Node.js tag, rebuild without relying on a stale build cache, redeploy every replica, and verify the running version. Rebuilding an image pinned to node:24.22.0 will faithfully give you a fresh copy of the same vulnerable runtime. Computers can be very obedient in unhelpful ways.

Do not forget CI runners, build containers, serverless functions, scheduled jobs, staging environments, and old replicas that are still registered behind a load balancer. An updated Dockerfile is only a plan until the resulting image is deployed.

When Node.js is hidden inside another application

Many desktop applications, control panels, development tools, automation platforms, and network services include Node.js or ship a complete runtime with their own files. You may be using Node.js without having installed a nodejs operating-system package at all.

In that situation, follow the product developer’s or vendor’s security instructions. Install the corrected product release or appliance firmware they provide. Replacing an embedded node binary by hand can break native modules, signatures, update mechanisms, and vendor support while still leaving another bundled copy untouched.

Ask the vendor which Node.js or Brotli build the product contains, whether CVE-2026-111497 and the other October 2026 vulnerabilities affect it, and which product version includes the fixes. If no update is available, reduce public exposure according to the vendor’s guidance and decide whether the product can safely remain in service.

The same rule applies to managed platforms. Confirm the runtime selected in the platform configuration and trigger a new deployment after changing it. A setting in a dashboard does not retroactively rebuild yesterday’s deployment.

Update, restart, verify

A practical update process is short:

  1. Inventory Node.js on hosts, in containers, in CI, and inside vendor products.
  2. Upgrade every supported line to 22.23.4, 24.22.1, 26.12.1, or newer.
  3. Move end-of-life Node.js installations to a supported release.
  4. Rebuild and redeploy containers and other packaged artifacts.
  5. Restart Node.js services and worker processes.
  6. Verify the runtime version in the actual running environment.
  7. Test application behavior and review logs for unexpected crashes or decoder errors.

The Node.js advisory does not offer a complete workaround for the Brotli flaw. Temporarily rejecting inbound requests with Content-Encoding: br can reduce one exposure path, but it does not protect an application that fetches a malicious Brotli response. A WAF can provide another temporary layer, not repair the decoder inside the runtime.

Node.js often disappears beneath frameworks, containers, dashboards, and vendor branding. The vulnerability does not disappear with it. Update the runtime wherever you control it, rebuild every container that carries it, and follow the vendor’s instructions wherever you do not.

Need Help?

Our support team is available 24/7 to assist you with any questions or issues.

Contact Support