The Brotli vulnerability now tracked as CVE-2026-111497 is a buffer overflow in a compression library you almost certainly run and almost certainly never installed. It reached CISA’s Known Exploited Vulnerabilities catalogue on 27 October, which moved it from a theoretical risk to an observed one.
Most of the write-ups in circulation were published between 22 and 26 October and say there is no known exploitation. They were accurate when they went out. They are not any more, so check the date on whatever you are working from.
Whether this matters to you comes down to one question: does anything in your estate decompress Brotli data that an attacker can supply? For a lot of .NET applications the answer is no, and Microsoft says so explicitly.
What the Brotli Vulnerability Actually Is
Brotli is a compression format and library from Google. It sits behind the br content encoding that web servers and browsers negotiate for ordinary page traffic, and it is bundled into a long list of runtimes, proxies and language packages.
The National Vulnerability Database describes the flaw like this:
A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream.
Two weaknesses are recorded against it: CWE-252, an unchecked return value, and CWE-787, an out-of-bounds write. The first causes the second. The decoder fails to check a return value, carries on with state it should have abandoned, and writes past the end of a buffer.
The Brotli vulnerability affects Google Brotli 1.0.3 through 1.2.0, on every platform. The fix is in 1.0.10, 1.1.1 or 1.2.1, depending which branch you are on. Google published 1.2.1 on 21 October with a one-line release note: out-of-bounds write permits remote code execution.
You will also see this called Node2Shell, HTTP2Shell, Brotli2Shell and Broccoli2Shell. Four nicknames for one flaw is no help at all when you are searching a ticket queue or a vendor portal, so keep the number: CVE-2026-111497.
At Transputec the first thing we do with a disclosure like this is separate the three questions that usually get merged: do we have it, is it reachable, and how fast does it have to be fixed. They have different answers and different deadlines.
It Reached CISA's Exploited List on 27 October
CISA added CVE-2026-111497 to the Known Exploited Vulnerabilities catalogue on 27 October 2026. The entry is titled “Google Brotli Unchecked Return Value Vulnerability” and carries a remediation due date of 10 November 2026.
That date does not apply to you, and it is worth being precise about why.
It comes from Binding Operational Directive 26-04, issued on 10 June 2026, which superseded BOD 19-02 and BOD 22-01. It is compulsory for US Federal Civilian Executive Branch agencies. The directive states that it “applies to agency assets in any federal information system”, and that “unless directed by the governing procurement contract, this Directive does not apply to contractors”. A UK business has no obligation under it at all.
What the listing tells you about the Brotli vulnerability is the part that matters. CISA adds entries on evidence of active exploitation, so the honest summary of this flaw changed on 27 October. It went from a serious bug with a public proof of concept to a bug that somebody is using.
Two qualifiers, both from the catalogue entry itself. The field for known ransomware campaign use reads “Unknown”, and CISA has not flagged the entry for forensic triage. Neither is reassurance, but it does mean there is no published link to a ransomware operation yet.
Not sure whether Brotli is even in your estate?
Brotli arrives inside other software, so answering that means looking at runtimes, build artefacts and dependencies rather than an installed-software list. Book an initial security consultation with a Transputec security architect.
Book a consultationIs It a 9.2 or an 8.1? Both, Depending on Who Is Scoring
The severity figures published for the Brotli vulnerability do not agree with one another, and the disagreement is informative rather than sloppy.
| Source | Score | Scale | Rating |
|---|---|---|---|
| Google, as CVE numbering authority | 9.2 | CVSS v4.0 | Critical |
| Microsoft, in its .NET advisory | 8.1 | CVSS v3.1 | High |
| Node.js | not scored | High | |
| NVD | none yet | Undergoing Analysis |
Google assigned 9.2 using CVSS version 4.0. Microsoft scored its own advisory at 8.1 using version 3.1. Node.js called it high without a number. The NVD record was published on 22 October and last modified on 28 October, and still sits at “Undergoing Analysis”, meaning NVD has not issued a score of its own.
There is a detail in Google’s vector worth pulling out. It contains AT:P, which in CVSS v4.0 means attack requirements are present: the attack does not succeed in all circumstances and depends on conditions outside the attacker’s control. A 9.2 carrying AT:P is a different animal from a 9.2 without it.
None of that argues for ignoring this. It argues for not letting one number drive the whole response when the vendors who own the code are telling you something more specific about their own products.
You Did Not Install Brotli, and That Is the Real Problem
Nobody procures Brotli. It arrives inside other things, and that is what makes the Brotli vulnerability awkward to respond to: the obvious question, do we run it, turns out to be the hard one.
Advisories so far name Node.js, .NET, PowerShell, the Python Brotli and brotlicffi packages, the Go implementation in andybalholm/brotli, Bun, Envoy, Istio, PHP builds for Windows, and Debian long-term support packages. CDNs and reverse proxies sit on top of that. F5 has said its NGINX Plus Brotli module does not use the decoder functionality directly.
That list is not complete, and treating it as complete is the mistake. Brotli is a transitive dependency: something you installed depends on something that depends on it. It will not show up in an installed-software inventory and it will not show up in a change record, because nobody ever made a decision about it.
This is the same shape of problem as the PHP2Shell vulnerability the week before, and the same shape as most of the serious incidents of recent years. The exposure was not in the application anybody wrote. It was in the layer underneath, which nobody owns and nobody lists.
So finding it means asking your build, not your asset register. Dependency manifests, lock files, container images, and software composition analysis output if you have it. If you do not have any of that, the runtimes above are your shortlist: establish your Node.js, .NET, Python and Go versions first, because that covers most of the ground.
The Question That Decides Whether You Are Exposed
Having the library is not the same as being exploitable. The Brotli vulnerability only fires where the decoder is handed attacker-controlled data, and whether that happens in your environment is a question of configuration rather than version numbers.
Microsoft is the clearest on this point. Its advisory of 25 October states:
ASP.NET Core request decompression and HttpClient automatic response decompression are not enabled by default.
So a stock ASP.NET Core application is not decompressing inbound Brotli unless somebody turned it on. Patch anyway. But that single sentence is the difference between an emergency change window and a scheduled one, and it is the most useful thing published about this flaw so far.
Node.js frames it as a condition too. Its October security release describes an attacker who can supply Brotli data that an application decompresses with node:zlib. If your code calls Brotli decompression on anything that arrived over the network, you are in scope. If it does not, you are patching a library you never feed.
The triage is three questions, in order.
Does this runtime accept Content-Encoding: br on inbound requests, or fetch and decompress remote responses?
Is the data it decompresses something an outsider can influence?
Is that path reachable without authentication?
Three yeses is an urgent patch. Two is this week. One or none goes on the normal cycle, and you should still patch, because the next finding in the same decoder will not wait while you re-run the analysis.
What to Patch, by Runtime
| Component | Affected | Fixed in |
|---|---|---|
| Google Brotli | 1.0.3 to 1.2.0 | 1.0.10, 1.1.1 or 1.2.1 |
| Node.js | 22.x, 24.x, 26.x | 22.23.4, 24.22.1, 26.12.1 |
| .NET 8 | below 8.0.33 | 8.0.33 |
| .NET 9 | below 9.0.22 | 9.0.22 |
| .NET 10 | below 10.0.14 | 10.0.14 |
| Python Brotli | 1.2.0 and earlier | 1.2.1 |
| Python brotlicffi | 1.2.0.x and earlier | 1.2.1.0 |
| Go andybalholm/brotli | before 1.2.7 | 1.2.7 |
One thing worth noticing about the Node.js release. The 21 October update carried ten CVEs, not one. Three others were rated high: two TLS hostname validation flaws and a DNS truncation issue, all of which are arguably more directly dangerous to an internet-facing service than a decoder bug that needs attacker-supplied compressed input to fire. If you upgrade Node.js to fix the Brotli vulnerability, you are fixing nine other things at the same time, and that is a better case for the change request than the one everybody is making.
Microsoft shipped its .NET patches out of band on 25 October, which tells you how Microsoft rated the urgency regardless of the default-off configuration.
The Deadline That Does Bind You Is 4 November
CISA’s 10 November date is not yours. Cyber Essentials, if you hold it, is.
The NCSC’s Cyber Essentials Requirements for IT Infrastructure v3.3 requires security updates to be applied within 14 days of release where the vendor rates the issue critical or high risk, where it has a CVSS v3 base score of 7 or above, or where the vendor gives no severity information at all. Microsoft rated the Brotli vulnerability high at 8.1. Node.js rated it high. Either route starts the 14-day clock.
Google published the Brotli fix on 21 October and Node.js shipped the same day, which puts that deadline at 4 November. Microsoft’s .NET patches landed on 25 October, so those are due by 8 November. Both land before CISA’s date, and unlike CISA’s, they carry a consequence you actually care about at renewal.
There is a second clause worth knowing, because it closes the obvious escape route. Where a vendor bundles fixes of differing severity into one update, and any of them is critical or high, the whole update has to go on within 14 days. The Node.js release is exactly that case. You cannot take the TLS fixes and defer the rest, or defer the lot because the Brotli element looks conditional in your environment.
We have written up the five Cyber Essentials controls in full. Security update management is the one that fails assessments most often, and it fails on exactly this: a defensible reason for not patching something, with nothing written down.
Two of These Landed on Consecutive Days
Worth stepping back for a moment.
On 21 October we published on PHP2Shell, two critical PHP flaws. Those are CVE-2026-109618 and CVE-2026-109619. CISA added them to the exploited list on 26 October with a remediation due date of 29 October. The NCSC issued a UK alert on that one, Critical security issue affecting PHP.
The Brotli vulnerability went onto the same list the following day.
Two unauthenticated memory-corruption flaws, listed as actively exploited on consecutive days, in components sitting beneath a large share of the web applications running in this country. Neither is in software anybody chose. Both are in the layer that simply comes with the stack.
The difference in the two deadlines is worth reading, because it is the closest thing to a public triage signal you will get. CISA gave the PHP flaws three days and gave Brotli fourteen. Same catalogue, same week, very different urgency, and the gap reflects how readily each one is being used rather than how bad each one looks on paper.
There is no NCSC advisory on Brotli as things stand. That is not a verdict. The NCSC publishes on a subset of what matters, and the absence of a UK alert is not evidence that something is safe. If a national advisory is what triggers your patch cycle, this pair is a good argument for changing that.
The pattern is the real lesson, and it has a cost attached. Each of these costs an unplanned day spent working out whether you run the thing, where, and in which version. Organisations that already hold that inventory spend an hour instead. Everyone else spends day one on archaeology, which is the worst possible day to be doing it.
The government has noticed the same gap, incidentally. The Budget 2026 cyber security package funds a new centre at the NCSC specifically to find exposed vulnerabilities across critical infrastructure and the wider economy. It will find yours. The question is whether you get there first.
Where to Start
The Brotli vulnerability is serious, very widely distributed, and now confirmed as exploited. It is also conditional in a way the headline number does not convey, and for some stacks, Microsoft’s included, the default configuration does not expose it.
So work in this order. Establish which runtimes you have and at what versions, from build artefacts rather than the asset register. Work out which of them decompress data that comes from outside. Patch those first and the rest on the normal cycle. If you run Node.js, upgrade regardless, because that release fixed nine other things.
Then write down what you checked and cleared, not just what you patched. Next quarter somebody will ask, and nobody will remember.
Our part in this is ordinary work rather than anything dramatic: vulnerability management keeps the inventory current so step one takes an hour, a managed SOC covers the window between disclosure and patch, and penetration testing answers the reachability question with more certainty than a configuration review. Transputec runs all three from a round-the-clock UK Security Operations Centre, and the first conversation is an initial security assessment rather than a proposal.
Talk to our team about the security work behind the headlines.
Frequently Asked Questions
What is CVE-2026-111497?
CVE-2026-111497 is a buffer overflow in the Brotli decoder, in the file c/dec/decode.c. A remote unauthenticated attacker who can supply a crafted Brotli-compressed stream may corrupt decoder state memory, disclose memory contents, cause a denial of service or potentially run code. Google scored it 9.2 critical under CVSS v4.0. It is also circulating under the names Node2Shell, HTTP2Shell, Brotli2Shell and Broccoli2Shell.
Which Brotli versions are affected?
Google Brotli 1.0.3 through 1.2.0 on all platforms. The fix is in 1.0.10, 1.1.1 or 1.2.1 depending on your branch. Downstream, update Node.js to 22.23.4, 24.22.1 or 26.12.1, .NET to 8.0.33, 9.0.22 or 10.0.14, the Python Brotli package to 1.2.1, brotlicffi to 1.2.1.0, and the Go andybalholm/brotli package to 1.2.7.
Is the Brotli vulnerability being exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalogue on 27 October 2026, and CISA lists entries there on evidence of active exploitation. Vendor write-ups published between 22 and 26 October state that no exploitation had been observed, which was accurate at the time but is now out of date. The catalogue entry records known ransomware campaign use as “Unknown”.
Does it affect .NET applications by default?
Not in a default configuration. Microsoft’s advisory states that “ASP.NET Core request decompression and HttpClient automatic response decompression are not enabled by default”, so a stock application is not decompressing attacker-supplied Brotli. You should still patch, and Microsoft shipped the .NET fixes out of band on 25 October, but the default-off position changes the urgency from an emergency change to a scheduled one.
Do UK businesses have to meet CISA's 10 November deadline?
No. The 10 November date comes from CISA’s Binding Operational Directive 26-04, which binds US Federal Civilian Executive Branch agencies and explicitly excludes contractors unless their contract says otherwise. UK organisations have no obligation under it. If you hold Cyber Essentials, though, the 14-day rule in the NCSC requirements does apply, which puts the Brotli and Node.js fixes at 4 November and the .NET fixes at 8 November.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
