Live data from Hacker News

FFmpeg dealing with a security researcher

twitter.com

71–80 of 174 posts

Re: FFmpeg dealing with a security researcher

#71

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

I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.

The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.

Re: FFmpeg dealing with a security researcher

#72
post #26

Earlier quoted context omitted.

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.

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

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

Re: FFmpeg dealing with a security researcher

#73

Earlier quoted context omitted.

I checked with Ubuntu's ffmpeg and it is enabled by default. There are a huge list of codecs enabled by default (maybe all of them?). Given the security track record of codecs implemented in C, this means it's basically guaranteed that there are dozens of security vulnerabilities in ffmpeg. I think the same is probably true for VLC to a lesser extent, which is pretty wild considering I've never heard of it being used…

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

VLC and ffmpeg share the same underlying library family (libav*) where this vulnerability lives.

> I doubt it'd be worth one's time to write exploits for desktop Linux

How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.

Re: FFmpeg dealing with a security researcher

#74
post #71

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

I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure. The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.

It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.

Re: FFmpeg dealing with a security researcher

#75
post #71

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

I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure. The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.

Nah, it's entitlement to expect maintainers to overwork and fix every single "security" issue thrown their way. ffmpeg has just a few resources and Google has way, way more. The maintainers are not your servants nor are they Google's servants.

Re: FFmpeg dealing with a security researcher

#76
post #70

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, t…

Here's a better summary: ffmpeg is getting DDOS'd by AI generated security CVEs. Those CVEs currently have zero real-world impact; the "researchers" didn't even bother to write a patch/fix for their reports.

My hot-take: it's security theater drama. Burn-out maintainers on one side and wealthy corporate employees on the other.

Re: FFmpeg dealing with a security researcher

#77

Earlier quoted context omitted.

I checked with Ubuntu's ffmpeg and it is enabled by default. There are a huge list of codecs enabled by default (maybe all of them?). Given the security track record of codecs implemented in C, this means it's basically guaranteed that there are dozens of security vulnerabilities in ffmpeg. I think the same is probably true for VLC to a lesser extent, which is pretty wild considering I've never heard of it being used…

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

  > VLC is pretty popular on windows, but ffmpeg?
I'm pretty confident VLC uses libavcodec

  > Is there any commonly used windows app that relies on it?
A lot of stuff uses libavcodec

Re: FFmpeg dealing with a security researcher

#78
post #71

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

I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure. The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.

>I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.

Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.

If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.

Re: FFmpeg dealing with a security researcher

#79
post #73

Earlier quoted context omitted.

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

VLC and ffmpeg share the same underlying library family (libav*) where this vulnerability lives. > I doubt it'd be worth one's time to write exploits for desktop Linux How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.

FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?

Re: FFmpeg dealing with a security researcher

#80
post #16

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

I'm not sure if Kostya's account is truthful. He has a huge axe to grind against ffmpeg https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

IIRC, his "LibAV" fork was malicious and his people lied a lot to the community ("ffmpeg is now deprecated!"). Ultimately, they failed, but I see a lot of their rhetoric and resentment in Kostya's post today.

Post reply on HN