Twenty One Zero-Days in FFmpeg

Perceived Severity of the FFmpeg Bugs

• Many consider the RTSP/RTP issues serious because they can hit ingest pipelines, surveillance/CCTV systems, and transcoding services that accept attacker-controlled URLs.
• Others note real exploitation likely requires chaining with ASLR leaks or other bugs, but media stacks are known to leak addresses easily.
• Some argue many of the 21 issues are niche, require bad deployment practices, or are just one step in a larger exploit chain.

FFmpeg’s Security Track Record and Attitudes

• Commenters say FFmpeg has long had an “inexhaustible” supply of memory corruption bugs found via fuzzing and is not safe to run on untrusted input unsandboxed.
• FFmpeg is described as hostile or dismissive toward security reports; some see this as understandable burnout, others as irresponsible.
• There’s disagreement on how “big a deal” obscure codec bugs are; some dev perspectives downplay them, others stress that attackers can choose any supported codec.

Sandboxing, Deployment, and Real-World Risk

• Browsers reportedly run FFmpeg-like components in separate sandboxed processes with allocator hardening; still, a chained sandbox escape remains a threat.
• Recommended mitigations: containers, firejail/bubblewrap, gVisor, VMs, or Qubes-style per-app VMs, though hardware acceleration and GPUs complicate sandboxing.
• Some accept TVs/embedded devices as effectively unsandboxed and suggest isolating them at the network level.

Alternatives and Rewrites (Rust, GStreamer, etc.)

• GStreamer is discussed as a pluggable media graph system; it can wrap FFmpeg but also has its own codecs and elements.
• Several call for “rewrite it in Rust,” but others argue:
  • FFmpeg’s hot paths and assembly would still require unsafe and wouldn’t automatically fix logic bugs.
  • A straight port could recreate the same vulnerabilities in a new language.

Zero-Day Terminology Debate

• Multiple comments say the article misuses “zero-day”; historically it means exploited before or at disclosure, not just “serious bug.”
• There’s discussion distinguishing vulnerabilities vs exploits and how the term’s meaning has drifted.

Security Research, LLMs, and Incentives

• Strong criticism of “clout-chasing” researchers and low-quality, LLM-generated reports that swamp maintainers.
• Others counter that vulnerabilities exist regardless of researcher behavior.
• Some argue tools should go beyond reports and submit high-quality PRs; claimed success rates are high where this is done.
• A few worry advanced LLM-based tools could quietly find and hoard powerful exploits.