FFmpeg to Google: Fund us or stop sending bugs

The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it.

Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.

Notably, the vulnerability is also in a part which isn't included by default and nobody uses. I'm not sure that even warrants a CVE? A simple bug report would have probably been fine. If they think this is really a CVE, a bug fix commit would have been warranted.

AIUI there's no such thing as "really a CVE". A CVE is merely a standardized identifier for a bug so you can call it "CVE-2025-XXXXX" rather than "that use-after-free Google found in ffmpeg with AI." It doesn't imply anything else about the bug, except that it may impact security. The Linux kernel assigns one to every bugfix that may impact security (which is most kernel bugs) to avoid controversy about whether they should be assigned.

It is included by default

It is included in most builds of ffmpeg, for example in most Linux packages or in Windows build linked to on ffmpeg.org that I use. But yeah, it's a very niche format that nobody uses.

Yes - more than a sour taste. This is hideous behavior. It is the polar opposite of everything intelligent engineers have understood regarding free-and-open software for decades.

Use After Free takes 3 seconds to fix if you defer free until the end of the program. If you have to do something else, or you don't want to leak memory, then it probably takes longer than 3 seconds.

Probably the right solution is to disable this codec. You should have to make a choice to compile with it; although if you're running ffmpeg in a context where security matters, you really should be hand picking the enabled codecs anyway.

One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue.

That's the difference between "it may or may not be that there's someone who cares" versus "no one should be running this software anywhere in the general vicinity of untrusted inputs".

You’re right about scoring, at least largely. Let’s not conflate the CVE system and the CVSS system, though. They are related but distinct. CVE is just an identifier system.

> One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue.

+100000

My favorite 8.x or higher CVEs are the ones where you would have to take untrusted user input, bypass all the standard ways to ingest and handle that type of data, and pass it into some internal function of a library. And then the end result is that a regex call becomes more expensive.

If it takes 3 seconds to fix it, then how is this some massive burden on the maintainers? The bug report pointed to the relevant lines, the maintainers are the most familiar with the code and it probably would have taken them 1.5 seconds to not only fix it, but validate the fix. It probably took more time to write up the complaint about the bugs than to implement the fix.

Not only is it included by default, but you can trigger this with a file that looks like a mp4 to the user.

It takes more time to read and understand the bug report, than to fix it. Instead of using googles time, they used ffmpegs voluntary time.

If this happens another 1000 times (easily possible with AI) google just got free labour and free publicity for "discovering 1000 critical bugs (but not fixing them even so they were easy to do)"

I’m not on the beck and call of Google’s robot.

Maybe if it was an actual engineer from Google doing this they would have gotten a better response. Don’t expect people to treat AIs the same way we treat people.

But if you send me an automated report and then tell me to jump I’m telling you to f*ck off.

If you think that's bad, you should look at Linux kernel CVEs. They're basically gone rogue when it comes to CVEs. Every minor bug gets flagged as a CVE, regardless of impact. Often, exploitation requires root access. If you have root, you've already won and can do whatever the hell you want. No need to exploit a bug to cause problems.

The report had a bunch of human effort in it, and didn't tell ffmpeg to do anything at all.

What happens if I send you an automated report that tells you of a meaningful problem you didn't know about, and don't tell you to jump?

It takes even more time to read and understand a patch. Not only to you have to do all of the work of reading and understanding the bug report for which the patch is relevant, but you now also have to read and understand the submitted code, which until just this moment you didn't even know was necessary and have no specific context for. Then you have to validate whether or not the code in the patch is sufficient to fix the issue or whether those changes have any additional knock on effects. Yes, you could hope that the Google coders did this, but since you already have such a low opinion of Google's efforts and behavior on this front, I would argue that trusting their submission without validation would be insane.

Then if there's any changes or additional work to be done, you now have to spend time communicating with the patch sumbmitter, either getting them to make the requested changes, or rejecting their patch outright and writing it on your own.

And after all that we'd be right back here, only instead of the complain being "we don't have enough time to review all your bug reports" it would be "we don't have enough time to review all your PRs"