--- title: "When Google's AI Came for FFmpeg: The Open Source Security Debacle That Actually Changed Things" author: "Cutsio Team" date: "2026-05-14" lastmod: "2026-05-14" category: "Video Technology" excerpt: "Google used AI to find security vulnerabilities in FFmpeg, then went to the media before volunteers could fix them. The resulting firestorm exposed the broken relationship between big tech security practices and volunteer-driven open source — and surprisingly, it led to real change." tags: ["FFmpeg", "Google", "Open Source", "Security", "AI", "Vulnerability Disclosure"] --- ## What happened when Google used AI to find security bugs in FFmpeg? Google deployed AI-powered security scanning against FFmpeg's codebase, generated automated vulnerability reports, went to the media to announce how effective their AI was before the volunteer team could fix the issues, and applied a rigid 90-day disclosure deadline designed for corporate environments — all on a project maintained by a handful of unpaid volunteers. The story starts with good intentions. Google has substantial resources dedicated to improving the security of open source software. Their security researchers are among the best in the world. They scan widely used projects for vulnerabilities, report them responsibly, and help make the internet more secure. In principle, this is exactly what the open source ecosystem needs. But the execution went wrong in several ways that reflect a deeper misunderstanding of how volunteer-driven projects operate. Google used AI to scan FFmpeg's codebase at massive scale. The AI generated detailed, verbose reports for every potential issue it found. The reports were filed through standard vulnerability disclosure channels with the standard 90-day deadline. And Google went to the press to announce how effective their AI was before the patches were ready. The core problem was asymmetry. Google deployed enormous computational resources to find bugs. The FFmpeg team — a small group of volunteers — had to manually triage, understand, and fix each report. The AI did not write patches. It did not offer to help. It just generated more work for people who were already stretched thin. ## Why did the FFmpeg community react so strongly? The FFmpeg community reacted strongly because the AI-generated reports were on an obscure 1990s game codec, marked with maximum severity language, accompanied by media publicity for the researchers, and came with a rigid disclosure clock that treated volunteers like a corporate vendor. The specific vulnerability that sparked the controversy was in a codec used by one video game, on one disc, released in 1993. It was not the kind of vulnerability that posed a systemic risk to the internet. It was the kind of vulnerability that exists in any large codebase that has accumulated decades of code for niche formats. But the security industry's disclosure framework does not distinguish between a critical vulnerability in widely used encryption software and a theoretical integer overflow in a decades-old game codec that almost nobody uses. Everything is marked with alarming language: "high priority," "critical severity," "you will get popped." Kieran Kunhya, who runs the FFmpeg account, described the issue using the analogy of a padlock. "The padlock on your home is there to protect against the capabilities of what it is there to protect. It is not there to protect Fort Knox. The security industry is using AI at a level of scale to go and pick those locks and then say, 'Hey, your lock is not secure. You need to deal with this.'" The security industry's standard language amplifies the problem. Terms like "remote code execution" and "arbitrary memory access" sound terrifying to the general public. To a security engineer, they describe a range of severity from "this could take down a datacenter" to "a carefully crafted file might cause a buffer overflow in a codec nobody uses." The reporting framework does not distinguish, and the AI reports inherite the same alarming tone. ## What is the "crying wolf" problem in security reporting? The "crying wolf" problem refers to the security industry's tendency to mark every vulnerability with the highest severity language, which over time desensitizes developers and users to genuine critical threats while exhausting the volunteers who have to triage the reports. Kieran highlighted this with a specific example from outside the Google incident. A security researcher reported that a filter in FFmpeg could overflow, potentially turning a single pixel the wrong color. This was marked as "high severity, 7.5 out of 10" in red. "At some point, the security industry needs to realize you cannot keep crying wolf like this," he said. "This just leads to people putting password stickers on their PC." The incentives in the security industry drive this behavior. Discoveries with catchy names, dedicated websites, and logos get more attention. Researchers who find high-profile vulnerabilities earn bounties, speaking engagements at conferences like DEF CON, and career advancement. There is no equivalent incentive for the volunteer developer who fixes the issue quietly. Alex Strange, a former FFmpeg developer, posted a widely shared comment on Hacker News during the controversy: "Security people are rampant self-promoters. Imagine you are a humble volunteer open source developer. If a security researcher finds a bug in your code, they are going to make up a cute name for it, start a website with a logo. Google is going to give them a million-dollar bounty. They are going to go to DEF CON and get a prize. Nobody is going to do any of that for you when you fix it." ## How did Google respond to the public backlash? Google responded to the public backlash by changing their approach to FFmpeg vulnerability reporting — they started sending actual patches alongside their reports and introduced reward programs for fixing issues rather than just finding them. The public confrontation was uncomfortable, but it produced results. The asymmetry that volunteers faced began to shift. Instead of dumping reports and expecting unpaid labor to fix them, Google started contributing fixes. The reward structure expanded to cover the fixing side of the equation, not just the discovery side. This outcome validates the strategy that the FFmpeg community has adopted: public accountability works. When trillion-dollar companies are called out for treating volunteer projects as free support, they do change their behavior. The change is not always fast, and it is not always sufficient, but it is real. "Donations have increased substantially," Kieran noted after the controversy settled. "They are still not enough to cover even a single full-time developer, but on both an awareness level and a technical level, there is substantially more technical awareness and awareness of the importance of FFmpeg as a result." ## What does this incident reveal about AI-generated security work? This incident reveals that AI-generated security work creates a fundamental asymmetry problem: AI can find bugs millions of times faster than humans can fix them, and without a corresponding investment in automated patching or financial support for maintainers, AI vulnerability discovery can become a denial-of-service attack on volunteer projects. The scale problem is only going to get worse. As AI-powered code analysis improves, it will find more potential vulnerabilities in more projects. Each report still requires human triage, human understanding, and human fixes. The bottleneck shifts from discovery to remediation, and the volunteer maintainers are the ones holding the bottleneck. The FFmpeg developers described the AI reports as "almost a denial of service by AI-generated bug reports on very niche codecs." The reports were verbose, technically detailed, and completely unhelpful for the fixing process. They required hours of reading to determine whether the reported issue was real, whether it was exploitable, and how to fix it without breaking the codec's functionality. The lesson for the broader open source ecosystem is that AI-powered security scanning needs to include a patching component. If you can automatically find a buffer overflow, you can probably automatically generate a bounds check. If your AI is sophisticated enough to identify a vulnerability pattern, it should be sophisticated enough to suggest or apply the corresponding fix. ## How does this relate to the XZ fiasco and the broader open source funding crisis? The XZ fiasco showed how dependence on unpaid volunteers can create systemic security risks, and the FFmpeg incident is part of a broader pattern where trillion-dollar companies demand urgent support from projects they contribute nothing to. The XZ backdoor was not discovered by corporate security teams or AI scanners. It was discovered by a volunteer who noticed that SSH logins were taking fractionally longer than expected. A single person's intuition prevented what could have been the worst supply chain attack in open source history. But the near-miss exposed the underlying fragility: critical internet infrastructure maintained by overworked, under-supported volunteers. The FFmpeg account's response to the XZ incident was pointed. "The XZ fiasco has shown how a dependence on unpaid volunteers can cause major problems. Trillion-dollar corporations expect free and urgent support from volunteers." The same dynamic plays out across dozens of critical open source projects. OpenSSL, libssh, systemd, curl — these are all projects that the internet depends on, maintained by small teams with inadequate funding. When a vulnerability is found, the world expects a fix immediately. The people writing that fix are often doing it in their spare time. ## What needs to change in the relationship between big tech and open source? The relationship between big tech and open source needs to move from asymmetry to reciprocity — companies that depend on open source projects must contribute proportionally to their usage, either through funding, engineering time, or both. The FFmpeg team is clear about what they need. They need companies that use FFmpeg to fund its development. They need security researchers to send patches, not just reports. They need the publicity and reward systems to recognize the people who fix bugs, not just the people who find them. There are positive signs. Google now sends patches. Microsoft has become more responsive. Donations have increased. But the gap between what open source projects need and what they receive remains enormous. FFmpeg has roughly ten to fifteen core maintainers for code that runs on billions of devices. The math does not add up. The solution is not charity. It is enlightened self-interest. Every company that uses video on the internet depends on FFmpeg. Investing in its maintenance is not a donation — it is an infrastructure cost. Companies that treat it as such will have more secure, more reliable, and more actively maintained software. Companies that do not will eventually face the consequences of neglected maintenance. | Problem | Impact on Volunteers | What Changed After the Backlash | |---|---|---| | AI-generated bug reports | Hours of triage per report | Google started sending patches | | Media publicity before fixes | Pressure from users and press | More coordinated disclosure | | Rigid 90-day deadlines | Impossible for volunteer schedules | More flexible timelines | | No reward for fixing | All incentives go to discovery | Reward programs expanded | | Name-dropping big companies | Assumes project is a vendor | Increased awareness of volunteer nature |

The tools you depend on deserve your support.

FFmpeg powers the video internet, maintained by volunteers who deserve recognition and support. Cutsio shares that philosophy: we build tools that respect your time and your footage. Upload your video, get AI-powered pre-processing with silence removal and transcription, and export clean XML to your NLE.

Try Cutsio Free

No credit card required. 60 minutes of free processing.

## FAQ **Did Google intentionally harm FFmpeg with its AI security scanning?** No, Google's intentions were positive — they wanted to improve open source security. The harm came from a mismatch between corporate security practices and volunteer-driven development timelines, not from malicious intent. **Did the FFmpeg community's public response work?** Yes, the public response led to concrete changes. Google started sending patches with vulnerability reports and expanded reward programs to include fixing bugs, not just finding them. **What is the 90-day disclosure deadline?** The 90-day deadline is a standard practice in the security industry where researchers publicly disclose a vulnerability 90 days after reporting it, regardless of whether a fix has been developed. This deadline is designed for corporate environments with dedicated security teams, not volunteer projects. **Is AI-powered vulnerability discovery always bad for open source?** Not necessarily. AI discovery is valuable when paired with AI-generated patches or when the discovering organization also contributes engineering time to fix the issues. The problem is asymmetry, not automation. **How can companies properly support open source projects they depend on?** Companies can support open source through direct funding, assigning engineering time to fix bugs and add features, sponsoring conferences and development events, and establishing Open Source Program Offices that understand how to engage constructively with volunteer communities.