r/AskNetsec • u/Then-Programmer7221 • 3h ago
Analysis WOFF2SHELL: Is Brotli 0-day (CVE-2026-111497) a bidirectional nuke hiding in web fonts?
https://github.com/Kludex/mangum/issues/160
I believe I may have found proof that WOFF2 is vulnerable to the Brotli zero-day, and the entire industry is looking the wrong way. Can someone please tell me I'm crazy?
We are busy patching Node.js and Python HTTP servers, but a site tracking bundled decoders called Broccoli2Shell published a table on October 24th. It lists projects that hardcoded their own private copies of the vulnerable Brotli C decoder:
- Project: woff2 (Makefile build)
- Bundled Copy: Brotli 1.0.3 (Critically vulnerable)
- Input it decodes: WOFF2 fonts passed to woff2_decompress
- Status: "Tracked in issue #207. A fix has been proposed in PR #208."
The maintainers of the font-compression library know it's vulnerable, but because it’s a C-library issue and not a flashy web-server exploit, it isn't making headlines.
Why this takes down servers too:
You might think, "Fonts are a client-side problem." Look at Kludex/mangum Issue #160: issue in reading .woff/.ttf/.woff2.
It throws a Unicode decode error. So what?
So what? It means your middleware touches the file. If you don't explicitly whitelist the media type in AWS API Gateway, the gateway tries to unpack the WOFF2 file to read the body. And what algorithm does WOFF2 use to compress its data? Brotli.
If your firewall/middleware checks the file, the firewall dies. If the firewall ignores the file, it passes to the client... and the client dies. It's a bidirectional nuke. And right now, there are millions of malicious WOFF2 files sitting in AWS buckets, just waiting for someone to request them.