A malicious response can take over the Node.js server that requested it

Malicious Brotli responses can reach vulnerable native code before application logic inspects the body.

The short version

Node.js services can be compromised when they decompress malicious Brotli, including responses fetched from attacker-controlled or configurable destinations.
Fixed releases are Node.js 22.23.4, 24.22.1, and 26.12.1; Node 20 requires migration rather than a standard fix.
Operators must rebuild runtime-containing artifacts, verify deployed binary versions, and audit Brotli decompression plus unusual hostname handling.

A Node.js server can get owned by a response it requested. Your backend fetches an ordinary-looking URL, receives malicious Brotli data, and hands it to vulnerable native code before your application even sees the body.

I initially assumed inbound request parsing defined most of the exposure. Wrong. Fetched responses deserve equal attention, especially anywhere users can configure URLs.

Red Hat rates the attack complexity High and says there is no public, reliable remote-code-execution proof of concept. Comforting, until you read Imperva’s work. Its Red Team demonstrated code execution in fresh Linux arm64 containers using the official vulnerable Node.js build, fetched Brotli responses, and configured request parsers. The exploit needed multiple attempts and didn’t cover every build or application. Retool, meanwhile, found no indication of malicious activity in its environment.

Patch the runtime, rebuild every artifact containing it, and audit anything that decompresses untrusted Brotli data. An npm update cannot replace the vulnerable binary underneath your application. I wish package managers had that kind of magic, but npm already has enough crimes on its résumé.

Use the fixed release for your supported line:

On the 22.x LTS line, replace earlier affected releases with 22.23.4 or newer.
On the 24.x LTS line, replace earlier affected releases with 24.22.1 or newer.
On the Current line, replace earlier affected releases with 26.12.1 or newer.

If you’re still on Node 20, you have a different job. Unlike the supported lines above, that branch received no standard fix in the October security release. Migrate it.

Eight bytes and one catastrophically vague answer

The Node.js Brotli RCE begins with a decoder giving the wrong answer to a very specific question. A crafted stream reaches a block switch that cannot be valid under the stream’s structure. The vulnerable decoder reports that condition as a temporary need for more input, a routine event during streaming, instead of returning a permanent format error. Its caller preserves the state and supplies more bytes. Input keeps accumulating around an internal 8-byte buffer even though decoding should have stopped. Continued processing can write past that buffer and corrupt adjacent process memory. JavaScript’s memory safety cannot rescue a process after bundled native code has wandered off the map.

Bar chart comparing current figures against their baselines: fixed Node.js release for the 22.x LTS… 22.23 x versus 22 x, fixed Node.js release for the 24.x LTS… 24.22 x versus 24 x, fixed Node.js release for the 26.x… 26.12 x versus 26 x.

The Node.js Project says an attacker who supplies Brotli data that an application decompresses can crash the process, disclose process memory, or execute code with that process’s permissions.

The flaw came from a shortcut inside DecodeBlockTypeAndLength(). The vulnerable function returned a Boolean even though the decoder needed to distinguish several outcomes. I have approved similarly “small” shortcuts during late-night reviews, usually while promising myself I would clean them up after launch. Reader, my post-launch self had other plans.

The upstream correction makes the function return a specific BrotliDecoderErrorCode. Incomplete data produces BROTLI_DECODER_NEEDS_MORE_INPUT, while an impossible transition produces BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH. That error then propagates through the literal, command, and distance block-switch paths. The caller can finally stop instead of feeding bytes into an invalid decoder state. The fixed Node.js releases bundle that correction.

Exposure begins when attacker-controlled Brotli reaches node:zlib or another route into the bundled decoder. Merely running Node.js does not trigger the bug.

Red Hat’s caution deserves a fair hearing. Reliable exploitation requires a carefully malformed stream, and operating-system or compiler hardening can make memory corruption difficult to convert into stable execution. Imperva nevertheless crossed that line with the official vulnerable build and created a marker file through supplied code; the patched release rejected the same payload. Its result proves code execution under the tested conditions. The repeated attempts and limited platform coverage also prevent anyone honest from calling exploitation universal or dependable.

The big unknown is portability: how reliably can this corruption become code execution across operating systems, CPU architectures, compiler-hardening configurations, and application layouts? There is also no evidence of exploitation outside the vendor and researcher tests described so far. I still wouldn’t leave conditional RCE in production like week-old tiramisù at a gas station.

Your HTTP client may deliver the payload

Picture a backend fetching an image URL, calling a customer-defined webhook, exchanging an OAuth token, or reading an MCP resource. The remote server replies with Content-Encoding: br, and an HTTP client decompresses the body before your business logic receives anything useful.

Charles Crouchman describes the danger of deploying AI agents in production:

The demo is the easy part. The real test begins when an AI agent touches a production system, a financial transaction or a customer interaction.

Your application opened the connection. The attacker still chose the bytes.

That trust-boundary crossing is easy to miss because every individual step looks normal. A user or integration supplies a destination, though a legitimate destination could also become compromised later. The Node service connects and accepts compressed content. The remote server returns plausible headers with a malformed Brotli body. A client library inflates it automatically, often before application code can inspect the response. Decompression crosses from JavaScript into the native decoder. On a vulnerable runtime, the invalid block switch can corrupt memory inside a process holding credentials or access to internal services. Egress is ingress wearing a nicer jacket.

Satya Nadella explains the security principle for agentic systems:

The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.

Vercel’s advisory draws a useful boundary. Node does not decode every Brotli object passing through a service, but application code and libraries may decompress request bodies or fetched responses. Vercel deployed WAF detections on disclosure day. Those rules can inspect traffic crossing its network; they cannot inspect arbitrary responses fetched by backend functions. Vercel therefore advised operators outside its managed runtimes to upgrade.

Inbound requests have another gate. A bare Node HTTP server receives a Brotli request body without automatically inflating it. Imperva reached the vulnerable decoder through Express and body-parser configurations with Brotli request decoding enabled. Read the middleware configuration before declaring an endpoint exposed, or safe.

Retool found outbound paths in REST, GraphQL, OpenAPI, MCP, OAuth, and custom AI URLs. It patched its cloud service about 13 hours after public disclosure and said exploitation generally required control of a destination or permission to configure requests. Fixed Stripe or Google endpoints carried lower risk because an attacker would need to control the vendor or intercept encrypted traffic.

A WAF may close one route. Updating Express may close another. Every surviving route eventually reaches the same native decoder, which makes the fixed Node.js binary the decisive repair.

What’s missing is the denominator: how many deployed applications actually decompress attacker-controlled Brotli through node:zlib, fetched responses, or configured middleware? Anyone offering a neat probability without that number is doing astrology with a CVE.

Torn white deployment package reveals a dark, aged runtime core beside an orange node --version strip.

TLS parsers could authenticate the wrong address

The same security release fixes TLS hostname-verification failures caused by different parsers interpreting one host string differently. These bugs require narrower conditions than the Brotli flaw, including attacker influence over the hostname, a suitable certificate, and control or interception of the connection. They still ship in the same runtime you need to replace.

A leading-zero IPv4 literal shows how the failure unfolds. Application code supplies an unusual host string. WHATWG URL handling may normalize its first octet using one numerical interpretation, while the operating-system resolver reads the original spelling another way. Node must also classify the host as an IP literal or DNS name before checking the certificate’s Subject Alternative Name. When normalization, classification, and resolution disagree, certificate validation can bind to an identity different from the address reached by the socket. A server at that address may then present a certificate satisfying the mistaken interpretation. The fix rejects non-canonical IP forms instead of hoping every parser agrees on cursed address spellings. Imagine my Italian family debating carbonara while the kitchen catches fire.

GitHub’s advisory documents leading-zero, hexadecimal, compact decimal, and abbreviated IPv4 forms. Affected Node versions could normalize those values while treating them as DNS names during certificate matching. Under the stated conditions, including a trusted certificate with a numeric DNS SAN and a resolver that accepts the notation, a DNS-only certificate could authenticate an IP endpoint.

Fullwidth digits created another classification mismatch. Unicode digits could normalize into an IPv4 address while certificate checking still treated the host as DNS text. According to the Node.js Project, that regression affected the two newer release lines, while the older LTS line sat outside this specific code path.

The release also fixes a related disagreement in dns.resolve*(). A hostname containing a NUL character could pass an application check in full, then be truncated when c-ares consumed it as a C string. Retool assessed its own path as unexploitable because parsed URLs rejected the character earlier. Other applications may validate one string and resolve a shortened version.

Real-world prevalence remains an open question. An application needs the right combination of certificate, hostname control, resolver behavior, and network interception for these flaws to matter. That narrows the surface, but the parser disagreement is reproducible, and fixed.

Make the running binary prove its version

Runtime inventory is the least glamorous part of operating a Docker stack. It’s also where teams will screw up this patch.

The failure chain is painfully familiar. A repository requests a current Node major and carries a beautifully clean lockfile. Its container build starts from a pinned image containing an older patch release. CI reuses a cached base image, or a standalone executable embeds the runtime directly. Deployment ships that artifact without consulting the developer’s local Node installation. Dependency scanners inspect JavaScript packages and report a clean tree because the vulnerable component lives inside the executable. Production keeps serving traffic with the old decoder. Only the version printed inside the running workload settles the argument.

My rollout order is blunt:

Inventory containers, VM images, CI workers, serverless environments, and single-executable applications.
Install the fixed release for each supported Node line.
Rebuild every artifact containing the runtime.
Run node --version inside the deployed workload.

The cdxgen advisory shows why source-only inventory fails. Its npm installation relied on the host runtime, while standalone binaries and container images bundled older Node versions. A downstream release intended to ship an update while some artifacts still contained the vulnerable binary. Operators had to inspect what they actually executed.

During rollout, search for node:zlib, createBrotliDecompress, automatic response decompression, Brotli-enabled Express parsers, configurable webhooks, OAuth token URLs, and proxy code that fetches user-selected destinations. Where practical, disable Brotli decoding on untrusted paths and constrain destination hosts. Unexpected SIGSEGV exits during decompression deserve investigation, as do unexplained child processes or strange outbound connections. None proves compromise by itself.

The official notes include other repairs worth reading. Keep-alive reuse could associate unsolicited bytes with a later request when the event loop was busy, while snapshot-based processes could repeat cached UUID or random-integer output across launches. The Current line also received ZIP and Permission Model corrections. Dependency updates vary by release line and include c-ares, root certificates, and Undici.

Before lunch, I want two answers from whoever owns production: which exact Node binary is serving traffic, and who can make it decode bytes?

If the team cannot answer both, the next malformed response may perform the inventory for them.

Frequently asked questions

Which Node.js versions fix the Brotli security vulnerability?

Node.js 22.x should run 22.23.4 or newer, 24.x should run 24.22.1 or newer, and the Current 26.x line should run 26.12.1 or newer. Node 20 received no standard fix in the October security release, so affected deployments on that branch should migrate.

When is a Node.js application exposed to the Brotli RCE flaw?

An application is exposed when attacker-controlled Brotli data reaches node:zlib or another route into Node’s bundled decoder. That can happen through explicitly decoded request bodies or automatically decompressed fetched responses. A bare Node HTTP server does not automatically inflate a Brotli request body, so middleware and client configuration determine exposure.

How do the Node.js TLS hostname-verification flaws work?

TLS hostname-verification flaws can make Node authenticate an identity different from the address a socket reaches when parsers disagree about unusual host strings. Exploitation requires narrower conditions, including attacker influence over the hostname, a suitable trusted certificate, and control or interception of the connection.