Google Brotli decoder out-of-bounds write can enable remote code execution

A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.

• Google Brotli: affected on all platforms in 1.0.3 <= version < 1.0.10, 1.1.0 <= version < 1.1.1, and 1.2.0 <= version < 1.2.1. The record sets default_status to unaffected outside the listed ranges.
• Node.js downstream: the Node.js advisory confirms that the 22.x, 24.x, and 26.x lines were affected before the corresponding fixed releases 22.23.4, 24.22.1, and 26.12.1.
• Debian trixie: the brotli package was fixed in 1.1.0-2+deb13u1. This is the boundary stated for the Debian package and does not replace checks for other Brotli copies embedded in applications.

The vulnerable component is the Brotli decoder in c/dec/decode.c. The Node.js advisory describes the specific mechanism as an invalid block switch being reported as a temporary need for more input instead of a permanent format error, allowing the streaming decoder to keep appending input bytes to an eight-byte internal buffer. At a high level: (1) an attacker supplies a crafted Brotli stream; (2) an application passes the stream to the decoder; (3) the decoder writes past the boundary and corrupts adjacent decoder state memory; and (4) the process may crash, disclose memory contents, or reach arbitrary code execution. The precondition is that an application decodes Brotli data controlled by the attacker, while the record describes remote reachability without authentication or user interaction. The record classifies the issue as CWE-787 and CWE-252; it does not provide further detail connecting CWE-252 to a specific implementation path. The adjacent memory layout and the reliability of code execution in each consuming product remain unestablished.

The flaw is network reachable when a service accepts or automatically processes a Brotli stream controlled by the attacker. The record describes a remote unauthenticated attacker, low attack complexity, and no user interaction, but exploitation still depends on an application path that invokes the decoder. For Node.js, reported paths include Brotli request bodies, automatically decompressed Brotli responses, and direct use of node:zlib APIs. The normalized record sets public_exploit to false; however, a later Aikido report says that a public proof of concept appeared and that researchers achieved code execution in lab conditions against an unmodified Node.js build, with inconsistent reliability. The supplied record does not establish exploitation in the wild.

A malicious Brotli stream can corrupt decoder state memory and lead to a crash, disclosure of memory contents, modification of in-process data, or arbitrary code execution. The privilege consequence depends on the privileges of the process decoding the stream; if code execution is achieved, it may operate within that process's permissions. The flaw directly affects the system processing the data, and the record does not establish a separate impact on another downstream system. The reliability of turning the out-of-bounds write into code execution may vary with the allocator, memory layout, build, and integration of Brotli.

• Services that process untrusted compressed input may crash or lose availability, causing restarts, failover, or request disruption.
• An out-of-bounds read or write may expose sensitive data present in the process address space, depending on memory layout and the data being handled.
• If code execution is achieved, the attacker may operate with the privileges of the process performing the decode, affecting data and functions available to that service account.
• Operations teams may need an urgent inventory across runtimes, container images, bundled libraries, and self-contained binaries because updating one system package does not necessarily update an embedded Brotli copy.

1. Update Google Brotli: move affected branches to the corresponding fixed release 1.0.10, 1.1.1, or 1.2.1 for the branch in use.
2. Update downstream runtimes and binaries: for Node.js, deploy the corresponding fixed release 22.23.4, 24.22.1, or 26.12.1. For Debian trixie, upgrade the brotli package to 1.1.0-2+deb13u1.
3. Rebuild and redeploy: rebuild container images, self-contained binaries, and NativeAOT or other applications that may have linked a vulnerable decoder copy. After updating, restart processes so they load the fixed decoder.
4. If an update cannot be deployed immediately: temporarily avoid passing untrusted Brotli data to the affected decoder. For HTTP ingress, blocking requests with Content-Encoding: br at a reverse proxy or middleware may reduce exposure where operationally appropriate. This is only a partial mitigation and does not protect paths such as Brotli responses fetched by the application.

• Inventory every Brotli library, binary, runtime, and bundled copy inside applications, container images, or self-contained binaries. Do not rely only on operating system package inventory because a bundled copy may not appear as a separate package.
• Check Brotli versions against the affected branches in affected_summary, including copies introduced through dependencies or packaged binaries.
• For Node.js, run node --version on hosts, CI runners, and inside each container image; also check the versions used by running processes rather than only installed files.
• Review paths that decode untrusted data, including node:zlib, calls to brotliDecompress or createBrotliDecompress, requests with Content-Encoding: br, and HTTP responses automatically decompressed by the application.
• As a precaution, review crash reports, unexpected restarts, and memory-disclosure alerts for services processing compressed input. These are not specific indicators, and the absence of such evidence does not prove that a system is safe.