A malformed Brotli stream can make the decoder bundled with Node.js write beyond an eight-byte buffer. Applications that decompress attacker-supplied Brotli data with node:zlib are the ones to examine: memory corruption in that process can crash it, expose sensitive memory or potentially lead to remote code execution. Rapid7’s October 26 analysis names the affected Node.js 22.x, 24.x and 26.x lines and their fixed releases.
The flaw, CVE-2026-111497, originated in upstream Google Brotli. Google’s CVE record credits OpenAI Codex Security researchers Khai Tran and Sylvie Mayer and scores it 9.2 under CVSS v4. Node.js rates its bundled-decoder issue High, while Google rates the upstream flaw Critical. An application has to pass untrusted compressed input to the decoder for the described attack path. Inventory identifies candidate services; tracing their decode paths tells you which ones handle hostile streams.
A format error becomes an overflow
Brotli is a compression format. A service may decompress a stream before it inspects or uses the underlying data. That makes the decoder the first piece of code to handle the stream, including a malformed one from an untrusted source.
Rapid7 describes an invalid Brotli block switch that the decoder treated as a “temporary need for more input” rather than a permanent format error. The streaming decoder continued adding input bytes to its eight-byte internal buffer. Once the buffer filled, subsequent input wrote beyond its bounds into process memory. The CVE record classifies the flaw as both an out-of-bounds write (CWE-787) and an unchecked return value (CWE-252), and describes corruption of adjacent decoder state. A process crash, memory disclosure and code execution are possible consequences of that corruption, depending on the application and environment.
Trace where your application calls Brotli decompression through node:zlib, then identify which of those paths accepts data supplied by users, clients, partners or other untrusted systems. Request-body handlers, ingest pipelines and background jobs deserve attention where they actually decode those streams. Brotli compression on an outbound response, by itself, describes a different data flow; the vulnerable operation here is decoding attacker-controlled input.
The same decoder travels downstream
The Google CNA record lists affected upstream Brotli ranges on all platforms: 1.0.3 before 1.0.10, 1.1.0 before 1.1.1, and 1.2.0 before 1.2.1. Google recommends updating affected libraries or binaries to the latest available fixed version in the corresponding series. Use Google’s version ranges to inspect upstream Brotli dependencies; check running Node.js builds against the fixed Node.js releases below.
Rapid7 also identifies downstream implementations or packages in Bun, Python Brotli and brotlicffi, .NET, Envoy and Istio, brotli4j and operating-system packages. Those products package and update Brotli differently. For each deployed decoder outside Node.js, use its distributor’s affected-version and remediation guidance alongside the upstream range. Find the services that decompress untrusted Brotli input to scope exposure.
Rapid7 reported no known exploitation in the wild as of October 26. It recommends urgent remediation for exposed applications because memory disclosure and code execution are possible.
Replace vulnerable Node.js builds
Rapid7 lists 22.23.4, 24.22.1 and 26.12.1 as the first fixed Node.js releases for the 22.x, 24.x and 26.x lines respectively. Upgrade affected running processes to those builds or later fixed builds on the same supported line. Rebuild containers and redeploy long-running workers as well as web servers, then compare the version printed by the runtime in each live deployment with the target release. An updated image in a registry leaves an old process in place until it is replaced.
Node.js advises treating end-of-life release lines as affected when a security release occurs, according to Rapid7; migrate those installations to a supported fixed line. Rapid7 says Node.js has no vendor-supported workaround. If deployment has to wait, temporarily restrict or disable the application paths that decompress untrusted Brotli input. Restore them after the updated processes are running and the version check passes. Restricting those paths reduces exposure until patched processes are running.
Verify the decoder in service
Start with the decompression path and the process that actually runs it. Record which entry points feed untrusted Brotli streams into node:zlib, and collect the running Node.js version from each affected service instance. Replace vulnerable builds, or temporarily remove the untrusted decode path while patching. For other products bundling Brotli, compare the installed component and downstream vendor fix before changing a package in isolation.
A fixed dependency file can coexist with a still-running old worker; check the live process and its untrusted decode path. Test the deployed service by reading its live runtime version and confirming that its untrusted Brotli entry path runs on a fixed build: 22.23.4, 24.22.1 or 26.12.1 or later in the respective supported line. Keep the entry-point inventory with the rollout so the next embedded-decoder update reaches the processes that actually handle those streams.