{"slug": "bye-bye-brotli-google-s-compression-library-is-a-security-mess", "title": "Bye Bye Brotli? Google's Compression Library Is a Security Mess", "summary": "A memory-corruption vulnerability in Google's Brotli decoder, tracked as CVE-2026-111497 and dubbed HTTP2Shell, can be triggered by a maliciously crafted Brotli-encoded payload and affects web servers that decode Brotli on untrusted input. Google fixed the flaw in a commit on February 27, 2026, but did not treat the attacker-controlled input overrunning an eight-byte buffer as a security issue, and a new Brotli release did not ship until October 21, 2026, after Node's security advisory had already gone public. The author argues the incident, alongside a November 2025 Brotli memory-exhaustion denial-of-service issue fixed only by an undocumented new parameter, shows the compression library is in a state of disrepair.", "body_md": "# Bye Bye Brotli?\n\n[Security](https://www.bugsink.com/blog/tags/security/)\n\nIs it time to say goodbye to Brotli yet? My vote is on yes.\n\nThis is where I’d love to same something smart about the vulnpocalypse, and how this is all super-relevant because\nof the new age of AI. I won’t, and instead will just say: the **Brotli package** is in such a **state of disrepair** that even\nmere humans would have been able to poke holes in it left and right.\n\nBut first: some anime, so you know this is actually serious:\n\n### This time\n\nSo what got us here?\nIt might have escaped your attention because the world was on fire over many security incidents\n(e.g. [PHP2Shell](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013),\n[eMudhra](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/),\n[Railway](https://blog.railway.com/p/security-disclosure-wednesday-october-21st) and\n[PingCAP’s breach](https://www.pingcap.com/trust-hub/security/security-update-october-2026/)) but we just\nhad a thing called [Node2Shell](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases). It’s now\ncalled [HTTP2Shell](https://www.aikido.dev/blog/python-packages-vulnerable-node2shell-brotli-cve-2026-111497) and\nI’d argue it should be called **Brotli2Shell** because that’s where the vulnerability actually is.\n\nWhat is it? It’s a **memory-corruption vulnerability in the Brotli decoder** that can be triggered by a maliciously crafted\nBrotli-encoded payload. Since brotli decoding is something that often happens with untrusted input, and in the case of\nweb servers: sometimes even simply on any request, this is a very serious vulnerability.\n\nThe [timeline](https://www.bugsink.com/blog/http2shell-timeline/) is somewhat sad though: Google fixed this in\n[February 27, 2026](https://github.com/google/brotli/commit/0ed4268a4401abcb4472096340477cf4af7d1a2b),\nbut apparently didn’t consider letting attacker-controlled input wander past the end of an eight-byte buffer into adjacent process memory a security issue.\nSince the regular release schedule for Brotli is “whenever the maintainer has time” it took until October 21, 2026 for a new release to be made.\nAlso weird in the timeline: Node made their security advisory public before the Brotli release and puzzling what the\nconsequences were for the rest of the world was left as an exercise to the broader public.\n\n### The last time\n\nThis wasn’t my first run-in with Brotli’s security “practices”. So I get to feel a bit more stupid than the rest of you. The previous time I ran into this was in November 2025.\n\nBugsink got its regular [dependabot warning](https://github.com/bugsink/bugsink/pull/263) stating that it was running on an\ninsecure version of (Python) Brotli, and that it needed to upgrade to a new version to be secure.\n\nThe problem being fixed: because **brotli compresses *very well*** it’s possible to create “bombs”: small brotli files that expand\n(in the failing scenario typically: in-memory) to something very large and then cause a DOS via memory exhaustion.\nBugsink accepts requests with a `Content-Encoding: br` brotli encoding, and automatically decodes those. Which meant\nthat Bugsink was vulnerable to a trivial **memory exhaustion DOS attack**.\n\nHowever, upon reading the actual upgrade-notes I noticed that **all the new version did was add a new parameter to a method**, but\nthat how this parameter was to be used was left as an excercise to the reader: **there was no documentation** for it, and\nthe only other package that had figured out that something was to be done other than just upgrading,\n[Scrapy](https://github.com/scrapy/scrapy/pull/7134), hadn’t actually figured out how to do that upgrade yet.\n\n(Note: Upon\nresearching this again in 2026 I noticed that this was\n[flagged on the original PR too](https://github.com/google/brotli/pull/1234#issuecomment-3744714019)).\n\nThe lack of documentation bit actual implementers too. `urllib3`\n[implemented the new limit on 5 December 2025](https://github.com/urllib3/urllib3/commit/c19571de34c47de3a766541b041637ba5f716ed7);\n153 days later it\n[had to fix that implementation](https://github.com/urllib3/urllib3/commit/2bdcc44d1e163fb5cc48a8662425e35e15adfe6a) because it had\n[introduced another high-severity decompression-bomb vulnerability](https://github.com/urllib3/urllib3/security/advisories/GHSA-mf9v-mfxr-j63j).\nIn other words: totally expected when you leave people to figure it out for themselves.\n\n#### Last time’s timeline\n\nThe timeline for last year’s drama was also pretty bad: the fix was\n[first committed in public view on Sep 17, 2024](https://github.com/google/brotli/pull/1201/changes/f1bdfaa803e62ce3608e0226c98da1cf20abebdc),\n[merged on January 8, 2025](https://github.com/google/brotli/commit/67d78bc41db1a0d03f2e763497748f2f69946627)\nand the [release notes, committed 9 days later](https://github.com/google/brotli/commit/ad3c0d5f47e3dab8d199e8a8458660dcafa73606),\nsaid:\n\n```\nSECURITY\npython: added Decompressor::can_accept_more_data method and optional\noutput_buffer_limit argument Decompressor::process; that allows mitigation\nof unexpectedly large output; reported by Charles Chan\n```\n\nIt was then left unreleased until October 27, 2025 as version 1.2.0, 283 days after the release notes; the Python packages had to wait another 9 days until release.\n\nIn brief, in days:\n\n- Day 0: [Fix first committed in public view](https://github.com/google/brotli/pull/1201/changes/f1bdfaa803e62ce3608e0226c98da1cf20abebdc)\n- Day 113: [Fix merged](https://github.com/google/brotli/commit/67d78bc41db1a0d03f2e763497748f2f69946627)\n- Day 122: [Release notes committed](https://github.com/google/brotli/commit/ad3c0d5f47e3dab8d199e8a8458660dcafa73606) ,\n  with the literal words`SECURITY [...] mitigation of [...] large output`\n- Day 405: [Tagged release of the C libraries](https://github.com/google/brotli/releases/tag/v1.2.0)\n- Day 414: [Python package released to PyPI](https://pypi.org/project/Brotli/1.2.0/)\n- Day TBD: documentation on how to actually use this\n\n### The next time\n\nI have very little confidence that this will be the last time we’ll have a severe security problem in this package. That’s obviously informed by the above, but also by the current state of the GitHub repository:\n\nHere’s 2 screenshots that should by themselves make the whole case:\n\nTo make the slightly more explicit: that’s 3 out of bounds reads sitting in public view as PRs\n([here](https://github.com/google/brotli/pull/1593), [here](https://github.com/google/brotli/pull/1594) and\n[here](https://github.com/google/brotli/pull/1595)), and a whole bunch of complaints about the release process\n([missing release notes](https://github.com/google/brotli/issues/1591),\n[when will the next release be released?](https://github.com/google/brotli/issues/1540), and a\n[release tracker that is still open](https://github.com/google/brotli/issues/1327)). Also: the maintainer says that\nresources are limited, and releases happen\n[when he can find a slice of time](https://github.com/google/brotli/issues/1540#issuecomment-6361140710).\n\nBecause it’s older (in fact: over a year old) the\n[trivial CPU exhaustion for the .NET implemenation](https://github.com/google/brotli/issues/1339) didn’t make that screenshot.\nFun fact: because Google doesn’t publish this code as an official NuGet package this code is probably not widely\ndeployed but I know it’s\n[somewhat widely in-use by virtue of copy-pasta](https://github.com/search?q=%2Fif%5Cs*%5C%28len%5Cs*%3D%3D%5Cs*-1%5C%29%2F+%22Unexpected+end+of+input%22+path%3ABitReader.cs+language%3AC%23+NOT+repo%3Agoogle%2Fbrotli&type=code).\n\n### So now what?\n\nSo where are we now?  My take on the above is: One of the world’s largest tech giants has been pushing a somewhat-specified new way to do compression with a reference\nimplementation in C. While its support is basically limited to what one guy is able to do in his spare time. In other words:\n**they’re not serious people**, and we should act accordingly.\n\nFor me (Bugsink) the way forward is not entirely clear, but there’s at least some things we can do. Not entirely clear because Bugsink is a Sentry-SDK compatible Error Tracker, and that means I’m aiming at accepting whatever Sentry SDKs send me. And since at least the Python sends Brotli-encoded messages, that means I’ll have to decode them.\n\nStill, I’m [adding a feature to just turn this off](https://github.com/bugsink/bugsink/pull/568) so that at least self-hosters\nthat don’t actually use this sending-side can avoid future RCEs, and I’ve also\n[asked upstream Sentry whether we can maybe just get rid of this](https://github.com/getsentry/sentry-python/issues/8118).\n\nThere’s also the crazy idea of just [vibe-coding a Python wrapper around a presumably more sane Rust implementation of Brotli](https://github.com/bugsink/brotli-rs).\nCrazy idea, and I’m sure not ready to commit *real code* to it, but at least it’s there as an escape hatch now.\n\nFor the rest of the world I’d say: **maybe it’s time to seriously consider whether you actually need to support brotli in\nthe first place**.\n\nIf nobody does, at least I get to say “I told you so”.", "url": "https://wpnews.pro/news/bye-bye-brotli-google-s-compression-library-is-a-security-mess", "canonical_source": "https://www.bugsink.com/blog/bye-bye-brotli/", "published_at": "2026-10-25 11:06:25+00:00", "updated_at": "2026-10-25 11:42:53.552396+00:00", "lang": "en", "topics": ["ai-safety"], "entities": ["Google", "Brotli", "Node.js", "Bugsink", "Scrapy", "urllib3", "HTTP2Shell", "CVE-2026-111497"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/bye-bye-brotli-google-s-compression-library-is-a-security-mess", "markdown": "https://wpnews.pro/news/bye-bye-brotli-google-s-compression-library-is-a-security-mess.md", "text": "https://wpnews.pro/news/bye-bye-brotli-google-s-compression-library-is-a-security-mess.txt", "jsonld": "https://wpnews.pro/news/bye-bye-brotli-google-s-compression-library-is-a-security-mess.jsonld"}}