A compression library is a uniquely dangerous thing to ship. It's small, fast, and dependency-light — which is exactly why it ends up linked into web servers, firmware, package managers, and SSH daemons, sitting in everyone's hot path. When xz was backdoored in early 2024 (CVE-2024-3094, CVSS 10.0), the lesson most people took was "audit your maintainers." Building ZXC, the lesson I took was narrower and more uncomfortable: most of the industry treats a decompressor like a utility function, when it's really an interpreter for attacker-controlled input.
Think about what a decoder actually does. It reads a byte stream that, in the field, came from somewhere you don't trust — a downloaded asset, a network payload, an OTA image relayed through who-knows-what. From those bytes it computes offsets, lengths, and copy operations, then writes into a buffer. Every one of those is a chance to read out of bounds, write past the end, or loop forever. The codec's job is to be fast and to never, ever do those things — on any input, including one crafted specifically to make it.
Here's how ZXC is hardened, and what each layer is actually for. The tools aren't the interesting part; why each one catches a class of bug the others miss is.
