HTTP2Shell RCE

What Is HTTP2Shell RCE?

A flaw in the compression library that web traffic uses everywhere turns ordinary br traffic into code execution, in anything that decodes it. You will watch HTTP2Shell crash a worker and then read a deploy token out of memory, then run the response: block it at the edge, learn why that is not containment, upgrade the runtimes that bundle the decoder rather than the host package, prove the fix holds, and rotate the leaked credential. You walk away able to scope and contain a bundled-library flaw across every decode path, inbound and outbound.

What You'll Learn in HTTP2Shell RCE

• Explain how a flaw in a bundled compression library reaches remote code execution through ordinary Content-Encoding: br traffic, with no login or vulnerable app feature
• Identify every decode path a library flaw exposes, both inbound request bodies and outbound responses a service fetches
• Explain why blocking br at the edge is a stopgap and not containment, and why dropping br from Accept-Encoding does not help
• Carry out the real fix: upgrade each runtime that bundles the library and redeploy, rather than trusting the host's system package version
• Distinguish patching from containment by rotating a credential the attacker read from memory, which leaves no trace in the logs

HTTP2Shell RCE — Training Steps

1. A service that answers

   On 21 October 2026, fixes shipped for a flaw in the Brotli compression library, the CVE tracked as CVE-2026-111497 , nicknamed HTTP2Shell (also Node2Shell). The bug is an out-of-bounds write in the decoder that handles Content-Encoding: br . Any service that automatically decompresses br traffic can be pushed into corrupting its own memory, and despite the name it is not an HTTP/2 bug. Bob is not after any one company. He scans for services on a vulnerable build and works through whatever answers. Today one of them is Larksend, whose whole product is fetching and unpacking other people's URLs.

2. Fingerprint the stack

   Before sending anything crafted, Bob checks what the API runs. A plain request to the public health endpoint names the runtime and the framework behind it.

3. How HTTP2Shell works

   Bob does not need an account, an upload form, or a vulnerable plugin. The flaw is in the Brotli decoder bundled inside the runtime. A single malformed br stream pushes the decoder to write past its own buffer, and from there execution can be steered. He opens his notes on the request shape. They lay out the stream's structure and the flaw it abuses; the working trigger itself stays withheld. What matters is why ordinary compressed traffic reaches code execution.

4. Why br traffic reaches code

   The request targets any endpoint that accepts a compressed body. It does not exploit Larksend's own code. It exploits the decoder underneath it.

5. Fire the request

   Bob sends a br-encoded request to the API. The first attempts do nothing visible except knock a worker over, which is exactly what the advisory describes: the flaw crashes the process far more often than it lands.

6. What he takes

   Bob keeps sending. On a later attempt the overrun steers execution instead of crashing, and the response is the output of a command he chose, run as the node process. He reads the process environment and walks off with a live deploy token. One library flaw becomes the blast radius: remote code execution on the API, and a credential that can push to production.

7. Knowledge check

8. The alert lands

   Larksend's edge provider flagged a surge of HTTP2Shell probes, and the on-call lead pulls Alice in. Two services are crash-looping, not one.

9. Confirm the live build

   Alice starts on the API host. The crash signature points at the runtime, so the first thing to settle is which Node build is actually serving.

10. The box was already reached

    The alert said one worker log caught node spawning a shell. Alice reads the tail of the API worker log to confirm it herself.