Rendered at 10:54:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mirashii 1 days ago [-]
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.
CodesInChaos 1 days ago [-]
> zstd has high quality rust implementations
On the decompression side yes, on the compression side the first good zstd rust port was announced yesterday. Until then, brotli was better supported in Rust than zstd.
But I agree, decompression libraries should be (mostly) memory safe nowadays, since that side is both easier to implement and more likely to be vulnerable.
kccqzy 21 hours ago [-]
Is there ever a demo of the "2shell" aspect here? Seems like the issue was fixed because it was thought to produce a hang. Has it ever been confirmed that the issue could result in an RCE? Or is this just hypothetical?
mirashii 16 hours ago [-]
Imperva claims to have demonstrated it, but didn't publish it openly (and their article screams AI slop, so take that for what you will).
All that said, we haven't heard the major cloud providers or security labs saying they've seen exploitation in the wild yet.
pjmlp 1 days ago [-]
Looking at the repo, some of the languages have their own safe implementations though, they don't use the C implementation directly.
However I guess testing isn't that great, probably.
1 days ago [-]
ataraxia937 1 days ago [-]
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.)
guac 1 days ago [-]
Doesn't node's fetch call the decoder automatically for `br` responses? So any attacker controlled content that a server fetch's may be vulnerable?
babuskov 1 days ago [-]
How did you check? Is there are PoC or some kind of command to run?
shakna 1 days ago [-]
Is your Brotli library built from older than the February commit? (The last tagged release is before then.)
If so, might be vulnerable.
Don't have Brotli enabled? Not vulnerable to this.
1 days ago [-]
Koffiepoeder 1 days ago [-]
The PHP thing is exploitable by now. No specific conditions needed. Stop spreading misinformation.
FreakLegion 1 days ago [-]
There were no known breaches or end-to-end exploits as of Friday. I've seen LLM hallucinations purporting to be exploits and real exploits missing pieces (address leaks), but nothing complete. Friends at some of the bigger IR practices (CrowdStrike CAO, Unit 42, Talos) have said the same thing.
It'll happen sooner or later, but all signs are that this was first and foremost a process nightmare. It wasn't another Log4Shell.
olabyne 22 hours ago [-]
The RCE was a know thing on Wednesday, without too much info. People started putting mitigation and orgs with valuable websites were shutting down servers.
Look at liveoverflow channel. Took him a good day with LLMs to find an exploit against a vanilla PHP instance.
It isn't a straightforward hack. But it is possible.
I can't find download numbers for extras, but it comes in the pretty dang innocuous-seeming `aiohttp[speedups]`, as well. Also `urllib3[brotli]`. Many, many people will be running these servers without recognizing the name of the library, especially in the agentic era.
I might be missing something obvious in your message, cause I don't see why server/client is relevant. Why would a frontend app speak a protocol that the backend doesn't?
deathanatos 1 days ago [-]
That's just the total number of times that package was downloaded, which is completely unrelated to how many servers it appears in? Same with `aiohttp`: aiohttp can be used as a client library.
Sure, people should check their dependency trees, and make informed decisions.
bbor 1 days ago [-]
Ok putting aside the "client" thing again assuming I'm just behind the times on python client-server architecture norms: What kind of vulnerability would concern you?
Sure, we can't say for sure that all 4 million of the jobs who downloaded (not built-with, but downloaded to cache anew) this library yesterday are running public-facing servers. But what subset of them might be? How much would it take before it's a concern?
Python feels particularly worrisome to me, as those are the kind of casually-setup servers on local dev boxes for some random little tool that are the most fertile ground for an exploit like this, where creds could be spread around in plaintext and malware could go unnoticed for a long time. And, of course, where the developers responsible probably aren't in the habit of watching the CVE list (yet...).
I hope I'm not coming across as rude -- I am honestly curious!
1 days ago [-]
vinyl7 1 days ago [-]
The whole package manager system is a complete disaster. A huge number of dependencies are pulled in that go unused in most projects, so the number of downloads is an extremely unreliable number. I'd be surprised if more than 10% of those downloads actually use the brotli decoder.
bbor 1 days ago [-]
Well first off I love PyPI and am greatly offended on the behalf of thew newly-formed (forming?) council to fix it, but also I don't think that applies in this case. If your server is capable of decoding brotli packets it's at risk -- you don't have to actually use that functionality regularly.
anonymous908213 1 days ago [-]
I could do without every memory bug getting a cute sensational name and marketing push, I have to say.
aaronbrethorst 1 days ago [-]
We should start naming them like hurricanes: NIST creates a list of alphabetical names and assigns any CVE >= 9.0 with a name. Vulnerability Alex (CVE 9.4)
ks2048 1 days ago [-]
Vulnerability Zzyzx in a week
nevir 1 days ago [-]
Tomorrow
ezm2131 1 days ago [-]
[dead]
cowlevel 1 days ago [-]
CVE scores are already inflated because it looks good for their discoverers.
duxup 1 days ago [-]
"Oh man, Jan really ruined my weekend."
I actually kinda like how that works.
my-huge-pony 1 days ago [-]
CVSS is a terrible proxy for vulnerability real world impact. Not to mention, that CVE with CVSS 10.0 in Bob's Flower Names library with 5 users is probably not that important.
lovich 1 days ago [-]
that ship sailed a while ago. Rowhammer is the first one I can remember
vinkelhake 1 days ago [-]
Let's not forget about heartbleed!
judge2020 1 days ago [-]
Back in the email days the virus authors named them, e.g. YouAreAnIdiot, ILoveYou
Waterluvian 1 days ago [-]
The Blaster virus was a fun one.
mhio 1 days ago [-]
That was the first exploit logo I can recall
weinzierl 1 days ago [-]
The most memorable one for me is DirtyCOW.
card_zero 1 days ago [-]
Rowhammer was kind of special, surely, what with being based on a physical design flaw?
Another day another out of bounds access in C code.
ks2048 1 days ago [-]
Can someone point the heart of this fix? I see a bunch of change of naming of constants, etc
red75prime 1 days ago [-]
As far as I understand it's line 1978: `goto saveStateAndReturn;`. Early return that prevents further processing.
cowlevel 1 days ago [-]
Doesn't mix up error-need-more-data with error-invalid-data
therein 1 days ago [-]
Had a short moment to glance at it. My guess would be BROTLI_DCHECK(s>meta_block_remaining_len <= (int)BROTLI_BLOCK_SIZE_CAP) along with BROTLI_SAFE_WITH_STATUS having that goto saveStateAndReturn on non BROTLI_DECODER_SUCCESS.
hatthew 1 days ago [-]
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?
Gigachad 1 days ago [-]
The whole industry is on edge right now, and numbers wise the CVE count has exploded beyond belief. It's probably to take the side of caution, treat everything as important and update everything promptly rather than the old way of doing things where libraries are left months or years out of date until something happens.
tdeck 1 days ago [-]
> I's probably to take the side of caution, treat everything as important and update everything promptly
The risk is that if people keep seeing headlines about some vuln emergency that isn't in fact exploitable in most cases they'll just start to ignore them.
cowlevel 1 days ago [-]
If your code ever accesses an HTTP URL that server can hack it. Some of the time, clients might be able to hack it too. This is comparable to the PHP issue.
oofbey 1 days ago [-]
I’d say this is reasonably severe. For a decently large class of servers exposed to the internet there’s a pretty simple way to RCE them. The actual set of vulnerable servers isn’t nearly as big as many would like to suggest. But if you’re running a node/express server, you should really be in panic mode right now.
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.
Until their agent realised there was a good chance of a press release in it.
robswc 1 days ago [-]
I am just amazed at how many people are blind to this.
Every single time one of these labs does something it is almost always sensationalized. They absolutely cannot refrain from describing how incredible their models are, it has to be injected into everything. I get this is basic grow-your-company stuff but it is getting obnoxious.
dofm 1 days ago [-]
I think — and this is not at all a criticism of your comment — that we all have to urgently get out of the habit of calling them “labs”, because in this way we reinforce their ability to portray themselves as sort of scientifically neutral observers of what is happening. I make this error all the time and I am trying to stop.
Though I got told off for saying it maybe too snarkily, I also think that when well-paid, high-profile employees of one of these LLM as a service companies post in controversial or notable ways that could affect the perception of their employer’s products, we should consider that they are acting as a spokesperson. Any tweet where you might think “do I need to consider how this relates to my employer’s SEC filings” is PR. Just because they are acting in informal ways doesn’t mean it’s personal opinion; we shouldn’t give it maximum benefit of the doubt.
Similarly, I think we have to consider that Patch The Planet may be vulnerable to perverse incentives.
robswc 18 hours ago [-]
I can agree. I believe the R&D component is very real but will take/has taken a backseat to the business.
SV_BubbleTime 1 days ago [-]
Chat, we need to constantly be justifying our absolutely absurd IPO. Use UltraMegThink and reference the ExploitToGetUsRegualtoryCapture.md. kkthnx
Sytten 1 days ago [-]
Since I checked Rust servers should be fine since the brotli crate is not a binding on the C.
doodlesdev 1 days ago [-]
Apparently it doesn't contain a binding to the C library, but it does contain some compatibility and shares design decisions with it. In other words, it's not a clean-room implementation from the spec, but rather it's a port. Since this RCE is triggered by a OOB access, it's unlikely to have made it into the crate, but it's good to keep these things in mind.
octoberfranklin 1 days ago [-]
Nope, run ldd on cargo; it links to libbrotlidec.so.1. Via libcurl.
Aren't you glad cargo connects to the network whenever it feels like it? I just love it when my build tool does that.
The real killer is the oath crate. Basically every rust project using OAuth is vulnerable. That's 398 projects on crates.io plus who knows how many binaries (a lot of non-library projects don't bother publishing to crates.io).
Another scary one is "a practical HTTP client that is fun" https://lib.rs/crates/isahc used in 317 crates including sequoia. In case you wanted somebody to steal your private keys.
iracigt 1 days ago [-]
I had some fun playing with this on Wednesday. After the node release, it was still about a day before the patched brotli package showed up on pypi.
Very easy to reproduce the with a single httpx.get(URL) in Python, but I couldn’t figure out an ASLR bypass from that context. Crashing is easy and I (with LLM assistance) can get some read/write primitives, but no chain into getting a function pointer where I needed it. Probably needs heap manipulation, but I lost interest at that point.
Really hoping we see an actual RCE PoC. Also, the open weight models can easily provide a "regression test" that would shoo away most crawlers.
oofbey 1 days ago [-]
Why are you hoping for an RCE PoC? Curiosity's sake? Or because you'd like to use it offensively? The existence/publication of such a PoC makes the world less safe.
iracigt 19 hours ago [-]
Curiosity. Calling it "node2shell" is a pretty strong claim. It is clearly the type of bug that can lead to code execution. What it takes to get there in the context of an http request is less clear.
As a practical matter, the impact could be pretty low. Very few things would accept brotli encoded data from a client. A PoC also doesn’t have to be for any particularly common configuration.
I’m someone who really enjoys reading Google’s Project Zero blog posts where they regularly walk through building exploits for phones and browsers. It gives you an appreciation for what is possible.
cowlevel 1 days ago [-]
Likely mitigation: disable brotli (br) content-encoding on both sides
thayne 1 days ago [-]
Unfortunately, AFAICT, there is no way to do this for node's fetch. I suspect there are other client libraries that don't have a way to disable it.
VladVladikoff 1 days ago [-]
>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?
kylepomykala 1 days ago [-]
They just keep coming, don't they?
Gigachad 1 days ago [-]
For as long as we still have C code accessible to the internet.
hoppp 1 days ago [-]
Never gonna stop. Consider it normal. Hey, at least humans still have a job. Incident response
awakeasleep 1 days ago [-]
Let's not kid ourselves, llm's are already doing the incident response for this in many infrastructure teams
chelmzy 1 days ago [-]
I would love to hear your definition of this. Are llms used to aid in incident response? 100%. Why would I sit there and manually review data from multiple sources when I could have an agent pull from all and summarize? But to hand it off end to end? I haven't seen anyone accomplish this.
hoppp 22 hours ago [-]
Handing it off completely is an incident waiting to happen.
What is the source of truth? If the LLM auto discovers when it needs to mitigate then it can get prompt injected. It's basically a backdoor into the system.
hoppp 1 days ago [-]
But they don't respond with fear and flailing arms!
brazukadev 23 hours ago [-]
Someone needs to be responsible for integrating the LLMs and reporting the results to the company. It is at least one job role in every serious project.
Is Deno affected, too? It uses brotli by default. But I don’t know how it is implemented.
gnabgib 1 days ago [-]
Deno is dead (baby)
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development
I know that it is dead but since they provide security updates for another year I haven’t migrated off of it immediately. Anyways, the Deno runtime uses a brotli Rust crate that does not wrap C code, and with unsafe off, so I assume it is safe.
gnabgib 1 days ago [-]
So a person of rhetorical questions? Great
csiegert 1 days ago [-]
No. After your unhelpful answer I started investigating if my deployment is affected.
Amsozzer 1 days ago [-]
I doubt it
userbinator 1 days ago [-]
Brotli, another one of those pseudostandards[1] from Big G that I was avoiding all along. Dodged another bullet.
Edit: the votes really show what an echochamber for Big G this place has become. FUCK YOU, GOOGLE!
johncolanduoni 1 days ago [-]
How do you suggest they provide the static compression dictionary?
userbinator 1 days ago [-]
You don't. Any real compression algorithm, including all the other standard ones, doesn't need such a thing.
Dylan16807 1 days ago [-]
Many compression formats support static dictionaries, and for a good reason. Short messages don't compress well. If you know a bunch of common data for a context, you can make the first several kilobytes compress a lot better.
chrismorgan 21 hours ago [-]
There are reasons why web content tends to compress better with Brotli than with Zstandard, and I don’t believe they’re algorithmic.
0xbadcafebee 1 days ago [-]
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.
HTTP requests can use content-encoding:br but this isn't normal in browsers so might not be implemented in many servers
QuadmasterXLII 1 days ago [-]
is flask hello world with gunicorn behind apache vulnerable?
cpburns2009 1 days ago [-]
Only decompression with Google's brotli library is affected. So if you use "Brotli" or "brotlicffi" in your Python app to decompress brotli, you're vulnerable. Compressing responses with brotli from Apache is safe.
TZubiri 1 days ago [-]
what I can say is that a 5 liner hello world starting with ‘import socket’ is not affected
whether a hello wolrd in fastapi is affected might also be interesting
Well for one you linked a bug that didn't lead to any known vulnerabilities. (And isn't an overflow.)
OCTAGRAM 1 days ago [-]
Ada is measured to have 9 times less bugs in average
caymanjim 1 days ago [-]
> Edit: why flagged
Rust Derangement Syndrome is at epidemic levels here.
gnabgib 1 days ago [-]
Check history, unconstrained
bogomind 1 days ago [-]
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.
cowlevel 1 days ago [-]
This is an AI karmabot and should remain flagged.
bibekadhikari 1 days ago [-]
[flagged]
thayne 1 days ago [-]
> refusing br content-encoding at the edge seems like the fastest mitigation.
That's pretty difficult if you make outbound requests, and don't already have a TLS interception proxy set up.
cowlevel 1 days ago [-]
This is an AI karmabot comment, it should remain flagged
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.
On the decompression side yes, on the compression side the first good zstd rust port was announced yesterday. Until then, brotli was better supported in Rust than zstd.
But I agree, decompression libraries should be (mostly) memory safe nowadays, since that side is both easier to implement and more likely to be vulnerable.
https://www.imperva.com/blog/node2shell-from-brotli-data-to-...
There's also a public POC here, though with the caveat that they demonstrated it only on builds with weaker configurations. https://github.com/dimasma0305/CVE-2026-111497-POC
All that said, we haven't heard the major cloud providers or security labs saying they've seen exploitation in the wild yet.
However I guess testing isn't that great, probably.
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.)
If so, might be vulnerable.
Don't have Brotli enabled? Not vulnerable to this.
It'll happen sooner or later, but all signs are that this was first and foremost a process nightmare. It wasn't another Log4Shell.
I can't find download numbers for extras, but it comes in the pretty dang innocuous-seeming `aiohttp[speedups]`, as well. Also `urllib3[brotli]`. Many, many people will be running these servers without recognizing the name of the library, especially in the agentic era.
I might be missing something obvious in your message, cause I don't see why server/client is relevant. Why would a frontend app speak a protocol that the backend doesn't?
Sure, people should check their dependency trees, and make informed decisions.
Sure, we can't say for sure that all 4 million of the jobs who downloaded (not built-with, but downloaded to cache anew) this library yesterday are running public-facing servers. But what subset of them might be? How much would it take before it's a concern?
Python feels particularly worrisome to me, as those are the kind of casually-setup servers on local dev boxes for some random little tool that are the most fertile ground for an exploit like this, where creds could be spread around in plaintext and malware could go unnoticed for a long time. And, of course, where the developers responsible probably aren't in the habit of watching the CVE list (yet...).
I hope I'm not coming across as rude -- I am honestly curious!
I actually kinda like how that works.
The python package has already been updated to 1.2.1. https://pypi.org/project/brotli/1.2.1/
Another day another out of bounds access in C code.
The risk is that if people keep seeing headlines about some vuln emergency that isn't in fact exploitable in most cases they'll just start to ignore them.
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.
https://nitter.jaydenha.uk/OpenAI/status/2113766354386084338
Every single time one of these labs does something it is almost always sensationalized. They absolutely cannot refrain from describing how incredible their models are, it has to be injected into everything. I get this is basic grow-your-company stuff but it is getting obnoxious.
Though I got told off for saying it maybe too snarkily, I also think that when well-paid, high-profile employees of one of these LLM as a service companies post in controversial or notable ways that could affect the perception of their employer’s products, we should consider that they are acting as a spokesperson. Any tweet where you might think “do I need to consider how this relates to my employer’s SEC filings” is PR. Just because they are acting in informal ways doesn’t mean it’s personal opinion; we shouldn’t give it maximum benefit of the doubt.
Similarly, I think we have to consider that Patch The Planet may be vulnerable to perverse incentives.
Aren't you glad cargo connects to the network whenever it feels like it? I just love it when my build tool does that.
There are 753 crates that drag in brotli this way: https://lib.rs/crates/curl/rev
The real killer is the oath crate. Basically every rust project using OAuth is vulnerable. That's 398 projects on crates.io plus who knows how many binaries (a lot of non-library projects don't bother publishing to crates.io).
Another scary one is "a practical HTTP client that is fun" https://lib.rs/crates/isahc used in 317 crates including sequoia. In case you wanted somebody to steal your private keys.
Very easy to reproduce the with a single httpx.get(URL) in Python, but I couldn’t figure out an ASLR bypass from that context. Crashing is easy and I (with LLM assistance) can get some read/write primitives, but no chain into getting a function pointer where I needed it. Probably needs heap manipulation, but I lost interest at that point.
Really hoping we see an actual RCE PoC. Also, the open weight models can easily provide a "regression test" that would shoo away most crawlers.
As a practical matter, the impact could be pretty low. Very few things would accept brotli encoded data from a client. A PoC also doesn’t have to be for any particularly common configuration.
I’m someone who really enjoys reading Google’s Project Zero blog posts where they regularly walk through building exploits for phones and browsers. It gives you an appreciation for what is possible.
Is it really so hard to write a 2 sentence tweet that you need an AI to do it for you?
What is the source of truth? If the LLM auto discovers when it needs to mitigate then it can get prompt injected. It's basically a backdoor into the system.
https://x.com/AikidoSecurity/status/2113759110625906950
and this is the actual CVE report, which doesn't say much: https://www.cve.org/CVERecord?id=CVE-2026-111497
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development
https://deno.com/blog/cloudflare
[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!
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)
whether a hello wolrd in fastapi is affected might also be interesting
https://news.ycombinator.com/item?id=50069499
Edit: why flagged
Well for one you linked a bug that didn't lead to any known vulnerabilities. (And isn't an overflow.)
Rust Derangement Syndrome is at epidemic levels here.
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.
That's pretty difficult if you make outbound requests, and don't already have a TLS interception proxy set up.