Brotli vulnerability: which Node and Python services can actually be hit (CVE-2026-111497)

The brotli vulnerability (CVE-2026-111497) matters only where your code decompresses Brotli data an attacker can influence: request bodies sent with Content-Encoding br, or responses from servers you call. Patch Node.js to 22.23.4, 24.22.1 or 26.12.1, update Python's Brotli to 1.2.1, then rebuild your container images.

This guide is current as of October 25, 2026. Fixed-version numbers can change as maintainers publish further releases, so treat the linked Node.js advisory and OSV record as the authority and re-check them before you close the ticket. Advisories get revised, so re-read the linked pages before you rely on a version number.

What the brotli vulnerability is, and when it can be reached

The Node.js advisory describes a Brotli decoder flaw where an invalid block switch "was reported as a temporary need for more input instead of a permanent format error." The streaming decoder then kept appending input bytes to an eight-byte internal buffer. Node.js rates it high and says an attacker who can supply Brotli data that an application decompresses with node:zlib can cause a crash, memory disclosure or remote code execution.

The bug is in Google's library, not only in Node. Google published Brotli 1.2.1, 1.1.1 and 1.0.10 on October 21, each listing CVE-2026-111497. The OSV record says versions 1.0.3 through 1.2.0 are affected on all platforms, and carries a GitHub-reviewed severity of critical.

Reaching the decoder takes two things: a Brotli decoder in your process, and bytes you did not write going through it. A service that never decompresses Brotli is not exposed through this bug, whatever version string it carries.

Which of your services are in the path

Aikido's write-up says Node apps were exposed if the app or a library decompresses bad Brotli data, naming the built-in fetch() and body-parser. body-parser's README says all its parsers support automatic inflation of gzip, br, deflate and zstd. Aikido also notes that Apache and Nginx do not decode Brotli by default, so a plain reverse proxy is not the usual path.

Aikido sells a security scanner and is listed on Upfynd. Its post is a vendor write-up, so we checked its version numbers against Node.js, Google and OSV, which agree on them.

Node.js: patch the runtime, then check the version you actually run

The Node.js 22.23.4 release notes, dated October 21, list the fix as "deps: brotli: cherry-pick 0ed4268a4401abcb44720963". The same release carries two other high-severity fixes, for TLS IP address handling and DNS null bytes, so there is no reason to skip it.

Because the fix is a cherry-pick rather than a Brotli version bump, we would not trust process.versions.brotli as proof of a patched build. We have not confirmed what that field prints on the fixed releases. Check the Node version instead, with node -v inside the running environment.

Node 20 needs a decision rather than a patch. The release notes name fixed builds only for 22, 24 and 26, and the Node.js release schedule lists Node 20's end of life as April 30, 2026. The advisory says "End-of-Life versions are always affected when a security release occurs." Plan the move to a supported line.

Python: the Brotli package is the problem, not the interpreter

The OSV record lists the PyPI Brotli package as affected up to 1.2.0 and fixed in 1.2.1, and brotlicffi fixed in 1.2.1.0. Aikido says urllib3 (and so requests) uses Brotli automatically when Brotli or brotlicffi is installed, as do httpx with its brotli extra and aiohttp. Your code does not have to import either package.

That makes transitive installs the trap. Aikido's checks, run in each environment, are pip show Brotli brotlicffi and pipdeptree -r -p Brotli, plus a grep of your lock files for brotli. To fix it, run pip install -U "Brotli>=1.2.1" or pip install -U "brotlicffi>=1.2.1.0".

On October 23, Aikido wrote that OSV and the GitHub Advisory Database did not yet list the PyPI packages, so scanners built on them would not flag old versions. The OSV record we read on October 25 does list both, with GitHub's review dated October 23. We did not test whether any particular scanner now reports it, so run the manual check as well.

Containers stay vulnerable until you rebuild them

Aikido puts it plainly: an image built on a vulnerable version stays vulnerable until you rebuild it. A patched laptop proves nothing about what runs in production.

On Docker Hub, the official Node image has a 22.23.4 tag pushed on October 22. Rebuild from that base with a fresh pull, redeploy, then run node -v and pip show Brotli inside the running container. Upfynd lists Docker and Node.js if you want their product pages, and our post on vulnerability scanners explains which layer each kind of scanner can see.

If you cannot patch today

Aikido lists three stopgaps. Treat them as temporary, because each can break traffic:

• Inbound: reject requests whose Content-Encoding contains br before any decoder runs.
• Outbound: remove br from your Accept-Encoding header, and reject br responses before decoding.
• Python: uninstall Brotli and brotlicffi, then rebuild and restart. Aikido warns that servers may still send Brotli, which can cause errors.

In our view, patch first any service that fetches URLs it does not control, such as webhook senders, link previews and scrapers, and any public endpoint that accepts compressed request bodies. Aikido gives the same two cases priority. It cites a report of no exploitation in the wild as of October 22, which we have not verified.

Next step

Make a list of every image and function you deploy, run node -v or pip show Brotli brotlicffi inside each, and rebuild the ones that fail. If you also want a scanner on the pipeline, browse the Security category, which lists 139 products as of October 2026, or the Developer Tooling category with 491. Neither replaces the manual check above.