Direct answer: On October 25, 2026, Sweet Security disclosed that the Node2Shell Brotli flaw also exists in a Go implementation of the Brotli library, with a parallel fix pushed on October 23. That puts Go-based HTTP infrastructure in scope, including Traefik, Fiber, Iris and fasthttp, even if your team already patched Node.js and PHP. Dependency presence alone does not prove a given service is exploitable, so the right next step is to inventory your Go services, check the Brotli library version in use, and confirm whether client-controlled Brotli decoding is enabled.
What happened on October 25
Sweet Security researcher Tomer Ben Gera found that a fix was pushed to the Go implementation of the Brotli compression library at about the same time as the original C library remediation. The company published its findings on October 25, 2026, framing the result plainly: where there is a fix in Go, there was a problem in Go.
That matters because most of the patching effort so far has focused on Node.js and PHP. Teams that closed those two fronts and stopped there may still have Go services carrying the same class of flaw. Sweet Security put it as an active area of investigation, not a future concern, for anyone running Traefik as a reverse proxy or load balancer, applications built on Fiber or Iris, or any Go HTTP service that decompresses Brotli requests.
What the flaw actually is
The underlying vulnerability is CVE-2026-111497, an out-of-bounds write in the Brotli decoder. In the C implementation, which affects library versions 1.0.3 through 1.2.0, a purpose-built compressed stream can corrupt process memory. The GitHub advisory for the Python package scores it CVSS v4 9.2, which is critical, while Node.js rates the issue high in its own advisory.
The decoder bug is subtle. An invalid block switch was reported as needing more input instead of returning a final error, so the streaming decoder kept queuing bytes into a small internal buffer and wrote past its end. The fix makes it return a format error. Depending on the build and configuration, the result can range from a crash to memory disclosure or, in specific demonstrated setups, code execution.
Node.js disclosed the flaw on October 21, 2026, with patched releases, and researchers have since shown that the same decoder problem reaches far beyond Node. Earlier coverage traced it through Bun, Python and Envoy under the HTTP2Shell name. The October 25 disclosure extends that map to Go.
Which Go projects are affected
Sweet Security identified four major Go HTTP projects with a confirmed dependency on the affected Go Brotli library. Read this list as exposure to check, not as proof that every deployment is exploitable. Versions, encoder versus decoder use, and application configuration all change the real risk.
Traefik
Traefik, with more than 65,000 GitHub stars and more than one billion cumulative Docker image pulls, uses the library as a direct dependency in its Compress middleware for encoding outgoing Brotli responses. Because Traefik commonly sits in front of other services as a reverse proxy or load balancer, it is worth checking first. A flaw at the edge can affect everything behind it.
Fiber
Fiber, with more than 40,000 stars, carries an indirect dependency through fasthttp in version 2.52.9. Sweet Security notes that request-body decoding is exposed through Ctx.Body() and JSON BodyParser, creating a path where client-controlled compressed bodies could trigger the vulnerability. If your Fiber application accepts request bodies from untrusted clients, this is the path to examine.
Iris
Iris, with more than 25,000 stars, carries the library as a direct dependency with support for both response encoding and request decoding. The request-decoding side is the more sensitive direction, since it processes data an outside caller controls.
fasthttp
fasthttp, with more than 23,000 stars, carried the library as a direct dependency through version 1.73.0 before migrating to an alternative in version 1.74.0. That version boundary gives fasthttp users a concrete check: anything at or below 1.73.0 needs a closer look, and 1.74.0 moves away from the affected library.
Why scanners may miss it
Sweet Security flags a structural problem with traditional vulnerability scanners here. Node and Go binaries do not follow predictable installation paths, so scanners that rely on known paths and package registries may not detect the vulnerable library at all. A clean scan report is therefore not the same as a clean estate.
The company recommends runtime visibility instead: identifying what is actually executing rather than what is expected to be present. In practice, that means checking running services and their dependency trees, not just a software inventory spreadsheet. If you cannot see which Brotli library a running Go process loaded, you cannot rule it out.
How to check your own stack
Start with an inventory, and work from the edge inward.
- List every Go-based HTTP service you run, including reverse proxies, API gateways, internal tools and sidecar services. Do not forget services that were deployed once and left running.
- For each service, find the Brotli library version in its dependency tree and in the built binary where possible. Note whether the service uses the library for decoding client requests, encoding responses, or both.
- Check whether Brotli decoding of client-controlled input is enabled. A service that only encodes its own responses has a different risk profile from one that decompresses data sent by callers.
- Check Traefik Compress middleware settings, Fiber body parsing, Iris compression settings and the fasthttp version, using the version boundaries above as your starting point.
- Compare what you find against the patched releases, and treat any service you cannot version as unpatched until proven otherwise.
If you run Traefik, check the version of the Compress middleware dependency directly rather than assuming a recent Traefik release automatically clears you. Framework and library versions move on different schedules.
What to patch and in what order
Patch the edge first, then the services that decode untrusted input, then everything else that carries the library.
- Traefik and other edge proxies. These face the internet and sit in front of other services. Update the Brotli dependency and verify the Compress middleware path after the update.
- Services that decode client request bodies. Fiber applications using Ctx.Body() or JSON BodyParser, Iris services with request decoding enabled, and any Go service that decompresses caller-supplied data belong in this group.
- fasthttp-based services. Move to fasthttp 1.74.0 or later, which migrates away from the affected library, and verify the dependency is actually gone from the built binary.
- Remaining Go services. Update the Go Brotli library to a patched release and rebuild, rather than only updating a manifest file and leaving old binaries in production.
After patching, rebuild and redeploy. A patched dependency in source control does not protect a container image that was built before the fix. Verify the running binary, not just the repository.
What to watch for while you patch
Sweet Security recommends monitoring runtime behavior for signs of exploitation, including unexpected process execution, unusual outbound connections and abnormal memory behavior in HTTP worker processes. Crashes in HTTP workers that handle compressed input are also worth investigating rather than dismissing as ordinary instability.
It is also worth stating what is not yet established. The October 25 disclosure identifies the Go library fix and the dependency map; it does not, on its own, claim confirmed exploitation of the Go path in the wild, and Sweet Security is explicit that dependency presence alone does not establish vulnerability or reachability. Patch on the strength of the flaw and the exposure, not on a claim of active Go exploitation that has not been made.
For background on how this flaw spread beyond Node in the first place, see our earlier coverage of HTTP2Shell and the Brotli flaw behind Node2Shell, and the Node.js October 2026 security update that first patched it. The PHP side of the same week is covered in our PHP2Shell emergency patch guide.
Frequently asked questions
Is every Traefik, Fiber or Iris deployment vulnerable?
No. Sweet Security is clear that dependency presence alone does not establish vulnerability or reachability. The version in use, whether the code path encodes responses or decodes requests, and the application configuration all matter. Treat these frameworks as in scope for checking, and confirm exposure per deployment.
Does patching Node.js fix the Go problem?
No. Node.js patches fix Node.js. Go services bundle or depend on their own Brotli library, so they need their own update and rebuild. A team that only patched Node and PHP has not finished this job.
Which fasthttp version should I be on?
fasthttp carried the affected library as a direct dependency through version 1.73.0 and migrated to an alternative in version 1.74.0. Move to 1.74.0 or later and verify the old library is no longer in the built binary.
Why would my scanner report no problem?
Node and Go binaries do not follow predictable installation paths, so scanners that depend on known paths and registries can miss the library entirely. Check running services and dependency trees directly, and use runtime visibility where available.
What should I do if I cannot version a Go service?
Treat it as unpatched until you can prove otherwise. Rebuild it from current dependencies, check whether it decodes client-controlled Brotli input, and monitor its HTTP workers for crashes, unexpected processes and unusual outbound connections while the rebuild is in progress.