FFMPEG takes a Big Sleep

A flashpoint in open-source security erupted after Google reported a vulnerability in FFmpeg through an AI-driven process—then demanded a 90-day private disclosure window before the details would go public. The core dispute wasn’t whether the bug existed, but how the disclosure was handled: FFmpeg maintainers and supporters argued that a company with massive compute should not be able to “hold volunteer maintainers at gunpoint,” effectively forcing them to patch without providing immediate fixes while also controlling when the vulnerability becomes public.

The conversation centered on how disclosure timelines work in practice. Bug disclosure is meant to balance two risks: publishing too early can alert attackers before defenders have a chance to mitigate, while waiting can reduce exposure but delays public awareness. In this case, the reported issue was a use-after-free bug—where memory is freed but a dangling pointer is still used. One participant noted that a simple mitigation like nulling the pointer after free could address the specific flaw, raising the sharper question: why didn’t Google also provide a patch or mitigation when it had the resources to find the problem?

The debate broadened into the ethics and mechanics of AI-assisted vulnerability hunting. Google’s OSS-Fuzz approach fuzzes open-source projects by injecting malformed or “bad” inputs to trigger crashes and bugs, and the newer push adds LLM-based analysis to find more complex issues that fuzzing alone may miss. That combination can produce high-quality, reproducible reports—but it also creates a scale problem for small teams. If maintainers receive a flood of AI-generated vulnerability reports (potentially with uncertain exploitability), they still must triage, assess real-world impact, and implement fixes—work that competes with everything else.

Several participants argued that the “90-day” model can be counterproductive when the vulnerability is niche or hard to trigger. The reported FFmpeg flaw sat inside a codec associated with a LucasArts game from 1995 and wasn’t enabled by default; it required explicit configuration. That meant the practical attack surface might be tiny, yet the public disclosure still risks giving attackers a roadmap. In other words, publishing can both inform defenders and simultaneously remove the “unknown” that makes vulnerability research harder.

Others pushed back on the idea that disclosure is primarily about credit. Disclosure is framed as a way to inform defenders that a bug exists and may be exploitable, not as a resume-building exercise—though the AI nature of the reporting complicates the usual human incentives. Still, maintainers’ frustration remained: there’s no contractual obligation or maintenance fee tied to the reports, and the burden of triage and patching falls on volunteers.

By the end, the discussion landed on a larger question with no clean answer: how should large organizations contribute to open-source security when they can find vulnerabilities at scale, but mitigation capacity and prioritization remain limited on the receiving end? The thread also highlighted a practical reality—triage isn’t free, and even when fixes are straightforward, maintainers can’t absorb unlimited incoming reports without slowing down the project’s core work.