Well, whoever picked the name HTTP2Shell certainly didn't use any intelligence, artificial or genuine.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
I think we've all seen where an LLM names a session, issue, or PR based on its early understanding and fails update it later.
AI isn't being asked to review the title, and it doesn't have experience or think, so of course it's not going to flag it.
No human reviews anything anymore so of course they aren't going to catch it.
Edit: AI for as good as it is at "writing" is terrible at writing and particularly at naming things. I had an AI name a client OpenAICompatibleEmbeddingClient. "Brooooo.. I think "compatible" is implied, who names stuff like that?!"
Much prefer the Broccoli2Shell name & site (for the same vuln): https://broccoli2shell.com/. For starters, I'm pretty sure you can hit this without HTTP if you do any manual Brotli decoding, HTTP just happens to be the most common case that comes up.
No, they aren't. The website doesn't list an author, so fame is out of the question, and they say exactly how severe the bug is rated ("Rated 9.2 Critical (CVSS 4.0) by GitHub, High by Node.js.") right at the top.
I'm not seeing any source for the claim that OpenAI discovered this in February. The source that the article links (a tweet by OpenAI) doesn't claim that.
To me, the surprising part is how many of these implement brotli compression of request (not just response) bodies, given how obscure a feature that is.
In any case all this sensationalism is starting to get annoying. Patch your stuff and move on.
Edit: actually, between all the sensationalism, its hard to tell from the article how many of these actually support brotli compressed request bodies in common configs vs some other use of brotli (which is bad but nowhere near as critical)
It seems like node supports it with body parser enabled.
But im having trouble finding any docs suggesting anything else supports it on inbound requests.
Obviously there are other scenarios where it is exploitable, but it is a much less severe vuln if the attacker must first force the program to make an outbound request to a server of its chosing rather than just connect to a vulnerable server.
According to Claude when I asked it to audit one of our Python applications, there are scenarios where Brolti can be used only when some Python library detects that the C library is installed on the system. So your Brolti-ness can depend on which machine your code runs on. Ymmv, it didn't look to be a practical possibility in our code so I didn't probe further.
These chat bots always hedge like that. They will never give you a straight answer, it's always "depending on version and build configuration and system configuration".
Investigate yourself. Read the documentation. Grep for brotli in the source. Don't blindly trust a chat bot when it says it "might happen in certain configurations".
Chat bot lol. It did all of those things including scanning the binary. I ran it after doing my own (albeit more limited, but maximal-human) investigation.
I wonder if we'll see more of this thanks to AI. Extremely complex features that nobody uses and that were easy to add, which incidentally tremendously expand the attack surface. One would hope that maintainer would be wise to avoid that, but for how long?
https://github.com/tmux/tmux/pull/5709/changes it is already happening. Nice 50 lines of C-code to add support for kernel-keyrings which no userland software uses and literally is a one-line config-option.
I'm not saying that my experience translates 1:1. As a child of domestic violence, all I can say is that it never gets better. Sadly, my feeling is that the violence will only escalate from here. If you look at the bright side, you can earn your stripes as a legitimate infosec engineer and prove your worth to the industry and the world.
I'm sorry that happened to you. I tend to agree that the race to the bottom will continue.
And don't worry about my stripes, I'm mostly talking about my hobby self-hosted apps. If anything, should someone hack them I'll have a funny article to post on my blog. Professionally, I do things differently.
My experience with Brotli is from back when all the hype was mobile first and India etc was super mobile first so all these social networks lost their mind optimizing for request success and speed. So they were going crazy over micro-wins like that.
Article claims OpenAI found this in February, but I don’t think that’s correct. I think Google made a change to the Brotli source code in February that fixes the issue, but hadn’t realized it was a security issue and therefore hadn’t cut a release.
A few month ago, everyone was advising to use cool-downs in your package upgrades. Now we're constantly overriding those because security incidents will be exploited immediately.
Guess that's just how it's gonna be from now on.
Yeah, obviously? Deploy fixes to security issues which apply to you as soon as possible, deploy random feature additions and non-critical bug fixes after some cooldown.
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.
Let’s say I have a node.js app behind an Amazon elastic load balancer which terminates TLS. My understanding is that in nearly all configurations, my app would be unaffected because the ELB would handle decompression. Is that generally correct?
I don’t know about that specific software, but I would be surprised if it decoded message bodies, which is entirely unrelated to TLS termination and shouldd be entirely unrelated to routing. So I would expect you would still be vulnerable.
An example of the cost of added complexity I suppose. Brotli is much more complicated than the gzip/deflate it replaces. ... and of course we still have to expose gzip to attack as well.
Every time you add something you lose something...
I had to check all of our Python deployments and installation BOMs and was quite relieved - turns out that none actually installed brotli libraries. HTTP libraries like httpx, requests and frameworks consider them optional and autodetect their presence.
And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.
So strictly we have to burn everything python to the ground and reinstall entirely.
Heh. This is part of why I always preferred getting my python runtime and all these core libs from my linux distro packager. But python die-hards look at me like I'm insane when I suggest this.
Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.
It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.
It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!
But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...
I agree about getting libs (binaries especially) from my distro, and it generally seems to be regarded as the "wrong thing to do". Freezing anything that might mean you get security updates slower seems to be a mistake to me.
Or - you can just upgrade pip with a SHA hash pin, or set the magic env vars to use the system bundle.
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
Yep! I tested it with my own vibe-coded MITM proxy that hijacks pypi installations, which I created for ~$0.30 spend on DeepSeek API.
$ python -m pip --no-cache install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
Collecting pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
Downloading pip-26.2.2-py3-none-any.whl (1.8 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 570.0 MB/s 0:00:00
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70 from https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70:
Expected sha256 fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
Got 8c448177668e735cdde7d6178694b90c084ba18559348cc394c4b1546eeec89c
The second one works too:
$ PIP_USE_DEPRECATED=legacy-certs PIP_CERT=/etc/ssl/certs/ca-certificates.crt python -m pip install --no-cache --upgrade "pip>=26.2.2"
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082) - skipping
ERROR: Could not find a version that satisfies the requirement pip>=26.2.2 (from versions: none)
ERROR: No matching distribution found for pip>=26.2.2
As compared with a naive installation through the proxy:
Oh nice. Then I have to thank you for a possible non-horrible upgrade path. If you were close by, I'd invite you for some icecream or a round of pool :)
"In 2016, the Brotli algorithm shipped in Chrome, delivering overall better compression ratios for eligible resources."
"By the end of 2017, all modern browsers supported Brotli, and server support for it started to become more widespread."
For www users, all that data collection, surveillance and ad services traffic to enrich so-called "tech" companies acting as intermediaries, can make the www exceedingly slow
The way to "make the web faster" (or less inefficient) is to get rid of that needless traffic, and the ads it supports
SPDY,^1 HTTP/2 Server Push,^2 HTTP/3 QPACK,^3 brotli, .... make www users ("ad targets" to Google) uninformed, nonconsenting subjects in Google's failed experiments
The www already works just fine for its intended purpose (_not_ data collection, surveillance and ad services)
I agree with you, but the immediate problem here seems to be that all major browsers support Brotli, and i think they all use the Google library, so they are all vulnerable.
Most of the discussion here is about vulnerabilities in servers, but it looks like its mostly a client problem.
Is there a way to turn brotli off?
Going back to your point, if we kept things simple we would be a lot more secure.
"OpenAI found this in February reported it as unauthenticated remote code execution that works in both directions, so a malicious client can take over an unpatched server and a malicious server can take over an unpatched client that accepts compressed responses."
Every user is different
For me I'm a text-only user not interested in graphics
I do not use a so-called "modern" browser to make HTTP requests
I don't request brotli-compressed content/resources^1
Normally I don't send an Accept-Encoding header
Almost always servers to which I connect^2 will return uncompressed text, which is what I want. No Accept-Encoding header needed
Occasionally servers will send gzip-compressed text by default and will ignore "Accept-Encoding: identity"
However the popular so-called "modern" browsers will send an Accept-Encoding header whose value includes brotli (br) by default
Unsuspecting www users are consequently opted in to Google's brotli experiment. Me, I opt out
1. I use a text-only browser (1.3MB static binary) to read HTML. I compile it without brotli support
2. Other users may connect to different servers. Preferences vary from user to user
git for windows is vulnerable even in its latest release (2.56.0.windows.3), careful pulling repos over https from random ass servers (prolly uncommon but hey). they already merged the fix on the repo, it's just in a snapshot build only; should prolly arrive on Monday (2.56.0.windows.4).
also affects codex (gui), which ships its own git, could be more of a problem there, when the LLMs get quirky at night. still unlikely to be a problem though.
speaking of, update codex (and wipe its cache at ~/.cache/codex-runtimes), ships its own node. update python.
stuff like wireshark and imhex remain vulnerable, even on their latest repo commits, which may or may not be spicy.
also Microsoft 365 Copilot still has its own unpatched brotlidec.dll from Oct 7, if anyone uses that. no fix available for that one afaik, not sure about how it can be made to access the vulnerable decoder.
Because a local software vuln is much less scary, less exploitable, and more common than an exploit like PHP2Shell, which requires basically no effort to exploit a large chunk of publicly exposed webservers. Basically, local vulns have been a thing forever and GP is off topic.
the article above is about a defect in google's brotli compression library (CVE-2026-111497). compression libraries don't really do web serving, or communicate with networked resources at all, they're hermetic. so exposure depends on the context this library is deployed in as a dependency.
put it in the network path, it can become an RCE.
put it in a privileged context, it can become privilege escalation.
put it in a hardened environment, it can become completely inert.
in no sane perspective is me listing off the applications shipping with vulnerable versions of this codec off-topic. just because the article is hellbent on portraying this as some sort of second php2shell, the actual underlying issue here is still CVE-2026-111497.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
Lots of apps will, for example, bring in your Google avatar (i.e. they fetch its URL for ingestion) as a default avatar if you use them for SSO. Slack included, IIRC.
I really don't understand how so many different things are affected by the same brotli bug/exploit.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Yes. All these language runtimes compile against common libraries. Compression libs are one of the most common common libraries that platforms like node, ruby, dotnet, python, and etc need to compile.
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.
Brotli was a library released by the Google team that developed it. There weren't lots of independent implementations; they were all from the same source code.
As I've mentioned numerous times at this point, relying on third party code is a massive liability (supply chain attacks/sloppy code). My hand rolled brotli implementation is not only faster than libbrotli but also immune to this vulnerability (yes, I checked). Roll your own code people.
Honestly it's time to get rid of C as a language used where security is a factor. Enough already. Why the hell is a lib like brotli that processes public general internet traffic, and maintained by google, not in rust?
Security is a factor everywhere. And C is everywhere. There's not going to be a "rewrite everything in Rust" project until after there is some legit penalty for selling / offering software in C that could be more secure in another language.
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
Why are we still so reliant on HTTP? HTTP came out in 1990 (36 years ago) and the most common version of HTTP still in use, 1.1 (RFC2616), came out in 1999 (27 years ago)?
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
HTTP 1 is full of parser differential vulnerabilities, which 2 fixes. That is probably its biggest flaw.
SMTP is too chatty - it uses too many round trips for efficient transfer across the internet. It can take several seconds just to get to the point of sending the email data. It also duplicates information between the SMTP envelope and the email body which creates vulnerabilities when they don't match.
For APIs that don't have to work in a browser I suggest JSON lines over TCP, or over TLS.
All webservers (apache, nginx, litespeed, caddy) have keep-alive enabled by default. All browsers also support it. Whether it's actually used/negotiated on most connections, I don't know, and if you want to be pedantic you're right that it can't be default by definition since you need the header to use it. But I suspect it actually is used for most connections nowadays.
Multiplexing is the default in HTTP/2 and 3. So you're still wrong.
So, for the sake of argument let’s say I am completely wrong, MDN is wrong, all of Stack Overflow is also wrong. Even still HTTP is slow. Slow as shit. Imagine trying to do a MS Teams call with 50+ participants with cameras on. It would be slow as shit for just a one-on-one call. A call with 50+ people would be ridiculously slower and would likely result in a crash from memory exhaustion.
I was also not talking about HTTP2 or 3. I was very clear about that. Reading is hard. HTTP is used in many different contexts outside the browser where 1.1 continues to dominate.
The primary reason developers want to keep HTTP around is familiarity and comfort. HTTP is great when you don’t compare to anything else or do any kind of performance tuning.
Agreed. The issue with all these archaic standards is that they were rolled decades ago back when certain practices were either outright not being employed OR that hardware wasn't fast enough. Ironically, HTTP itself is a literal nightmare to parse (performance wise) on top of having like... ten? distinct vulnerability classes. The world desperately needs new standards.
Just open a TCP socket and send JSON messages. Or if you want a bit more efficiency, fixed-format binary messages, but remember to include a version number.
For custom server implementations, agreed. But the web still depends on HTTP and we sadly need the major infra providers to agree on a new standard otherwise HTTP isn't going anywhere
Web uses web protocols, notweb uses notweb protocols. When I write an XMPP bot it has to speak XMPP, not HTTP. I could write my video game server to use XMPP but why the heck would I do that? If I choose a badly fitting protocol, it's on me.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
You might as well call it Exploit Pro Max...
AI isn't being asked to review the title, and it doesn't have experience or think, so of course it's not going to flag it.
No human reviews anything anymore so of course they aren't going to catch it.
Edit: AI for as good as it is at "writing" is terrible at writing and particularly at naming things. I had an AI name a client OpenAICompatibleEmbeddingClient. "Brooooo.. I think "compatible" is implied, who names stuff like that?!"
Now, whether it's warranted or not, that's another matter, but they know how to appeal for maximum awareness/interaction.
> but it wasn't recognized as a security issue at the time and no release shipped with the fix until now
I'm always getting my dangerous RCE bugs mixed up with my harmless RCE bugs.
I'm curious how this was reported and fixed back in Feb but nobody recognized the importance. A case of AI automation and nobody at the wheel?
In any case all this sensationalism is starting to get annoying. Patch your stuff and move on.
Edit: actually, between all the sensationalism, its hard to tell from the article how many of these actually support brotli compressed request bodies in common configs vs some other use of brotli (which is bad but nowhere near as critical)
So as a hotfix I block this on my reverse proxy.
It seems like node supports it with body parser enabled.
But im having trouble finding any docs suggesting anything else supports it on inbound requests.
Obviously there are other scenarios where it is exploitable, but it is a much less severe vuln if the attacker must first force the program to make an outbound request to a server of its chosing rather than just connect to a vulnerable server.
I hope my assets are not connecting to malicious servers, otherwise yes, I have a problem.
DotNet, however, has it's own C# Brotli implementation.
Investigate yourself. Read the documentation. Grep for brotli in the source. Don't blindly trust a chat bot when it says it "might happen in certain configurations".
Unfortunately that means understanding and limiting dependencies of developers... Yea, good luck.
My popcorn is ready. My servers are not.
And don't worry about my stripes, I'm mostly talking about my hobby self-hosted apps. If anything, should someone hack them I'll have a funny article to post on my blog. Professionally, I do things differently.
- git
- Sublime text
- VS studio
- CUDA
- .NET
- inkscape
- AzureTools
Maybe an LLM just happened to do one of those "while I'm here" fixes in Feb and because nobody reviews anything anymore..
"Fixed reading too many bytes."
LGTM!
Edit: I was close! "Detect and report invalid stream earlier." Could have been a person.
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.
Who turned on hard mode this week?
Apache and nginx don't handle brotli out of the box.
Every time you add something you lose something...
> Security notice: Upgrade certifi, pip, and uv in response to CA certificate incident
Blimey PIP is affected? That's bad. I feel like that should have been bigger news?
So strictly we have to burn everything python to the ground and reinstall entirely.
Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.
It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.
It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!
But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
Or alternatively, on Debian with fixed system cert chain: https://discuss.python.org/t/avoiding-compromised-certificat..."By the end of 2017, all modern browsers supported Brotli, and server support for it started to become more widespread."
For www users, all that data collection, surveillance and ad services traffic to enrich so-called "tech" companies acting as intermediaries, can make the www exceedingly slow
The way to "make the web faster" (or less inefficient) is to get rid of that needless traffic, and the ads it supports
SPDY,^1 HTTP/2 Server Push,^2 HTTP/3 QPACK,^3 brotli, .... make www users ("ad targets" to Google) uninformed, nonconsenting subjects in Google's failed experiments
The www already works just fine for its intended purpose (_not_ data collection, surveillance and ad services)
1. "As of 2021, no major browsers supported SPDY" https://en.wikipedia.org/wiki/SPDY
2. https://en.wikipedia.org/wiki/HTTP/2_Server_Push
3. https://foxio.io/blog/header-accordions-qpack-amplification-...
Most of the discussion here is about vulnerabilities in servers, but it looks like its mostly a client problem.
Is there a way to turn brotli off?
Going back to your point, if we kept things simple we would be a lot more secure.
Every user is different
For me I'm a text-only user not interested in graphics
I do not use a so-called "modern" browser to make HTTP requests
I don't request brotli-compressed content/resources^1
Normally I don't send an Accept-Encoding header
Almost always servers to which I connect^2 will return uncompressed text, which is what I want. No Accept-Encoding header needed
Occasionally servers will send gzip-compressed text by default and will ignore "Accept-Encoding: identity"
However the popular so-called "modern" browsers will send an Accept-Encoding header whose value includes brotli (br) by default
Unsuspecting www users are consequently opted in to Google's brotli experiment. Me, I opt out
1. I use a text-only browser (1.3MB static binary) to read HTML. I compile it without brotli support
2. Other users may connect to different servers. Preferences vary from user to user
also affects codex (gui), which ships its own git, could be more of a problem there, when the LLMs get quirky at night. still unlikely to be a problem though.
speaking of, update codex (and wipe its cache at ~/.cache/codex-runtimes), ships its own node. update python.
stuff like wireshark and imhex remain vulnerable, even on their latest repo commits, which may or may not be spicy.
also Microsoft 365 Copilot still has its own unpatched brotlidec.dll from Oct 7, if anyone uses that. no fix available for that one afaik, not sure about how it can be made to access the vulnerable decoder.
put it in the network path, it can become an RCE.
put it in a privileged context, it can become privilege escalation.
put it in a hardened environment, it can become completely inert.
in no sane perspective is me listing off the applications shipping with vulnerable versions of this codec off-topic. just because the article is hellbent on portraying this as some sort of second php2shell, the actual underlying issue here is still CVE-2026-111497.
How many clients only accept brotli?
So say you run a SaaS that allows for something like letting people set their Avatar from an image URL which gets downloaded.
As an attacker I setup a new server that serves only brotli and then submit that URL to the SaaS.
That's a clever example, but why would you do that? The avatar should be a static resource. As such, I'd only provide an upload file dialog.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
However, why not switch to the Rust lib when it was available? I suppose people at Dropbox are now pretty happy they did in 2016: https://dropbox.tech/infrastructure/lossless-compression-wit...
It's slower, though. Too high a price to pay for safety it seems.
There is a cost to conversion.
Dropbox switched to it a decade ago, so it's probably quite product-ready.
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
If you want something else you can take your pick based on need from dozens of other options
SMTP is too chatty - it uses too many round trips for efficient transfer across the internet. It can take several seconds just to get to the point of sending the email data. It also duplicates information between the SMTP envelope and the email body which creates vulnerabilities when they don't match.
For APIs that don't have to work in a browser I suggest JSON lines over TCP, or over TLS.
Multiplexing is the default in HTTP/2 and 3. So you're still wrong.
https://stackoverflow.com/questions/36517829/what-does-multi...
So, for the sake of argument let’s say I am completely wrong, MDN is wrong, all of Stack Overflow is also wrong. Even still HTTP is slow. Slow as shit. Imagine trying to do a MS Teams call with 50+ participants with cameras on. It would be slow as shit for just a one-on-one call. A call with 50+ people would be ridiculously slower and would likely result in a crash from memory exhaustion.
I was also not talking about HTTP2 or 3. I was very clear about that. Reading is hard. HTTP is used in many different contexts outside the browser where 1.1 continues to dominate.
The primary reason developers want to keep HTTP around is familiarity and comfort. HTTP is great when you don’t compare to anything else or do any kind of performance tuning.