Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Original editorial illustration of a dark server room where one glowing compression pipeline splits into three parallel colour-coded pipes — blue, amber, and cyan — with the cyan pipe newly lit and a small patch seal closing over a crack in it

Node2Shell in Go: Brotli Flaw Expands to Traefik, Fiber, Iris

by

Node2Shell in Go: Brotli Flaw Expands to Traefik, Fiber, Iris

In brief

  • Node2Shell is not Node.js-only: Sweet Security found the same Brotli flaw class in Go, with a fix pushed Oct 23. What Traefik, Fiber and Iris users must check.
  • The Go Brotli library is a direct or indirect dependency of major HTTP frameworks including Traefik, Fiber and Iris, with combined GitHub adoption above 130,000 stars; Traefik alone has more than one billion cumulative Docker image pulls.
  • Traefik uses the library as a direct dependency in its Compress middleware, which encodes outgoing Brotli responses — the kind of everyday compression path that makes a library flaw reach production traffic without anyone writing decompression code.
  • The underlying flaw is CVE-2026-111497, an out-of-bounds write in Google’s Brotli C decoder rated 9.2 under CVSS 4.0. The Go finding is about the same flaw class in a different language implementation, not a new CVE — and the release names no Go library version, so the exact fixed version must be confirmed before acting on a version number.
  • If you patched Node.js or Python for Node2Shell and stopped there, this disclosure is the reason to extend the same check to Go services: where a fix was pushed in parallel, there was a problem in parallel.

The disclosure in one paragraph

Node2Shell began as a Node.js story. On October 21, 2026, the Node.js project fixed CVE-2026-111497 in its October security release, and researchers at Imperva later demonstrated remote code execution on an official Node.js build using crafted Brotli data. The flaw itself, though, lives in Google’s Brotli decoder, not in Node.js: an out-of-bounds write in the C decoder’s fast decode path, where an unchecked return value lets the decoder keep running on corrupted internal state and write past its ring buffer.

That distinction is the whole reason the story kept growing. Because the vulnerable code is a shared library, everything that bundles or ports that decoder inherits the risk — Node.js, Bun, and the Python packages Brotli and brotlicffi, whose quiet fixes (Brotli 1.2.1, brotlicffi 1.2.1.0) shipped on October 22-23 without, in one account, any mention of the vulnerability in their release notes. Sweet Security’s October 25 finding adds the next language to that list: Go.

What Sweet Security actually found

Sweet Security engineer Tomer Ben Gera identified that a fix was pushed to the Go implementation of the Brotli library on October 23, 2026, at about the same time as the original C remediation. The company’s argument is deliberately simple, and it is worth quoting because it is also the verification logic: “Where there is a fix in Go, there was a problem in Go.”

That sentence matters because it separates what is proven from what is inferred. What is proven by the release is that a fix was pushed to the Go implementation in parallel with the C fix, which strongly indicates the underlying memory-management flaw present in the C implementation was replicated in Go. What the release does not do is name the affected Go library versions, name a fixed version, or assign a separate CVE to the Go implementation. A careful reader should not fill those gaps from the Node.js numbers: the C decoder’s fixed versions (Brotli 1.0.10, 1.1.1 and 1.2.1) and the Node.js fixed releases (22.23.4, 24.22.1 and 26.12.1) describe the C library and the Node.js runtime, not the Go port. Before publishing a version number for Go, check the Go library’s own repository and release notes — that check is flagged as a pre-publish step for this article.

The second thing the release does establish is reach. Sweet Security’s analysis identified four major Go HTTP projects with confirmed dependency on the affected library, naming Traefik, Fiber and Iris. Traefik, with more than 65,000 GitHub stars, uses the library as a direct dependency in its Compress middleware for encoding outgoing Brotli responses. That detail is the reason this is not a theoretical footnote: a reverse proxy that compresses responses for other services sits in front of production traffic, so a decoder flaw in its compression path is not contained to one application.

Why the same bug keeps appearing in new languages

Compression libraries are infrastructure in the most literal sense: they are copied, vendored and ported into runtimes and frameworks, and then forgotten. Node.js vendors its own copy of the Brotli library under deps/brotli, so the flaw was a property of the runtime binary, not of any npm package. The Python packages are built from the same C source. The Go implementation is a port of the same logic. When the root flaw is in the shared logic — here, a decoder function returning an ambiguous value when a Brotli stream requests a block-type switch the stream never validly declared, with the fast path discarding that return value — every faithful copy carries it.

That is also why the fix pattern has been uneven. Node.js shipped a coordinated fix on October 21. The Python packages shipped quiet fixes days later. The Go fix was pushed on October 23 and only publicly connected to Node2Shell on October 25. Security teams that scoped their Node2Shell response to “Node.js services” on October 21 therefore had a stale scope by October 23, and only learned about it on October 25. The lesson is not that anyone was careless; it is that a library-level flaw cannot be scoped by runtime. It has to be scoped by dependency: every service that decodes or encodes Brotli, in any language, in any runtime.

What to check in your own Go services

Start with the dependency, not the framework name. If you run Traefik, Fiber or Iris, check whether your build pulls in the Go Brotli library and which version it pins — and then check that library’s release history for the October 23 fix, rather than assuming your framework’s latest release already includes it. Framework releases and library fixes do not always move together, and the Sweet Security release does not claim any particular framework version is fixed.

Next, check the compression path itself. The Traefik example is instructive: the dependency enters through Compress middleware that encodes outgoing responses. A service does not need to accept compressed uploads to be in scope; producing compressed responses through an affected library is the path the release identifies. The same reasoning applies to any Go HTTP service that negotiates Brotli content encoding, in either direction.

Finally, treat “no exploitation reported” as a status, not a reassurance. For Node.js, Imperva’s proof of concept showed code execution on one official build (Node.js 24.22.0 for Linux arm64), took several tries, and did not succeed on every attempt; on the fixed 24.22.1 release the same data was rejected. No exploitation in the wild had been reported as of October 22 for the Node.js flaw. The Go finding, as disclosed, reports the flaw class and the fix, not observed exploitation. That is the normal order for a library flaw — disclosure, then patching, then, if patching lags, exploitation attempts — and it is the reason the patch window, not the exploit news, is the deadline.

What this means for you

  • If you run Go HTTP services: check for the Go Brotli library in your dependency tree and confirm the October 23 fix is in your pinned version. Do not assume a Node.js or Python patch covers Go.
  • If you run Traefik: the Compress middleware dependency is the named path. Verify your Traefik build’s Brotli library version against the fix, and watch for a Traefik advisory or release note that names it.
  • If you already patched Node.js and Python: your Node2Shell work is not wasted, but it is incomplete until Go is checked. The flaw class crossed languages once; the check should cross languages too.

  • If you write the patch plan: scope by library, not by runtime. List every service that touches Brotli — Node.js, Python, Go, Bun, Envoy and anything else that bundles the decoder — and close each one against its own fixed version.

  • The Tower Post — “Go Brotli Patch Broadens Node2Shell Security Audit Beyond JavaScript” (Oct 26, 2026; Go fix committed Oct 23, disclosed Oct 25; dependency does not by itself prove an app exposes a vulnerable path)

Related reading

Sources

Last verified: October 27, 2026.

Related: Microsoft’s Emergency .NET Patch: The Same Brotli Flaw, a Different Ecosystem — the same Brotli flaw reached .NET, but most .NET apps are not exposed because decompression is off by default. The triage is which apps turned it on.

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment