FFmpeg dealing with a security researcher

trollied | 104 points

I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.

vqtska | 2 days ago

"Just send patches" is I think the main point. Rather than just reporting security bugs these big organisations ought to start seeing the point of open source being that can and should be contributing if they value the project and need this fixed because its a pretty obscure problem generated by AI.

PaulKeeble | 2 days ago

I'm confused, on the bug report it is claimed ffmpeg fixed the issue, so presumably it was a valid issue. So what's the problem here? That it was a mere memory corruption bug and not an exploitable issue? Even still it seems reasonable that google reports bugs even if they aren't security issues and it seems reasonable to err on the side of memory cirruption being security relavent.

Edit: i guess its not even that, they are just bitter that they have to fix bugs in their own code??? Recieving vuln reports is a gift. If ffmpeg doesnt like it maybe google should just start practising full disclosure.

bawolff | 2 days ago

It looks like the FFmpeg account on X is calling out Google for using AI to mass-report CVEs in obscure volunteer maintained codecs, then expecting unpaid maintainers to rush fixes. Large, profitable firms rely on FFmpeg everywhere, but don’t seem to be contributing much to the project.

cebert | 2 days ago

Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/

mappu | 2 days ago

FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1].

On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain.

On the other hand, we have plenty of evidence that untrusted input validation bugs pose a very high risk to end users. So, for as long as this is their policy, FFmpeg code really should not be included in any system where security is at all important. Perhaps we need a "fundamentally unsafe for use" sticker for OSS projects taking this stance?

[1] https://x.com/FFmpeg/status/1984425167070630289

gnfargbl | 2 days ago

Not sure why the Twitter account is complaining about this now. Maybe it's part of a bigger sequence of issues? This particular one was resolved pretty quickly, back in August.

The Google bug report is dated August 21: https://issuetracker.google.com/issues/440183164

There are FFmpeg commits apparently fixing the sanm codec problem within a day or so: https://github.com/FFmpeg/FFmpeg/commits/140fd653aed8cad774f...

Earlier, on August 20, there are FFmpeg fixes for other issues in the same codec apparently also found by Google (by fuzzing not AI?): https://github.com/FFmpeg/FFmpeg/commit/5f8cb575e83a05bc95b8..., https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6c...

mkl | 2 days ago

Those who do not learn from Stagefright are doomed to repeat it.

https://en.wikipedia.org/wiki/Stagefright_(bug)

GeekyBear | 2 days ago

Why didn’t one of the ffmpeg developers that Google employs fix the bug?

I assume Google has several full time ffmpeg developers given how much they rely on it.

hdgvhicv | 2 days ago

Rather unprofessional for an official project twitter account to complain about "slop"

> We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix.

Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just because it isn't likely to be exploited doesn't mean it isn't there. While it'd be nice if Google contributed, if I had to choose between Google doing this and doing nothing, I'd choose this.

> Is it really the job of a volunteer working on hobby 1990s codec to care about Google's security issues? Or anyone's?

It isn't "Google's security issues", it's a FFmpeg security issue. The tone from this account is incredibly childish.

This exchange was what shocked me the most:

Person 1:

> If someone sends me cutekitten.mp4, but it is actually not an mp4 file, but a smush file using an obscure 1990s hobby codec, could the bug be exploited if I just run ffplay cutekitten.mp4?

FFmpeg:

> Is it the job of volunteers working on game codecs in their free time as a hobby to fix Google's AI generated bug reports?

Completely dodging the question.

GaryBluto | 2 days ago

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...

TheChaplain | 2 days ago

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.

tonetegeatinst | 2 days ago
[deleted]
| a day ago

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.

Ekaros | a day ago

[flagged]

anon_oss | 2 days ago