Twenty One Zero-Days in FFmpeg

The strongest reaction was not shock at FFmpeg specifically. People familiar with the codebase said this is exactly the kind of software that keeps yielding bugs under fuzzing because it is huge, performance-driven C and assembly that implements a long tail of ugly, underspecified, and obscure formats. The practical consensus was blunt. FFmpeg should be treated like a dangerous parser, not a trusted library. If you feed it user uploads, remote streams, or arbitrary files, run it inside a sandbox, container, VM, gVisor, WASM wrapper, or separate locked-down process. Several comments noted that browsers already do this, and security-conscious services often ship custom FFmpeg builds with only the codecs they actually need. A lot of energy went into correcting the marketing. Multiple commenters said these are not "zero-days" unless they are already being exploited in the wild before disclosure. They also questioned how serious the full set really is, since some issues depend on obscure codecs, niche containers, or exploit chains that still need an address leak or sandbox escape. That did not change the main conclusion. Niche codec bugs still matter if your build enables them and an attacker can choose the input format. The more useful framing is that AI is making vulnerability discovery and duplicate reporting much cheaper, while maintainers still have to triage, patch, and support complex software with limited time. That gap, more than the exact count of bugs in this post, is what people expect to get worse.