[{"cid":60344,"parent_cid":null,"body":"21 Zero-Days in FFmpeg\r\n\r\nhttps://depthfirst.com/research/21-zero-days-in-ffmpeg\r\n\r\nLobsters: https://lobste.rs/s/ejra5c/21_zero_days_ffmpeg","created_at":"2026-06-13T01:25:11.452Z","tags":["security","bot"],"orgs":[],"usrs":[],"created_by":"bot_lobsters","thumb":"https://depthfirst.com/uploads/21%20zero%20days%20in%20FFmpeg.png","c_comments":1,"c_reactions":"","c_flags":0,"links":[],"flaggers":[],"author_ups":52,"author_downs":4,"author_posts_count":4096,"tag_ups":446,"tag_downs":77,"domain_ups":52,"domain_downs":4,"score":"2026-06-10T20:05:49.541Z","repost_ups":0,"mentions":[],"domains":["depthfirst.com","lobste.rs"],"comments":"1","reaction_count":"0","reaction_counts":{},"user_reactions":[],"child_comments":[{"cid":60345,"body":"> # [21 Zero-Days in FFmpeg | depthfirst](https://depthfirst.com/research/21-zero-days-in-ffmpeg)\r\n>\r\n> TLDR: depthfirst’s production autonomous security agent discovered 21 zero-day vulnerabilities in FFmpeg, after intensive security analysis by Google and Anthropic. Moving beyond theoretical analysis, our agent produces concrete, reproducible PoC inputs to confirm its findings at a fraction of the costs ($1k vs. $10k). Several of the findings had been sitting latent for 15 to 20 years. We explored the exploitability of the issues and developed a PoC demonstrating a RCE exploit primitive.\r\n>\r\n> FFmpeg is one of the most widely deployed pieces of software in the world. From the browsers we use daily to the infrastructure powering the large streaming platforms, it quietly processes media everywhere. As a library that routinely parses complex, untrusted media, it is inherently security critical and a prime target for zero-click attacks.\r\n>\r\n> Looking deeper into FFmpeg’s repository reveals the true scale of the challenge: it is massive, comprising roughly 1.5 million lines of heavily optimized C code dedicated to parsing hundreds of complex media formats. Furthermore, it has absorbed over two decades of relentless fuzzing and manual audits. Recently, Google’s Big Sleep team disclosed 13 vulnerabilities in FFmpeg. Soon after, Anthropic used their Mythos model to scan FFmpeg and successfully discovered some security issues. These milestones demonstrated that advanced models are increasingly capable of reasoning through dense, hardened C code.\r\n>\r\n> With these recent efforts, finding vulnerabilities in FFmpeg is getting much harder. At depthfirst, we built an agentic system that can do deep scans over large codebases. Finding bugs here is a measure of our security system’s capability. While we don’t have access to Mythos, we wanted to know how far we can go just using the models that are available to us. Can we re-discover what Big Sleep and Mythos have found? And more importantly, can we find any new critical bugs that they completely missed?\r\n>\r\n> ## Depthfirst’s Security Agent\r\n>\r\n> A coding agent and a security agent may use the same underlying models, but they operate with very different objectives. A coding agent is usually interactive: a human gives it a task, and the goal is to write code, rather than focusing on edge cases and adversarial inputs. A security agent has a narrower and more targeted goal. It is not trying to write useful application code, but trying to find real, exploitable security issues in an existing system without specific instructions.\r\n>\r\n> That changes the shape of the agent. A security agent has to begin by threat modeling the codebase: understanding its architecture, identifying exposed parsers and protocol handlers, and mapping where attacker-controlled input can enter the system. From there, it audits the attack surface code directly, following data flow through the relevant components instead of treating the repository as a flat collection of files. In addition, a practical security agent needs guardrails that prevent it from fabricating missing conditions, over-claiming theoretical bugs, or flooding with false positives. It must check whether the attacker actually controls the right input, whether the vulnerable path is reachable, and whether the suspected flaw can be reproduced. When needed, it should identify or generate appropriate harnesses to interact with the target components and test those hypotheses concretely.\r\n>\r\n> …","orgs":[],"tags":["security","bot"],"usrs":[],"c_flags":0,"comments":0,"created_at":"2026-06-13T01:25:15.236811+00:00","created_by":"bot_reader","parent_cid":60344,"child_comments":[],"user_reactions":[],"reaction_counts":{}}]}]