I feel as though this should be googlebrotli2shell, not http2shell. Google deserves to take a bit of a reputational hit for this. This is a basic memory safety violation, from the same organization that does wuffs, that promotes Rust for memory safety, that has Carbon. zstd has high quality rust implementations and is from roughly the same time.

On top of that, the brotli library saw no releases for almost a full year, with the fix for this vulnerability being committed back in February. Google builds from main for all their projects, so were unaffected, but open source releases are a complete afterthought. Over 100 commits with miscellaneous fixes left languishing until a security incident forces a release.

This one again feels overblown, at least for servers. I just checked an org of over 200 GitHub repos. Node, Python, and C#. None of them are vulnerable... because none of them actually call the Brotli decoder. It's just not enabled by default on the server side, by the platforms themselves. This is much like the PHP bugs, where specific conditions have to be in play before you're actually vulnerable.

For clients? Sure, that's a bigger risk. Patch them. But bad guys aren't attacking your clients unless the clients connect to them. Don't stay up late to fix this.

(And yes, .NET is included here, because Microsoft's Brotli module is a binding for Google's vulnerable reference implementation.)

I could do without every memory bug getting a cute sensational name and marketing push, I have to say.

It looks like brotli <= 1.2.0 is vulnerable.

The python package has already been updated to 1.2.1. https://pypi.org/project/brotli/1.2.1/

I feel like normal security issues don't get much publicity. The PHP and eMudhra issues seemed severe, and worth publicity. But then with things like this, I'm not sure. Is this a severe issue? Or is it just a run of the mill issue that's only newsworthy because web security is on people's minds right now?

There’s apparently no writeup on exactly what was the fix. So I’m going to make a guess that this is the chromium commit that fixed the problem: https://source.chromium.org/chromium/chromium/src/+/224140d4...

And this commit contained a refactoring from BROTLI_BOOL to BrotliDecoderErrorCode so the situation was that probably one of the error conditions previously simply returned false but needed more detail about what went wrong to continue safely.

Well okay this change from `if (prev_ix < cur_ix)` to `if (prev_ix < cur_ix && cached_backward <= max_backward)` is also suspicious and could be an related or unrelated hardening fix.

Interestingly the commit that fixes this in brotli dates back to February https://github.com/google/brotli/commit/0ed4268a4401abcb4472...

Since I checked Rust servers should be fine since the brotli crate is not a binding on the C.

They just keep coming, don't they?

Likely mitigation: disable brotli (br) content-encoding on both sides

>A significant blast radius

Is it really so hard to write a 2 sentence tweet that you need an AI to do it for you?

This is a better article: https://www.aikido.dev/blog/python-packages-vulnerable-node2...

and this is the actual CVE report, which doesn't say much: https://www.cve.org/CVERecord?id=CVE-2026-111497

If you are using Python, you are affected if you use urllib3, requests, httpx, aiohttp, Scapy, and others, if they were installed when Brotli was also installed. You can mitigate by uninstalling brotli and brotlicffi, OR, strip `br` from Accept-Encoding on outbound AND reject `Content-Encoding: br` on inbound.

This is not a server-side issue (unless for some weird reason you're using Brotli decoding in your http request processing), it's client-side.

Thank you Paul for the write-up (https://opensourcemalware.com/blog/node2shell-affects-python)

Is Deno affected, too? It uses brotli by default. But I don’t know how it is implemented.

Here's the normal link:

https://x.com/AikidoSecurity/status/2113759110625906950

is flask hello world with gunicorn behind apache vulnerable?

The brotli commit under this is a state fix more than a bounds fix: DecodeBlockTypeAndLength used to return BROTLI_FALSE for both "needs more input" and "format error", so a stream truncated at a block-switch boundary is reported as invalid, and a caller that branches on that can be walked into the wrong path. The commit gives the function a BrotliDecoderErrorCode, adds a distinct BLOCK_SWITCH format error and keeps NEEDS_MORE_INPUT for the truncated case (google/brotli 0ed4268).

Worth checking before the panic: node vendors that decoder in deps/brotli, and its v24.x tree already carries the changed function, so 24.x is not exposing the old behaviour. What is exposed is anything still vendoring brotli from before February 2026, and "disable br" is a fine stopgap that leaves the decoder in place.

From the honeypot side, an HTTP/1.1-only decoy farm is blind to this class. Mine is: no h2 preface in 7,900 lines, so the sweepers can't tell me whether anybody is already trying it.

[flagged]

Another day, another buffer-overflow vulnerability in C code …

Brotli, another one of those pseudostandards[1] from Big G that I was avoiding all along. Dodged another bullet.

[1] When more than half of the "standard" https://www.rfc-editor.org/info/rfc7932/#page-44 is an opaque binary blob, they're really not encouraging independent implementations.

Edit: the votes really show what an echochamber for Big G this place has become. FUCK YOU, GOOGLE!