A flaw in the code that opens compressed data has put web servers, HTTP clients and other applications on the same security update cycle. HTTP2Shell, tracked as CVE-2026-111497, can corrupt memory when software decodes a malicious Brotli stream. The possible outcomes include crashes, exposed memory and remote code execution.
Node.js shipped security fixes on October 21, 2026. Since then, advisories have expanded the picture to other software that carries the same native decoder. An application can encounter the vulnerable code while accepting an upload or fetching a response from another server. As a result, a service’s outbound web connections can become an entry point into its own process.
One Decoder Sits Behind Several Names
HTTP2Shell and Node2Shell describe the same Brotli vulnerability. Despite its name, the issue does not require the HTTP/2 protocol. The affected component is the C library that decompresses Brotli data, wherever an application uses that implementation.
Affected upstream releases span 1.0.3 through 1.0.9, 1.1.0 and 1.2.0. Fixed releases are 1.0.10, 1.1.1 and 1.2.1. Software distributors can also backport the correction, so an upstream version string alone may not establish exposure.
Two conditions determine whether a particular installation presents an attack path. It must contain the vulnerable decoder, and attacker-controlled data must reach it. Merely finding Brotli in an inventory does not prove remote exploitability. Likewise, serving compressed pages does not establish that a server decompresses hostile input.
An Invalid Block Switch Keeps The Decoder Reading
Brotli organizes compressed data into blocks. When the decoder encounters an invalid block switch, the vulnerable implementation confuses a permanent format error with a temporary shortage of input.
Instead of stopping, the streaming decoder continues accepting bytes into an eight-byte internal buffer. Further input can extend beyond that buffer and corrupt neighboring decoder state. This is a memory safety failure inside native code, below the application logic that expects decompression to return ordinary data or an error.
The correction makes the decoder report the invalid format and propagate that error. Consequently, the fixed path stops processing the malformed stream. A program’s use of a managed language does not remove the risk when its decompression work enters the vulnerable C implementation.
A Server Can Become The Attacked Client
Incoming request bodies provide one route. For example, middleware that accepts Brotli-compressed bodies can decode them before a route handler examines the resulting content. A bare Node.js HTTP server, however, does not decompress those bodies automatically.
The response route reverses the roles. An application calls fetch() and receives a response marked with the br content encoding. Its HTTP client then decompresses the response inside the application’s process. If an attacker controls that response, they control the decoder’s input.
URL previews, crawlers and configurable integrations illustrate why this matters. The application initiates a legitimate connection, but the returned compressed data crosses a trust boundary. An inbound web application firewall therefore does not necessarily inspect the response that the application retrieves from elsewhere. Blocking compressed uploads alone leaves this separate path in place.
Code Execution And Field Activity Are Different Evidence
Code execution has been demonstrated on an official Node.js 24.22.0 Linux ARM64 build through fetched responses and incoming Express request bodies. The demonstration required repeated attempts, so it does not establish reliable exploitation against every application or architecture.
Separate testing reported code execution on Linux x86-64 against the same Node.js release. However, build-specific memory layout and application behavior still affect the outcome. A crash demonstrates an impact on availability; it does not, by itself, prove that an attacker obtained a shell.
An October 26 sensor update describes an exploitation attempt targeting Node.js 24.22.0 on x86-64. That observation goes beyond the earlier reporting of exposure scanning. Successful compromise of a production victim remains unverified in the evidence reviewed here, and the report does not establish a widespread campaign.
PHP Windows Builds Need A Separate Dependency Fix
PHP2Shell concerns two different PHP engine vulnerabilities, CVE-2026-109618 and CVE-2026-109619, with an advisory also dated October 21. We covered those flaws in our PHP2Shell analysis. HTTP2Shell concerns Brotli, although PHP applications can reach that decoder too.
On October 26, PHP announced rebuilt Windows packages 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1, containing Brotli 1.2.1. In those builds, the cURL extension can reach the vulnerable code when automatic HTTP response decompression is enabled. That feature is off by default in cURL, but applications and HTTP libraries can enable it.
The -1 suffix identifies a dependency rebuild, while the underlying PHP source release and runtime version remain unchanged. Consequently, a familiar PHP version number can conceal an important package difference. Completing the earlier PHP engine update does not establish that the Windows package contains this separate Brotli correction.
Each Runtime Carries Its Own Exposure Conditions
Node.js released fixes in 22.23.4, 24.22.1 and 26.12.1. Meanwhile, Bun 1.4.4 includes Brotli 1.2.1. Executables built with an affected Bun runtime retain their embedded copy until a rebuild replaces it.
The .NET advisory, published October 25, describes another configuration-dependent path. ASP.NET Core and HttpClient do not automatically decompress Brotli in their default configurations. However, enabled request or response decompression, or direct use of BrotliStream and BrotliDecoder, can pass hostile data to the native decoder. The separate .NET Framework product is unaffected.
File processing provides further routes to the decoder. Tests reached it through JPEG XL metadata in FFmpeg and reproduced an endless decoding loop in Apache Arrow. These results demonstrate reachable failure paths, rather than universal code execution across those products. Application behavior, the actual decoder build and the source of its input determine the practical exposure.
Conclusion: The Decoder Inherits The Application’s Reach
HTTP2Shell turns a data-handling step into an execution boundary. An application can request an ordinary web response, then pass its compressed bytes into vulnerable native code. Because decompression runs inside that application, a successful exploit can inherit the service’s existing authority. The connection starts internally, while the dangerous input arrives from outside.
That distinction changes how exposure needs to be measured. Public request handlers are only part of the assessment; background integrations and file-processing jobs can reach the same decoder. Code execution demonstrations establish the risk in tested environments. However, the reported field attempt does not establish successful compromise across the wider software ecosystem.
Why This Threat Matters
- Service privileges shape the damage. A successful takeover can use the compromised process’s permissions, so service accounts and reachable resources affect the potential impact.
- Outbound features expand exposure. URL previews and configurable integrations can feed external data into a backend even when its public routes reject compressed uploads.
- Dependency copies age separately. A runtime, application package and deployment image can carry different decoder builds, so one upgrade cannot close every path.
- Availability can fail before takeover. Crashes and stalled decoding can interrupt work without a successful shell, although those symptoms alone do not prove exploitation.
- Version labels need context. The PHP Windows dependency rebuild illustrates why package revisions and vendor backports matter alongside the application’s familiar release number.
Where Defensive Control Must Operate
Defensive work starts at the decoder itself. Replace vulnerable builds wherever untrusted input reaches Brotli decompression. If patching must wait, reject the affected encoding before that path processes it, covering incoming bodies and fetched responses separately. An inbound firewall rule cannot establish coverage of the response path.
Xcitium Vulnerability Assessment supports discovery and prioritization of outdated software and exposed services across external infrastructure. That helps focus remediation on reachable entry points. Embedded decoder copies and internal client workflows still require application-level inventory and package evidence; a perimeter assessment alone cannot certify them as fixed.
On supported, managed Windows systems, Xcitium Advanced EDR provides behavior telemetry for investigating suspicious child processes or subsequent payload execution. Xcitium’s patented Zero-Dwell platform adds Execution Governance to restrict unknown executables’ access to real endpoint resources under the applicable policy. However, exploitation inside an already trusted runtime does not necessarily introduce an unknown executable. These controls complement the library fix; they do not establish prevention of this specific decoder exploit.
Verify The Build That Handles The Data
Closure needs evidence from the deployed application. Record the package revision or documented backport, identify which decoder the service actually uses, and restart or redeploy affected processes after updating. Rebuild artifacts that embed their own runtime. Finally, confirm that every identified input path reaches the corrected code. A completed update ticket is insufficient when a worker or separate executable still uses the earlier build.
