Fixed for eight months, installable for none: Brotli CVE-2026-111497 and Node.js's October 21 patch

On October 21, 2026, Node.js shipped a security release fixing 10 vulnerabilities, including a flaw in its Brotli decoder. The most watched of the ten is tracked as CVE-2026-111497: an out-of-bounds write that lets a crafted piece of compressed data crash a process, leak memory, or potentially execute code. But the most instructive part of this story is not the bug's mechanics. It is the timeline: the code that caused it had already been fixed in Brotli's source in February 2026 — yet because nobody recognized it as a security issue at the time and no new version was cut, the fix sat in the repository for eight months while every installable Brotli release stayed vulnerable.

This article covers three things: how the flaw is triggered, which software you need to update, and why "fixed in the source" does not mean "safe for users" in open source. The last point matters most for vibe developers, because your projects almost certainly run on Node.js — and Node.js's bundled Brotli decoder is at the center of this incident.

How this relates to our earlier coverage: our October 22 feature on four runtimes patching at once introduced this flaw's trigger and Node.js fix versions in one section, written for readers without a development background. This piece is a developer-facing follow-up with a different focus — why the fix sat in the repository for eight months before it became a version anyone could install, and the upgrade checklist for Bun, Envoy and Python beyond Node.js.

The mechanism: a misreported "wait for more" overflows an 8-byte buffer

Node.js's security advisory describes the mechanism with unusual precision, and it is worth reading closely. When the streaming Brotli decoder encountered an invalid block switch, it should have rejected it as a permanent format error. Instead, it reported the situation as a temporary need for more input. The decoder therefore kept appending subsequent input bytes into an internal buffer of just eight bytes until it wrote past the end. In Node.js's words: an attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution.

In plain language, the bug is not in compression itself but in a judgment call between "this data is wrong" and "this data is incomplete." One misclassification looks trivial, but streaming decoders do not stop to double-check: they keep going on the wrong premise until the buffer gives way. Many memory-safety bugs share this shape — a small classification error paired with an unguarded loop becomes an out-of-bounds write.

Attacker data can reach the decoder from two directions, and the second is the one most developers miss on first hearing. The first direction is the request body: your service receives a Brotli-compressed request body and decodes it with middleware or node:zlib. The second direction is the response body: your service fetches a third-party API with Node.js's built-in fetch(), the other side returns a Brotli-compressed response, and Node.js decodes it automatically. The second direction is more dangerous because it does not require the attacker to reach your service directly — only to control one upstream your service fetches, such as a user-supplied URL or a third-party webhook response. Checking "who can send me requests" is not enough; you must also check "whose responses do I decompress."

The timeline: eight months fixed-but-unreleased, two days to publish

Laid out in order, the timeline is striking. In February 2026, the relevant code in Brotli's source was changed, but the change was not identified as a security fix and triggered no release. The most recent tagged Brotli release before that was 1.2.0 from October 2025. So for eight months, the fix existed only on the repository's default branch — in no artifact any package manager could install. A consumer watching only the upstream project's releases received no signal at all during that period.

October changed that. Google reserved the CVE number on October 16; Brotli cut version 1.2.1 on October 21 (alongside 1.1.1 and 1.0.10 for maintenance branches); the CVE record went public on October 22. On the same day, Node.js released 22.23.4, 24.22.1, and 26.12.1. The credited reporters are worth noting precisely: both the CVE record and Node.js's advisory credit OpenAI Codex Security's Khai Tran and Sylvie Mayer, in the context of a red-teaming exercise run while OpenAI hardened its frontier-model training.

One widely repeated simplification needs correcting: "an AI found this vulnerability." The accurate statement is that a red-teaming exercise reported the flaw, and the CVE record credits two named researchers. Shrinking "found during a red-team exercise" into "autonomously discovered by AI" exaggerates what automation did — and distracts from the real lesson, which is not about the discovery mechanism at all. The discovery mechanism is not the lesson; the release mechanism is.

The severity dispute: 9.2, High, and unconfirmed in-the-wild exploitation

The same flaw carries different severity labels in different places, and that is not a typo — it is a difference in rating systems. Google's CVE record scores CVE-2026-111497 at 9.2 Critical under CVSS 4.0, describing a remote unauthenticated attacker who can corrupt adjacent decoder state, disclose memory, cause denial of service, or potentially execute arbitrary code — while also marking attack requirements as present (AT:P), meaning exploitation depends on the target's configuration and is not equally possible everywhere. Node.js rates the same flaw High, not Critical. Both can be true: the CVE score describes the flaw's worst-case potential, while Node.js's rating reflects its judgment for Node.js deployments specifically.

Proof-of-concept reporting is similarly split and must be kept separate. Imperva's Red Team wrote on October 22 that it achieved code execution against the official Node.js 24.22.0 image through fetch and body-parser paths, while conceding it took multiple attempts in its setup. Another outlet's account of a public proof of concept says code execution was achieved only on a deliberately weakened test build, with standard builds producing a crash and a limited memory read. As of October 24, no in-the-wild exploitation had been publicly reported. The honest summary: remote code execution is conditionally demonstrated, not a universal one-shot against every unpatched service. Your action plan should not rest on guessing whether you will be attacked; it should rest on the fact that patches exist and no workaround is offered.

One more risk sits outside the severity labels: this Node.js release fixed 10 vulnerabilities in total, and Brotli is only the most visible. The others include TLS hostname verification and DNS truncation issues, plus a trusted CA store refresh. Upgrading for the Brotli CVE alone fixes the most visible of ten doors. The correct move is to install the whole security release, not to cherry-pick one fix.

The update checklist: Node.js first, then every Brotli bundler

Node.js first. The fixed releases are 22.23.4, 24.22.1, and 26.12.1 for the three supported lines. Node.js's advisory states explicitly that no workaround is offered — upgrading is the only fix. Node.js 20.x and older have reached end of life and will never receive this fix; staying on them is not "temporarily unpatched" but "permanently unpatched." If you are still on 20.x, this incident is the final notice to move to a supported line, not another reminder you can defer.

Then everything beyond Node.js. Upstream Brotli's fixed versions are 1.2.1, 1.1.1, and 1.0.10; Python's brotli and brotlicffi packages are fixed from 1.2.1 and 1.2.1.0; Bun fixed it in 1.4.4 — with an extra requirement that standalone executables produced by its compile mode must be rebuilt, not relinked, because the old binary embeds the old decoder. Envoy fixed it in 1.40.0, 1.39.3, 1.38.6, 1.37.8, and 1.36.12 for deployments with a Brotli decompressor configured. Istio shipped corresponding fixes as well. The principle: every piece of software that bundles a Brotli decoder needs its own confirmation. "Node.js is patched" does not imply "everything is patched."

For vibe projects, add three more checks. First, your Dockerfile base image. Many vibe projects pin node:24 or a similar major tag, so a rebuild picks up the fix — but if you pinned a specific old patch release such as node:24.22.0, rebuilding changes nothing until you edit the tag. Second, your deployment platform and edge layer. Some platforms decompress Brotli at the edge; if the edge is unpatched, the attack surface survives even with a patched origin. Third, native modules in your dependency tree. JavaScript dependencies rarely embed Brotli, but once Rust, Go, or C extensions enter a project, their Brotli versions need separate confirmation.

Why "fixed in the repository" is not "safe for users"

This incident exposes a recurring crack in the open-source release chain: a fix merged to the default branch, without a version number and without a published artifact, does not exist for users. Brotli's own repository publishes no security advisories at all, so the entire disclosure trail was carried downstream by Node.js, Bun, Envoy, and PyPI. A consumer subscribed only to the upstream project's activity heard nothing for eight months; a consumer subscribed to downstream security advisories heard about it on October 21. Your subscription list should be reordered on that lesson: upstream activity tells you "someone is changing code"; downstream security advisories tell you "you need to upgrade."

For vibe developers, the sharper version of that lesson is: do not watch only your application dependencies. Your project's real attack surface includes the runtime (Node.js), the base image, the edge proxy, and every component that embeds a decoder — none of which appear in package.json. That file tells you what libraries your code uses; the runtime and base image tell you what your code runs on. When the latter breaks, npm audit will not warn you and dependency scanners may miss it entirely, because it is not a dependency update at all — it is a runtime update.

Finally, a monthly habit that costs ten minutes and needs no new tooling: confirm that production's node --version sits on a supported line at the latest patch release; confirm that base-image tags are not pinned to old patch releases; and confirm that the team subscribes to Node.js security advisories and to the security advisories of its edge platform. All three belong on the same checklist as dependency versions. The cost of the Brotli incident was not a sophisticated attack — it was a problem that a routine upgrade on October 21 would have solved, provided someone actually upgraded that day.