The recently disclosed HTTP2Shell vulnerability (CVE-2026-111497) has quickly expanded beyond its initial discovery in Node.js. The vulnerability originates in Google's Brotli compression library, potentially exposing applications across multiple programming languages and HTTP frameworks to remote code execution (RCE).

While much of the attention has focused on the C implementation of Brotli, Sweet Security's research team has confirmed that the Go implementation is also vulnerable. Sweet Security engineer Tomer Ben Gera successfully reproduced an exploit against the Go Brotli decoder, demonstrating how a specially crafted compressed HTTP payload can trigger a runtime panic and potentially cause denial of service (DoS).

The finding highlights a broader concern: vulnerabilities in widely adopted compression libraries can propagate across language implementations, extending the attack surface far beyond the originally reported ecosystem.

TL;DR

• HTTP2Shell (CVE-2026-111497) is an out-of-bounds write vulnerability in the Brotli decoder that can lead to memory disclosure, denial of service, and remote code execution.
• The vulnerability affects applications using Brotli decompression, including Node.js, Python, and HTTP infrastructure components.
• Sweet Security successfully exploited the Go Brotli implementation (v1.2.6), triggering a runtime panic through a crafted HTTP request.
• Popular Go projects including Traefik, Fiber, Iris, and fasthttp have dependencies on the affected Go Brotli library, although actual exploitability depends on configuration and decoder reachability.
• Sweet Security provides runtime detection and virtual patching, allowing organizations to block exploitation attempts while permanent fixes are deployed.

How HTTP2Shell Works

Brotli is a widely adopted compression algorithm used to reduce the size of HTTP requests and responses. Its implementation is embedded in numerous runtimes, HTTP libraries, reverse proxies, and application frameworks.

The vulnerability stems from improper handling of malformed Brotli streams during decompression. Specifically, an invalid block-type switch can be incorrectly treated as a request for additional input rather than an unrecoverable decoding error.

In the vulnerable C implementation, this allows the decoder to continue processing invalid state and eventually write beyond an internal buffer. Depending on the exploitation conditions, the resulting memory corruption can lead to process crashes, information disclosure, or arbitrary code execution.

The issue was initially disclosed through Node.js security updates on October 21, 2026, with subsequent research demonstrating successful RCE against vulnerable Node.js applications.

However, because the vulnerability originates in Brotli rather than Node.js itself, its impact extends to other software that incorporates vulnerable decoder implementations.

Sweet Security Research: The Go Implementation Is Vulnerable Too

Think only the C implementation was vulnerable? Think again.

During its investigation into HTTP2Shell, Sweet Security engineer Tomer Ben Gera identified that the Go port of Brotli, github.com/andybalholm/brotli, contained the same underlying decoder error-handling flaw.

The Go implementation had received a corresponding upstream fix on October 23, 2026, in commit 33c2a98, which ports the original C remediation.

Sweet Security went beyond examining the patch: our research team successfully reproduced the vulnerability against Go Brotli v1.2.6.

Exploiting the Go Brotli Decoder

Using a specially crafted Brotli-compressed HTTP request, our researchers triggered an out-of-range memory access inside the decoder.

The resulting Go stack trace shows:

runtime error: index out of range [8] with length 8

github.com/andybalholm/brotli.decodeDecompressStream(...)
github.com/andybalholm/brotli.(*Reader).Read(...)

Unlike the C implementation, where memory corruption can potentially lead to RCE, Go's runtime bounds checking converts this invalid access into a panic.

Nevertheless, the vulnerability presents a denial-of-service risk. Depending on how the application handles panics, exploitation could disrupt requests or terminate the affected process.

In our demonstration, the malicious request caused the HTTP handler to panic and close the connection without a response. The application remained alive, confirming a reproducible request-level failure without demonstrating full process termination.

‍

Why This Matters

The affected Go Brotli library is used directly or indirectly by several popular HTTP projects:

These projects collectively represent a substantial deployment footprint, with Traefik alone exceeding one billion cumulative Docker image pulls.

Importantly, having the affected library as a dependency does not automatically make an application exploitable. Exposure depends on the deployed version, whether Brotli decoding is enabled, and whether attacker-controlled compressed data reaches the vulnerable decoder.

For example, applications that only use Brotli to compress outgoing responses are not exposed through that encoding path.

Still, the finding demonstrates why remediation efforts focused exclusively on Node.js and C-based dependencies may overlook vulnerable Go infrastructure.

Detecting and Blocking HTTP2Shell with Sweet Security

HTTP2Shell is particularly challenging for traditional vulnerability management because vulnerable decoders may be embedded inside application runtimes, statically linked Go binaries, or bundled with other software.

Sweet Security addresses this challenge through runtime visibility, exploit detection, and virtual patching that blocks malicious activity inside running workloads.

Sweet's sensors can identify suspicious execution behavior associated with Brotli exploitation. In an RCE scenario, for example, a fork, clone, or exec operation originating from a Brotli or Node.js decompression call stack is a strong indication of malicious behavior: compression routines have no legitimate reason to spawn shells or execute arbitrary commands.

Sweet can detect and block these execution attempts using their runtime context, rather than relying solely on static signatures or known malicious payloads.

Additionally, Sweet's Virtual Patching capability enables security teams to enforce targeted protection against vulnerable code paths, blocking exploitation attempts while engineering teams test and deploy permanent patches.

For Go-based denial-of-service exploitation, where no child process is created, protection must target the vulnerable decoding path itself. Process-execution detections alone would not identify the panic demonstrated in our research.

By combining runtime vulnerability intelligence with active enforcement, Sweet helps organizations reduce exposure without waiting for their entire patching cycle to complete.

What Security Teams Should Do

Organizations should immediately assess their exposure to HTTP2Shell across all affected application stacks, rather than focusing exclusively on Node.js.

Recommended actions include:

1. Patch vulnerable components. Upgrade Go Brotli (github.com/andybalholm/brotli) to v1.2.7 or later, and update affected Node.js and Brotli C implementations to their respective patched releases.
2. Inventory Go HTTP infrastructure. Identify services using Brotli directly or through frameworks such as Traefik, Fiber, Iris, and fasthttp.
3. Verify runtime reachability. Determine whether applications decompress Brotli data from untrusted HTTP requests, responses, or other attacker-controlled sources.
4. Monitor for exploitation. Investigate unexpected decoder panics, HTTP request failures, abnormal process execution, and suspicious outbound connections.
5. Apply runtime protection. Use virtual patching and targeted blocking to reduce exposure while permanent remediation is underway.

Final Thoughts

HTTP2Shell is another reminder that vulnerabilities in foundational libraries rarely remain confined to a single application or programming language.

Sweet Security's successful exploitation of the Go Brotli implementation demonstrates that even memory-safe languages are not immune to vulnerabilities in shared decoding logic. While Go's memory safety significantly limits the consequences compared to C, attackers can still exploit malformed input to disrupt application availability.

As the scope of HTTP2Shell continues to evolve, organizations need visibility into what their applications actually execute, which vulnerable code paths are reachable, and whether exploitation is occurring in production.

Sweet Security continues to monitor HTTP2Shell, investigate affected implementations, and provide customers with updated detection and protection capabilities as new findings emerge.

‍