Security work has a blind spot shaped like a dependency graph. CVE-2026-111497 lives in a decompressor that ships inside the Node.js runtime, which means the team that owns the application, the team that owns the container image and the team that owns the base operating system can each assume somebody else patched it.
Three copies of the same decoder
The Node.js advisory describes a flaw in the Brotli decoder bundled with the runtime: an invalid block switch is reported as a need for more input, so a streaming caller keeps appending bytes to an eight-byte internal buffer until the write runs past its end. The CVE record points at Brotli 1.0.3 through 1.2.0 in c/dec/decode.c, fixed in 1.0.10, 1.1.1 and 1.2.1.
That description implies at least three places the defective code can exist in one organisation.
The Node.js runtime itself, on lines 22.x, 24.x and 26.x, where the fixes are 22.23.4, 24.22.1 and 26.12.1.
A separately vendored Brotli library compiled into a native service, a Go or Rust binary using a C binding, or a data pipeline that decompresses archives without Node.js in the picture at all.
A container base image or prebuilt distribution package that pins an older runtime while the application's own manifest looks current.
An inventory built only from package.json will find none of these.
Why the third copy is the dangerous one
Teams usually track application dependencies because those are the lines that change in a pull request. Runtime and base image versions change rarely, and that stability is exactly what makes them easy to forget. A service rebuilt weekly on the same base image will carry the vulnerable decoder across every release, and a version string read from the application will confirm a patch that never happened.
The practical test is to ask the running process, not the repository. Inside a container, that means checking the runtime version reported by the interpreter that actually starts the service, and checking whether any linked decompression library predates the fixed releases.
Ownership needs to follow the decode path
The advisory's precondition is functional rather than textual: some code path must hand attacker-controlled Brotli data to the decoder. That gives an organisation a clean way to assign ownership. Whoever owns the endpoint that accepts br content encoding owns the risk on that endpoint. Whoever owns the queue consumer that expands stored payloads owns the risk there. Whoever owns the base image owns the risk that remains.
Splitting the work this way also produces a useful negative list. Services that never inflate Brotli input, because the reverse proxy terminates compression in another language, can be closed with a documented reason instead of lingering as unknown.
Remediation without a rewrite
Upgrade the runtime to the fixed release for each supported line, update any vendored library to the version floor, and rebuild images so the patched runtime is actually the one deployed. Where the upgrade has to wait, put a ceiling on decompressed size and reject Brotli bodies on endpoints that do not need them.
The defect was reported by Khai Tran and Sylvie Mayer of OpenAI Codex Security and fixed by mcollina and aduh95. What makes this case instructive is not the buffer arithmetic but the ownership gap: a vulnerability in a component everyone depends on and nobody tracks.