HTTP2Shell: Everything We Know So Far

A vulnerability initially disclosed in Node.js has developed into a broader software supply chain security concern. Tracked as CVE-2026-111497, the flaw affects Google's Brotli decompression library, a component incorporated into multiple programming languages, runtimes and infrastructure products.

Initially referred to as Node2Shell, the vulnerability is also known as HTTP2Shell and Brotli2Shell. Its impact extends beyond Node.js to Python, .NET, Java, PowerShell, Envoy and other software that bundles or uses the affected decoder.

The vulnerability can potentially lead to memory disclosure or remote code execution. Security researchers have observed exploitation attempts and demonstrated code execution under controlled conditions. CISA has added CVE-2026-111497 to its Known Exploited Vulnerabilities catalog.

Here is what we know so far.

What is HTTP2Shell?

Brotli is a compression algorithm developed by Google and widely used to reduce the size of web content, including HTML, JavaScript, CSS and API responses. Browsers, web servers, application runtimes and HTTP clients use it to make data transfers more efficient.

When a system receives Brotli-compressed content, a decoder processes the compressed stream and reconstructs the original data.

CVE-2026-111497 is an out-of-bounds write vulnerability in Google's Brotli decoder, specifically in its block-decoding logic. A specially crafted compressed stream can trigger an invalid memory write during block-type transitions, potentially corrupting adjacent memory.

Depending on the affected application and execution environment, this can result in memory disclosure, application crashes or arbitrary code execution.

The vulnerability is in the Brotli decoder, not the HTTP/2 protocol itself. Although HTTP2Shell is a commonly used name, the issue can also be reached through software processing compressed files and other data.

Why does it affect more than Node.js?

Node.js was the initial focus because it bundles the vulnerable Brotli decoder. However, the same underlying component is incorporated into other runtimes, libraries and products.

This makes CVE-2026-111497 a shared-component vulnerability rather than an issue limited to one programming language.

Affected products and fixed versions

The following table covers major affected ecosystems. Fixed versions refer to vendor-patched releases; downstream distributions may backport fixes without changing the upstream version number.

Sources: Node.js security releases, Microsoft .NET advisory, Python Brotli, New Zealand NCSC, Field Effect's expanded product assessment.

The impact extends further. Research and vendor advisories have identified affected components in Envoy Proxy, Istio, Visual Studio, Palo Alto PAN-OS, Prisma Cloud Application Security Transporter Client, ClickHouse, DuckDB, Apache Arrow, MuPDF, FFmpeg through libjxl, and other projects that bundle Brotli.

Some of these products require specific configurations or processing paths to be exposed. For example, PAN-OS requires both TLS decryption and Brotli inspection to be enabled. Envoy and Istio exposure depends on Brotli decompression being configured. The .NET Framework is not affected, and .NET 7 remains affected without a listed fix.

Linux distributions also issue their own security updates and backports. Organizations should check distribution-specific package versions rather than relying only on upstream Brotli version numbers.

How can attackers exploit it?

The vulnerability becomes relevant when attacker-controlled data reaches a vulnerable Brotli decoder.

Network traffic: An attacker can send specially crafted Brotli-compressed data to an application or service that decompresses incoming requests or responses. This can happen through configured request decompression, HTTP clients or middleware.

File processing: Applications that process untrusted files may also reach the vulnerable decoder through embedded compressed data. Research involving JPEG XL and libjxl demonstrated that specially crafted image files could trigger the vulnerable code through file-processing workflows, including FFmpeg deployments.

The presence of an affected runtime or package does not automatically make an application exploitable. Exposure depends on whether the vulnerable decoder is present, whether the application uses it, and whether an attacker can control the data it processes.

HTTP2Shell exploitation: What has happened so far?

Attack activity emerged quickly after the vulnerability became public. Security researchers have reported automated scanning, exploitation attempts and demonstrations of code execution.

HTTP2Shell: Exploitation activity in the first 24 hours

Zscaler ThreatLabz, global deception network telemetry. These are observed events, not confirmed successful compromises.

Check Point Research independently reported suspicious activity in its own telemetry, including automated vulnerability scanning and probes targeting upload and ingestion endpoints. Its percentages represent a separate dataset and should not be combined with Zscaler's figures. Read Check Point's findings.

Evidence of exploitation has also become more significant:

• October 26: ELLIO reported detecting an exploitation attempt against Node.js 24.22.0.
• October 27: CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities catalog.
• October 29: NHS England reported active exploitation attempts and successful code-execution demonstrations against vulnerable Node.js builds. Read the NHS England alert.
• October 29: New Zealand's NCSC warned of active exploitation and publicly available proof-of-concept exploits. Read the NCSC alert.

Researchers have demonstrated that remote code execution is possible, but exploitation reliability varies across builds and environments. Some laboratory attempts resulted in application crashes rather than successful code execution.

There is no reliable public aggregate figure for the number of systems successfully compromised. The observed activity and government warnings nevertheless make this an urgent vulnerability to investigate.

What should organizations do?

Organizations should investigate exposure across their software environments rather than checking Node.js alone.

1. Inventory affected software: Identify Node.js, Bun, .NET, Python, Java, PowerShell, Envoy and system-level Brotli libraries.
2. Inspect dependencies: Check direct and transitive dependencies, including native libraries bundled inside application packages.
3. Assess exposure: Determine whether applications, HTTP clients, proxies or file-processing workflows handle attacker-controlled compressed data.
4. Apply vendor updates: Upgrade to patched runtime and library versions. Where patches are unavailable, follow vendor guidance and consider disabling Brotli decompression on exposed paths where feasible.
5. Rebuild and redeploy: Update container images and self-contained applications. Updating a host package may not update a separately bundled library.
6. Monitor for suspicious activity: Look for malformed Brotli payloads, unexpected worker crashes, memory access violations and unusual processes or network connections.

For additional technical details on the Node.js implementation, affected versions and remediation, see CleanStart's CVE-2026-111497 security advisory.

The bigger issue: A shared component, a wider attack surface

HTTP2Shell demonstrates how a vulnerability in a shared software component can extend far beyond the product in which it is first discovered.

A Node.js-only assessment would miss potential exposure in Python packages, .NET applications, Java integrations, proxies, file-processing tools and operating system libraries. Security teams need visibility into the components their software packages, not just the products and runtimes they deploy.

For container environments, this means inspecting base images, application dependencies and bundled native libraries, then verifying that patched components have reached running workloads.

The priority is to identify every instance of the vulnerable Brotli decoder, determine whether untrusted data can reach it, and ensure that available fixes are deployed across the environment.