HTTP2Shell is not an HTTP/2 bug, and that's the scary part

Your team probably has a list of the frameworks it depends on. Does it have a list of the decompressors? HTTP2Shell is one of the names now attached to a remote code execution flaw hitting Node.js and, reportedly, Python libraries. Despite the name, the protocol isn't the culprit. A compression decoder is.

The bug lives in the decompressor, not the protocol

As Brandefense explains, this is one flaw, CVE-2026-111497, in the Brotli decoder that Node.js ships. It was first called Node2Shell, and since late on October 23 (UTC) it has also been called HTTP2Shell. Node.js fixed it on October 21, 2026 in versions 22.23.4, 24.22.1 and 26.12.1. The CVE record rates it 9.2 on CVSS 4.0. The advisory credits OpenAI Codex Security for the report.

Aikido says the same Brotli flaw affects many libraries and applications that use HTTP with Brotli or brotlicffi installed. Remote code execution on the official Node.js 24.22.0 image is, for now, what researchers reported. Aikido presents that as a report rather than its own test, and adds that the exploit did not work every time. Public proof-of-concept code reportedly crashes unpatched Node.js, but working RCE hasn't been shown in public code. In our view that distinction changes how loudly you should describe the flaw. It doesn't change how fast you should patch.

The wrong name points at the wrong layer

Calling it HTTP2Shell is understandable. The flaw shows up on the HTTP path, and the name is catchy. But it points people at the wrong layer. Nobody should go hunting for an HTTP/2 setting to switch off.

Brandefense's walkthrough, relaying Vercel's explanation, shows how ordinary the exposure is. Node.js doesn't decode Brotli on its own. An app is exposed when its own code, or a library it uses, decompresses attacker-controlled Brotli data. Researcher Ron Masas wrote on X that on a vulnerable runtime, "app.use(express.json) is enough". Brandefense says that matches what the Express 5 source does. A JSON request with a Brotli content encoding gets decoded before your route code runs.

That is the uncomfortable part. In many teams, we suspect, nobody wrote a Brotli feature and nobody reviewed one. The exposure arrived as a default behavior of something you did choose. And Brandefense notes that other middleware, frameworks, reverse proxies and your own code may also decode Brotli. Each of those is a place to check.

Patching has to become infrastructure work, not a sprint ticket

The timeline is the argument. Node.js shipped fixes at 10:38 UTC on October 21. According to Brandefense, the first GitHub repository for the CVE appeared about five hours later, and by late October 23 a search returned 25. In our view, defenders don't get a grace period once patches can be compared with the old code.

The same day, PHP shipped its own fixes for the separate PHP2Shell flaws. The University of Toronto's security team warns that mass exploitation is expected quickly and that Cloudflare had already reported early attacks. We don't want to merge two unrelated bugs into one story. But two critical runtime flaws landing together is what a bad week looks like when so much runs on a handful of shared runtimes.

There is a second lesson, about end-of-life software. Brandefense quotes Vercel as saying Node.js 20 "will not receive this fix". Teams parked on an unsupported runtime aren't one patch behind. They have no patch to apply. That is a budget decision made months ago coming due in a weekend.

Wiz argues in its PHP2Shell write-up that frontier AI models let it develop and adapt working exploits in hours. We'd treat that as a claim worth taking seriously, not as settled fact. If it holds up, the old comfort that a flaw is too complex for anyone to exploit gets weaker.

Monday's job: inventory, upgrade, assign an owner

Our recommendation is plain. Check your versions with node --version, and find every place your code or a dependency decompresses Brotli from outside. Upgrade to the fixed releases, and move off Node.js 20. Don't run GitHub proof-of-concept code outside an isolated lab, because exploit code from unknown accounts can hide malware.

The bigger change is organizational. Runtime and library updates shouldn't wait in a backlog behind feature work. They should have an owner, an inventory and a same-week deadline. A flaw like this won't be the last, and we think the teams that treat it as routine infrastructure maintenance will be the ones who barely notice the next one.