Product showcase: Sweet Virtual Patching stops HTTP2Shell while fixes catch up
HTTP2Shell (CVE-2026-111497), the critical Brotli bug first known as Node2Shell, is a remote code execution flaw in the compression library inside Node.js, Bun, Envoy, Python and more. AI found it: OpenAI’s agents turned it up in late September during a high-compute red-teaming campaign.
Finding bugs is getting faster. Fixing them isn’t. HTTP2Shell shows why that gap matters, and how Sweet Virtual Patching protects running applications until the fixes land.
A bad stream, a broken decoder
Brotli’s decoder sits inside runtimes, HTTP libraries, proxies and frameworks, and it’s the first code to touch compressed data an attacker sends. As Sweet CTO Tomer Filiba explained, a malformed block-type switch can be read as a request for more input instead of an error, so the C decoder keeps going and writes past the end of an internal buffer. The result ranges from a crash to unauthenticated remote code execution, which researchers demonstrated against Node.js applications shortly after disclosure.
AI finds it in one afternoon. You patch it for weeks
Brotli isn’t one package. Sweet’s research team reproduced the same flaw in the most widely used Go port of Brotli, which sits underneath Traefik, Fiber and Iris. Each copy has to be fixed on its own: container images rebuilt and redeployed, single-executable apps recompiled, vendor bundles waited on.
The window also opened long before disclosure. The root-cause fix landed in Brotli’s public source code on February 27, unrecognized as a security fix, and sat for close to eight months with no release or advisory. Diffing every commit to every popular library used to be impractical. For an agent, it isn’t.
Attackers didn’t wait, either. In the weeks after disclosure, Sweet observed exploitation attempts in 88% of the environments it monitors. The industry’s answer so far has been more people: Bank of America CEO Brian Moynihan told CNBC the bank brought on 1,000 contractors to patch vulnerabilities surfaced by advanced AI models. Most organizations can’t do that, and none will out-hire the rate at which AI finds bugs.
Patch what’s running first, cover the rest
A CVE in an image tells you the vulnerable code exists, not whether it’s a risk. For that you need to know whether the library is loaded in a running process, whether that process decodes data an attacker can influence, whether the vulnerable code path has executed and whether the service is reachable from the internet. Those answers only exist at runtime, and they set the patching order.
Anything that can’t be patched right away needs a compensating control. Disabling Brotli decompression works where the application doesn’t need it, as long as it’s disabled in the application and not only at a proxy. Where it can’t be turned off, virtual patching stops exploitation of that one flaw without a code change. It doesn’t replace the permanent fix, but it buys the time to do it properly.
How Sweet Virtual Patching stops HTTP2Shell
Sweet’s eBPF-based sensor watches processes, files, network traffic and application-layer requests in running workloads, without sidecars or code changes. Virtual Patching is built on that runtime view.
See which services are actually exposed
For HTTP2Shell in Node.js workloads, Sweet answers those runtime questions. In the example below, brotli-libs is loaded and executed in a card validation service that takes public inbound traffic and handles PCI data, so Sweet raises the CVE’s base score of 9.2 to a Sweet Score of 10.
Sweet’s investigation view for CVE-2026-111497, with the vulnerable package mapped to a running, internet-facing service.
Block the exploit in one click
Once a team knows a service can be exploited, it can enforce a virtual patch in one click, with no code change or redeploy. For HTTP2Shell, the patch targets the point where the exploit does damage. When the Brotli decompression path tries to create a new process, the sensor blocks that system call. As Tomer put it, compression routines have no legitimate reason to spawn shells, so blocking the call stops the attack while legitimate traffic keeps flowing. When Sweet Attack, Sweet’s AI red-team agent, proactively proves a vulnerability is exploitable, it suggests the virtual patching policy for the team to enforce.
The exploit path for CVE-2026-111497, with the clone system call blocked before the shell could start.
See the patch working
When Sweet blocks an attempt, it reconstructs the exploit step by step:
1. A crafted Brotli body sent to the service failed decompression and landed in the stream’s error path.
2. The vulnerable function ran.
3. The corrupted handle’s callback pointed at attacker-controlled code.
4. That code tried to launch a shell command to download and run a script.
5. The last step, the kernel call to create the shell process, was blocked.
Security gets the evidence to treat the attempt as an incident, and engineering gets the exact frames behind the fix. Virtual Patching is available in supported environments.
Sweet’s exploit chain for a blocked HTTP2Shell attempt, from malformed stream to the blocked process creation.
Sweet covers the first 30 days
Any organization concerned about HTTP2Shell can block it directly with Sweet Safety Net, an extension of Sweet’s Virtual Patching, and for no cost. Sweet covers 30 days of protection, starting at deployment.
Final thoughts
AI will keep finding bugs that have sat dormant for years in code that’s now almost everywhere. That’s good news, but it moves the bottleneck. Security teams used to be limited by what they knew about. Now they’re limited by how fast they can fix it. The teams that come out ahead will know which findings are running, reachable and being hit, and will virtually patch those while the permanent fixes catch up.
