FFmpeg dealing with a security researcher

Posted by trollied 11/1/2025

FFmpeg dealing with a security researcher(twitter.com)

107 points | 165 commentspage 2

TheChaplain 11/1/2025|

The comments from the public.. Just wow we are doomed..

To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group.

Then people start berating them without even knowing the full story...

lukeschlather 11/1/2025||

Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.

vreg 11/1/2025|||

If that is true then Google should be strictly sandboxing ffmpeg and filtering the input before it even gets there. A solid defense-in-depth approach would make sure it's highly unlikely this vulnerable code would be reached, and if it was, there would be effectively no impact.

They should be building ffmpeg with a minimal feature set anyway, so none of these obscure codecs end up included in the final binary.

tkfoss 11/1/2025||||

Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?

yegle 11/2/2025||

Please stop spreading this misinformation. At least in Debian this is enabled by default (and as another post indicates, Ubuntu as well).

Run the following command to confirm:

ffmpeg -codecs|grep sanm

tkfoss 11/13/2025|||

You re right, thanks!

astrange 11/3/2025|||

If you're using ffmpeg it's recommended to just enable the things you need, or only accept some container formats. But yes, in a generic package everything is enabled.

chris_wot 11/1/2025|||

Then they can certainly afford to supply patches.

haskellshill 11/1/2025|||

>rarely anyone ever uses

It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

defrost 11/1/2025||

If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs.

In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.

Ukv 11/1/2025|||

To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).

GaryBluto 11/2/2025||

Yeah but who cares about them, right? It's a volunteer project don't you know.

haskellshill 11/2/2025|||

Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?

defrost 11/2/2025|||

> Right, they probably already mitigated this bug in their own usage.

Indeed. A step so obvious it renders comments such as this:

  It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

moot.

> Which is exactly why reporting the bug is a FAVOR to ffmpeg.

Not sure you have to SHOUT the obvious.

> Would you rather they just quietly fix it on their own and not report it to the maintainers?

What do you suppose the answer to that question to be?

Rebelgecko 11/3/2025||

There's this weird "damned if you do, damned if you don't" situation on social media where people try to help and get reamed for not doing enough. Taylor Swift donated $500k to charity and people complaining she didn't round up to a million. After all, she can afford it.

But she ends up getting more criticism than the billionaire who donates nothing. Seems unfair but I guess it's human nature.

array_key_first 11/2/2025|||

I would rather they fix it and submit a patch like normal fucking people.

cebert 11/1/2025||

I could see a compromise where if there are obscure codecs that may not be as secure, FFmpeg would present a warning before loading the file. This way, the user would have the option to decide whether to load the file or not. By default, potentially malicious files would not be loaded, which could prevent them from being used as part of an exploit. This seems like a reasonable compromise.

kvemkon 11/1/2025||

> FFmpeg would present a warning

Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.

tonetegeatinst 11/1/2025||

This seems very weird to me as someone who has been watching vulnerability reports for over 8+ years.

Normally if a bug is found in a open source project, then its common courtesy to propose a patch to fix it. Hell when you do red team security research on a codebase your supposed to identify the root cause in code or human behavior and propose a fix/patch if you have access to the code.

throwaway2046 11/2/2025||

https://xcancel.com/ffmpeg/status/1984207514389586050

roarinelk 11/7/2025||

The buggy code in question was never in a release -- it just existed in the ffmpeg git repo: 7.1.2 does not have it at all, and it was fixed before the 8.0 release. Why does it even have a CVE?

Ekaros 11/2/2025||

If FFmpeg with current developer resources is not good or secure enough for their use case. They should implement their own code that is. I feel that is most reasonable approach for anybody using it.

anon_oss 11/1/2025|

[flagged]

socalgal2 11/1/2025||

Because not disclosing an actual bug that could affect users would somehow be good?

anon_oss 11/2/2025||

Sorry, I just needed to vent. I see now that Google's AI bug report isn't as bad as I'd assumed.

They should have included a patch though and they should have contacted ffmpeg team first before spamming them with dozens of issues all at once.

jsnell 11/2/2025|||

So, this is the report they complained about: https://issuetracker.google.com/issues/440183164

I don't know how a vulnerability report could be much better than that. It is a real vulnerability. The report includes a detailed analysis of where the vulnerability is. The bug has been validated, and the report includes exact reproduction instructions.

How is that a bullshit bug report?

anon_oss 11/2/2025||

Fair enough, I hadn't seen the bug report and assumed it was the usual AI slop.

galaxy_gas 11/1/2025||

The one nice thing is Google had submit a real bug at least.

The human idiot "researchers" will send paragraph long automatically generated extortion threats over not sending HSTS header