The compressor you didn't know you were using

What happened

Know those Russian nesting dolls? You open the big one, there’s a smaller one inside, then a smaller one, and at the very end a tiny one you’d barely notice. Modern software is exactly like that. Your website runs on a framework, the framework on a runtime, and inside the runtime sit lots of small, bundled libraries. This time, one of the innermost dolls cracked.

That doll is called Brotli. It’s Google’s open-source compression library and one of the web’s core compression formats next to gzip: when browsers and servers send data packed up, they often use it. Researchers found an out-of-bounds write in its decompression part, the decoder: CVE-2026-111497. In plain terms, a deliberately malformed compressed stream can make the program write past the end of an internal memory area while unpacking. The result can be a crash, a memory leak, and under some conditions even remote code execution. The press calls it several names: Node2Shell, HTTP2Shell, and some researchers jokingly say Broccoli2Shell.

Fixed Brotli versions (1.0.10, 1.1.1 and 1.2.1) came out on 21 October 2026. That’s where the real story starts. Because so much software bundles its own copy of the library, out-of-band patches rolled in all week: Node.js on 21 October; Python’s Brotli packages, Bun, Envoy and Istio on 22–23 October; and on Sunday, 25 October, Microsoft with fixes for .NET 8, 9 and 10, Visual Studio and PowerShell. Around 26 October, PHP rebuilt its Windows packages for the second time in five days, just after the PHP2Shell fixes.

What struck me most: according to reports, the change fixing the root cause landed in Brotli’s source code back in February 2026. Nobody flagged it as a security bug at the time, and no release followed. The flaw was eventually reported by OpenAI’s Codex Security team; Node.js credits them with the discovery.

How worried should you be? As of 23 October 2026, no attacks in the wild had been reported, and the flaw wasn’t in CISA’s Known Exploited Vulnerabilities (KEV) catalog. There is, however, a public proof of concept (PoC, working demo code), and Imperva researchers showed code execution on an official Node.js build, though not on every attempt. Severity is disputed: scores range from 8.1 to 9.2, and the most likely impact is denial of service, meaning your service goes down.

Why it matters to you

If your company has a website, web shop or API running on Node.js, .NET, PHP (on Windows) or Python, Brotli is very likely in there. Even if the word never appears in your code: it’s enough that an HTTP client automatically unpacks compressed responses, or that the package was pulled in as a dependency of another package, a so-called transitive dependency.

The trap is that the usual routine isn’t enough here. Updating the system’s Brotli doesn’t fix applications that bundle their own copy. And the other way round: an updated package doesn’t protect you until you restart the running process or rebuild the container image.

No impact in Hungary is known yet, and at the time of research we found no warning from the Hungarian national cyber authority (NBSZ NKI) or regional data. Since many web services across the region run on .NET or Node.js, broad exposure is likely, but there are no hard numbers.

Red // attacker's view

The whole point of compression is that the unpacker turns small data into big data. In other words, it trusts what the package says about itself. That’s exactly what I build on.

According to public analyses, one part of the decoder signalled “bad data” and “need more data” the same way, and a fast path didn’t check which one it was. So a deliberately malformed package could get it to keep stuffing a small internal buffer past its limit. The fix is simple: on a format error it now stops hard.

I have two doors. Inbound: I send your server a compressed request body, and the framework unpacks it automatically. Outbound: your app fetches something from a foreign server (a webhook, a link preview, a crawler, an API call), and the HTTP client dutifully unpacks my response. I like that door better, because your firewall and your web application firewall (WAF) can’t see it. Removing the Brotli hint from your requests doesn’t help either: the server can still send a compressed response.

The most convenient part for me is that the word “Brotli” appears nowhere in your code, so you’d never think to look for it. I’ll admit it: getting all the way to code execution is hard, modern memory protections make it tough. But to take your service down, a crash is enough.

Blue // what to do now

Small business with an outside IT or hosting partner

Ask your partner today: does your website or web shop run on Node.js, .NET, PHP (Windows) or Python, and has it been updated since 21 October 2026?
Ask them to restart the services after updating, and if they run in containers, to rebuild the images.
If you run PHP on Windows, switch to the build ending in “-1” (for example 8.5.12-1) and check the download’s SHA-256 checksum on the php.net download page. PHP’s version output shows the same number, so you can’t tell from that.
If you’re on Node.js 20, 23 or 25, those no longer get fixes: plan the move to the 22, 24 or 26 line.

In-house IT or development team

Inventory where Brotli lives in your environment: runtimes, packages, lockfiles (the files pinning exact dependency versions), container images, CI, build and developer machines, bundled copies. Don’t rely only on your vulnerability scanner: according to reports, some tools initially didn’t reliably flag the affected Python package versions.
Prioritise by exposure: patch first the services that fetch untrusted URLs or accept Brotli-compressed request bodies.
Patch, rebuild, restart: Node.js 22.23.4 / 24.22.1 / 26.12.1, .NET 8.0.33 / 9.0.22 / 10.0.14, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Then verify the running binary really is the fixed one.
If you can’t patch right away: reject Brotli-compressed request bodies at the proxy, load balancer or WAF, turn off automatic Brotli decompression, and in Python remove the Brotli package (clients fall back to gzip).
Watch for the signs: repeated crashes of web-facing Node.js or .NET processes, a shell spawned under the web process, unexpected outbound connections.

For professionals: technical details

CVE: CVE-2026-111497, out-of-bounds write in the block-type switching code of the Brotli C decoder. Affected: Brotli 1.0.3–1.2.0; fixed: 1.0.10, 1.1.1, 1.2.1.
Scores: Google CVSS 4.0: 9.2 (critical); Red Hat CVSS 3.1: 8.1 (AV:N/AC:H/PR:N/UI:N); Microsoft CVSS 3.1: 8.1, “Exploitation More Likely”; Node.js: “High”.
Fixed versions: Node.js 22.23.4, 24.22.1, 26.12.1 (20/23/25 are end-of-life, no fix); .NET 8.0.33, 9.0.22, 10.0.14, 11 RC3; PHP Windows 8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1; Python Brotli 1.2.1, brotlicffi 1.2.1.0; Bun 1.4.4; Envoy 1.36.12, 1.37.8, 1.38.6, 1.39.3, 1.40.0; Istio 1.29.9, 1.30.6, 1.31.2; Go andybalholm/brotli v1.2.7.
Reachable paths: Node.js zlib, built-in fetch auto-decompression, Express 5 body parsing; ASP.NET Core request decompression and HttpClient automatic decompression (both off by default); PHP cURL when automatic decompression is enabled; Python urllib3/requests, httpx, aiohttp when the package is installed.
Linux: some Node.js and .NET builds use the system Brotli, others the bundled one; your distribution’s advisory is authoritative (backported version numbers).
Still unpatched per the public tracker (26 October): among others DuckDB, Apache Arrow, 7-Zip-zstd, p7zip, EDK II.
ATT&CK (editorial mapping): T1190, T1499, T1059, T1105, T1552.
Detection: the overwrite itself isn’t visible; watch post-exploitation behaviour (process spawn after a crash in the same workload, a shell under the web process, unexpected outbound connections), plus Brotli-compressed requests to endpoints that don’t normally get them.
Indicators: no official IOC list is known. Official guidance: Microsoft .NET security announcement (dotnet/announcements #494), Red Hat RHSB-2026-015, the Node.js October 2026 security release, the PHP Windows download page.

Péter // the chief's note

In a case like this, the first and most important thing is to assess our exposure fast enough. Until we know where the faulty component sits, we can’t properly set the order of patching or judge the risk.

With supply-chain problems at this level, that can be even harder than usual, because we simply can’t be 100% sure which build of which of our components uses the vulnerable code. The Brotli case shows this almost textbook-style. The library often isn’t even named in the code; an HTTP client quietly pulls it in, or it arrives as a dependency of another package. PHP’s fixed Windows package shows the same version number as the old one, with just a “-1” at the end of the file name. Some scanners initially didn’t reliably flag the affected Python packages. And updating the system library says nothing about whether applications carrying their own copy are fine.

And it’s even harder to pin down the real risk the organisation is running. Even the industry doesn’t agree this time: scores range from 8.1 to 9.2, code execution has only been shown with difficulty and not reliably, and the most likely impact is a service outage. What that means for us depends on which of our services accept compressed requests and which fetch data from foreign servers. And again, we can only answer that if we know where that component sits.

So here’s the question I’d close with: if a similar headline lands tomorrow morning, how long would it take you to say where the innermost doll is hiding in your systems?

Background report for professionals

The full research in one PDF

Timeline, actors, how the attack works, actions for each audience, technical details and source assessment. All in one place, printable and easy to pass on.

PDF · 7 pages · 211 KB · research revision v1

Open the PDF (English) Magyar eredeti (PDF)

What happened

Why it matters to you

The full research in one PDF

Sources