Node.js: Brotli decoder RCE flaw and TLS verification bypasses

Why this batch of fixes is more urgent than usual

Node.js bundles its own copy of the Brotli library and uses it whenever an application decompresses data in that format. CVE-2026-111497 is an out-of-bounds write in that decoder. A crafted Brotli stream can corrupt process memory, disclose parts of it, crash the application and, in the worst case, execute attacker code. Node.js rates the flaw High. In NVD, Google as the CNA assigned it 9.2 on the CVSS 4.0 scale, and the record is still awaiting NVD analysis.

As of October 22 there were no reports of attacks or a public exploit, and the flaw is not in the CISA KEV catalog. Node.js has not given detailed attack conditions, so the risk depends on how your applications use compression.

Who is really exposed

The most exposed are applications that decompress data outside your control:

• services that call the Brotli functions of the zlib module on data from users or external systems, for example when accepting compressed files or request bodies;
• applications that fetch content from third-party servers: API integrations, proxies, crawlers, webhook handling. An HTTP client that automatically decompresses responses with a Content-Encoding: br header passes whatever the other side sends straight to the decoder.

An application that only compresses with Brotli, for example serving compressed static files, does not feed foreign data to the decoder and is less affected by this flaw. The other fixes still apply to it.

Three more High-severity flaws hit outbound connections. Two of them allow bypassing the TLS hostname check, and the third breaks resolution of DNS names containing a NUL character. This matters for applications that connect over TLS to addresses supplied from outside (e.g. a webhook URL entered by a customer) or directly to IP addresses. In those cases a connection may accept a certificate that should have failed verification.

What to patch today and what can wait for the next maintenance window

• Today: internet-facing services that decompress user data or fetch content from external servers, and applications that connect over TLS to addresses outside your control.
• Next window: internal tools, front-end build processes and CI jobs that do not process foreign data.
• Separate plan: everything on Node.js 18 and 20, as these lines will not get a fix.

Fixed versions

• Node.js 22.x: 22.23.4
• Node.js 24.x: 24.22.1
• Node.js 26.x: 26.12.1
• Node.js 18, 20, 23 and 25: End-of-Life versions, no fixes. The Node.js project states that EOL versions are always affected when a security release occurs.

The remaining flaws in brief. High: CVE-2026-105482 (dns.resolve truncates names containing a NUL character; 22.x, 24.x, 26.x), CVE-2026-105483 (hostname check bypass when the IP is written in fullwidth digits; 24.x, 26.x), CVE-2026-106069 (bypass of the same check when the host loosely resolves to an IP address; 22.x, 24.x, 26.x). Medium: CVE-2026-105481 (keep-alive), CVE-2026-106072 (DNS names in a certificate authenticate IP endpoints written in non-canonical form) and CVE-2026-106074 (crypto.randomUUID() and randomInt() repeat values in startup snapshots and SEA applications). Low: CVE-2026-106070 (ZipFile, 26.x only), CVE-2026-106071 and CVE-2026-106073 (Permission Model).

Where old Node.js tends to hide

Running node -v on a server is the easy part. Anything lower than v22.23.4, v24.22.1 or v26.12.1 within its line is vulnerable. It is harder to find Node.js that is not installed on the system:

• Docker images. The node:22-alpine tag contains whichever version was current when the image was built, so an older container has an old version. Check running containers: for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec $c node -v 2>/dev/null)"; done. Images pinned to an exact version, such as node:20.x.y, will never update themselves.
• Applications with a bundled runtime. Electron apps and SEA applications carry their own copy of Node.js, fixed only by a new release from the vendor.
• CI agents and build machines. They often have separate Node.js installations, set in the pipeline configuration or in a version manager.
• Hosting and serverless. The runtime version is chosen by the platform or a project setting. Check the selected line and whether the provider has already updated it.

Updating the system brotli package does not help, because Node.js uses its own copy of the library.

What to do, step by step

1. Update Node.js to 22.23.4, 24.22.1 or 26.12.1. The vendor has not published a workaround for the Brotli flaw.
2. Rebuild images on a freshly pulled base image (docker build --pull --no-cache) and redeploy them. Restarting a container does not change its Node.js version. New images, such as node:22.23.4-alpine, are already on Docker Hub.
3. If the update has to wait, check whether Brotli decompression can be switched off for now in services that accept external data.
4. After updating, watch the logs. Unexpected process restarts and decompression errors while handling external data need explaining.

The longer-term lesson

With releases like this, the longest part is finding forgotten places: an image built a year ago or a Node.js 18 application nobody remembers. An inventory of where Node.js runs, with its version and base image, shrinks this kind of exercise to hours. Pinning images to an exact version makes sense only when something regularly bumps that version and rebuilds the image. Lines 18 and 20 need a migration date to 22 or 24 LTS, because every new security release will add flaws to them that nobody will fix anymore.