why SSGs? Broccoli2Shell is why
post details
published:
260 wordsanother day, another diss track released by the Vulnerability Apocalypse[^1].
the technicalities around CVE-2026-111497 go way over my head—if Google’s reference C implementation of the Brotli decompression library makes perfect sense to you, then you're probably not here on my site, reading this 🙃
what’s relevant here’s why serving a site as static files—built by static site generators (SSGs)—removes one route for yucky attacks like this[^2]
TL;DR an SSG builds your pages before anyone visits. your hosting serves the finished files instead of running your site’s application code to assemble a page whenever someone requests it.
this vulnerability needs a particular piece of software to decompress malicious data. so if there’s no site application doing that when visitors send requests, there’s nothing at that layer for this exploit to target 🔐
fewer moving parts, fewer things to exploit, less tech drama, happy life[^3]. SSGs for the win! 👇
- HTML + CSS + JavaScript + images sit ready to serve in the Great Big File Cloud in the Sky 🌐💨
- a purely static site needs no application database / runtime secrets on the serving side, so there's less backend baggage to compromise
naturally, build tools + hosting infra still need patching, and compromised hosting could still alter what visitors receive. static files aren’t a force field, though by comparison it sure feels like it! 🦸♀️
[^1]: The Patch Apocalypse: Why Traditional Vulnerability Management is Breaking Under AI‑Driven Discovery
[^2]: or on a peripherally related note, [[why I built my website with two static site generators]]
[^3]: SSGs are the key to happiness, right?