The Brotli Bug Behind Black October

Somewhere around the third week of October, people started calling it Black October, and the name stuck fast enough that nobody seems totally sure who said it first. One outlet tracking the story couldn’t even find the post that supposedly coined it. The short version is that several unrelated security problems landed in the same two or three weeks. PHP shipped emergency fixes on October 22 for two critical remote code execution bugs, the kind that let an attacker run code on a server without logging in first. php.net’s own changelog describes them, almost casually, as fixes to “avoid state corruption via bailout.” A certificate authority had private keys for eight intermediate certificates turn out to be weak. An open source AI gateway got hit with a supply chain attack through its own release infrastructure. And Node.js, on October 21, shipped a security release fixing ten separate issues, one of which is the one worth actually understanding, because it’s not really a Node bug at all.

That one goes by two names, Node2Shell and HTTP2Shell, and they refer to the exact same flaw, CVE-2026-111497. It lives in Brotli, the compression library that shrinks data before it travels over the web and expands it again on the other end. You’ve almost certainly never installed Brotli on purpose. It’s baked into your browser, into Node’s built in fetch, into web servers and HTTP client libraries across several languages, quietly doing its job every time a server sends back a compressed response. That invisibility is most of the reason this bug matters more than a single CVSS number suggests.

What actually went wrong inside Brotli is almost mundane, which somehow makes it worse. According to Node.js’s own security advisory, the decoder has an internal buffer meant to hold eight bytes at a time while it works through a compressed stream. Under one specific condition, an invalid switch between compression blocks, the decoder misclassified what should have been a hard format error as something closer to “I just need a bit more input.” So it kept appending incoming bytes to that eight-byte buffer instead of stopping. Feed it a stream crafted to hit that condition, and the decoder will happily keep writing past the end of a box built to hold a handful of bytes, into whatever memory happens to sit next to it. Depending on what’s sitting there, that can mean a crash, a leak of memory contents the attacker was never supposed to see, or, under the right conditions, running code of the attacker’s choosing with whatever permissions the decompressing process has.

It was reported by Khai Tran and Sylvie Mayer at OpenAI’s Codex Security team, and fixed by two of Node’s own core maintainers, Matteo Collina and Antoine du Hamel. That detail has fed into a bigger, noisier story this month about AI finding and exploiting vulnerabilities faster than humans can patch them. There’s something real underneath that story: security teams genuinely are using AI assistance to search for bugs like this one. But it’s worth not overreading it. A vulnerability getting found by a well-resourced research team and responsibly reported through the normal disclosure process is close to the opposite of the worst case people tend to imagine when they hear “AI found a security hole.”

Because the flaw lives in Brotli itself rather than in Node, it follows Brotli wherever Brotli goes. A fix exists now, both for the library itself and separately for everything that bundles a copy of it: Node, Bun, and Python’s own Brotli packages all needed and got their own patched releases, and that matters because plenty of web tooling pulls in Brotli support without anyone explicitly asking for it. Anything old enough to have already fallen out of support doesn’t get a fix at all, which is its own argument for not running unsupported software on anything facing the internet. If your stack touches HTTP and decompresses responses, which is most of what a web server or client does all day, there’s a decent chance Brotli is somewhere in the dependency tree whether you remember adding it or not.

As for how bad it actually is right now, the honest answer as of this week is that nobody has reported seeing it used in a real attack, and it isn’t on CISA’s list of vulnerabilities known to be under active exploitation. A public proof of concept exists, and it does reach full code execution, but only against a test build deliberately weakened to make the memory layout cooperate. Run it against an ordinary build and what you get is a crash and a small, limited peek at process memory, not a clean shell. That’s a meaningfully different risk profile than an actively exploited zero day, even though the underlying bug is just as real and just as worth fixing.

None of that is a reason to leave it unpatched. It’s a reason to patch calmly rather than in a panic, which is the thing Black October as a label tends to work against. The PHP bugs in the same news cycle trace back to an old, rarely touched corner of session handling, not some exotic new attack surface, and the Brotli bug traces back to an eight-byte buffer that’s been sitting there since 1.0.3. Neither one is the story of some brand new frontier of risk opening up. They’re the much older story of code that’s been quietly working for years turning out to have one bad assumption buried in it, found now instead of earlier partly because the tools for finding this kind of thing have gotten better. Update Node, update your Brotli dependencies directly if you’re pinning versions, and treat the Black October label as a useful flag that it was a busy few weeks for patching, not as evidence that the infrastructure under the web is coming apart.