16 ms·

FFmpeg dealing with a security researcher

107 points by trollied 11mo ago

cebert 11mo 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.
- TZubiri 11mo ago
  You think google uses ffmpeg for youtube?
  - joatmon-snoo 11mo ago
    They do.
    - defrost 11mo ago
      Full build with all the codecs, or a custom build with a limited vetted set?
      - Telaneo 11mo ago
        Does it matter? Like, I don't expect Google to deliver patches for FFmpeg beyond bug fixes or features that directly benefit them, but that's the least you can expect.
        defrost 11mo ago
        It matters to Google if they process public submitted videos using FFmpeg codecs that can be exploited. One would expect Google to only use FFmpeg with vetted codecs and to either reject videos with codecs that have untrusted FFmpeg modules or to sandbox any such processing, both for increased safety and perhaps to occassionally find new malware "in the wild".
  - Telaneo 11mo ago
    They did once upon a time atleast.[1] Most videos probably go through dedicated hardware nowadays, but it wouldn't surprise me if some videos still have to go the FFmpeg route that catches all the videos that the dedicated hardware can't handle. [1] https://web.archive.org/web/20110315155125/https://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/ https://web.archive.org/web/20110315155125/https://multimedi...
- joatmon-snoo 11mo ago
  No, this is the unfortunate reality of “ffmpeg is maintained by volunteers” and “CVE discovered on specific untrusted input”. Google’s AI system is no different than the oss-fuzz project of yesteryear: it ensures that the underlying bug is concretely reproducible before filing the bug. The 90-day disclosure window is standard disclosure policy and applies equally to hobby projects and Google Chrome.
  - haskellshill 11mo ago
    Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?
    - hdgvhicv 11mo ago
      “This is broken, here’s how I fixed it” Vs “this is broken, you gave 90 days to fix it” If you can’t see the difference you’re the existential threat to Free software that stems from the trillion dollar industries that just take.
      - haskellshill 11mo ago
        > you have 90 days to fix it Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here. If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.
- socalgal2 11mo ago
  A quick search of the ffmpeg commit history shows google has made plenty of contributions to ffmpeg. They may or may not provide a patch for this CVE but reporting it is the first step so people can then decide what action to take (like don't compile that codec in for example)
- blueg3 11mo ago
  I don't think Google is expecting anything here. They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe. The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse. It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it. The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.
TheChaplain 11mo 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...
- cebert 11mo ago
  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 11mo ago
    > FFmpeg would present a warning Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.
- lukeschlather 11mo ago
  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 11mo ago
    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.
PaulKeeble 11mo 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.
- _flux 11mo ago
  Perhaps it'll be sooner than you expect: actually having proper fixes made by AI for the issues found with AI.
- Telaneo 11mo ago
  I can't help but be reminded about the time that an MS employee put in a ticket on FFmpeg's bug tracker and said it was 'High priority'.[1][2] On the one hand, this one Microsoft employee was probably in a bind and actually blocked by this bug. On some level, it's hard to blame them as an individual. On the other hand, Microsoft has no leverage here and pays somewhere between a pittance and nothing for FFmpeg, while getting enormous use out of it. If they regularly donated with either money or patches, then there'd be no beef, but it's the expectation of getting something more for free while already getting so damn much for for zero cents that really grinds both mine and FFmpeg's gears. That reminds me that I should probably throw some money at FFmpeg, if only to clear my conscience. [1] https://xcancel.com/FFmpeg/status/1775178805704888726 https://xcancel.com/FFmpeg/status/1775178805704888726 [2] https://news.ycombinator.com/item?id=39912916 https://news.ycombinator.com/item?id=39912916
- bawolff 11mo ago
  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.
  - thatguysaguy 11mo ago
    It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.
anon_oss 11mo ago
[flagged]
- socalgal2 11mo ago
  Because not disclosing an actual bug that could affect users would somehow be good?
  - anon_oss 11mo ago
    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.
- galaxy_gas 11mo ago
  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
- jsnell 11mo ago
  So, this is the report they complained about: https://issuetracker.google.com/issues/440183164 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 11mo ago
    Fair enough, I hadn't seen the bug report and assumed it was the usual AI slop.
vqtska 11mo ago
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.
- chemotaxis 11mo ago
  The somewhat depressing reality is that if you're running ffmpeg on user-supplied multimedia without putting it in a bulletproof sandbox, you're just bound to have a bad time. Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step you need to take. Maybe it's on the ffmpeg project that they don't steer people in that direction. Trying to fix these bugs piecemeal is somewhat pointless - or at least, we've been trying for several decades, throwing a ton of manpower and compute at it, and we're still nowhere near a point where you could say "this is safe".
  - ozgrakkurt 11mo ago
    Does this mean we have to run vlc in a sandbox while watching a downloaded film?
    - awakeasleep 11mo ago
      In production? With a user-supplied film? You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)
- ls612 11mo ago
  It isn't even like this is without precedent, the FORCEDENTRY NSO kit used the shitty old JBIG2 parser that Apple was shipping as its entry point despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.
GaryBluto 11mo 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.
- fabrice_d 11mo ago
  It is absolutely Google's security issue if they use an open source project with that license: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING.LGPLv2.1#l435 https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING.... and then expect volunteers to provide them fixes.
  - GaryBluto 11mo ago
    It's not just Google who could be affected by this. > and then expect volunteers to provide them fixes. Expect volunteers to provide everyone using the software with fixes.
    - sillywabbit 11mo ago
      For a bug in the LucasArts Smush codec? Why didn't you verify it was an mp4/h264 first?
mappu 11mo ago
Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/ https://codecs.multimedia.cx/2025/11/ffpropaganda/
- vreg 11mo ago
  He sounds bitter.
- pityJuke 11mo ago
  it’s very… sad, i guess, watching a lot of software engineering discourse on social media (at least, what I see from Twitter) just become this attention grabbing shitposting. ffmpeg is very much a big player in this field, and it has paid off handsomely - those tweets are often popular on site, and shared across other social media.
  - Ygg2 11mo ago
    > paid off handsomely Paid off how? Did they get more funding? More contributors?
    - cratermoon 11mo ago
      "exposure"
- casey2 11mo ago
  Wow these people have a lot of free time... shouldn't they be programming?
- secondcoming 11mo ago
  The most interesting part of that is the admission that they used decompilers to reverse engineer the codecs. I wonder if makign that output freely available is legal.
  - ronsor 11mo ago
GeekyBear 11mo ago
Those who do not learn from Stagefright are doomed to repeat it. https://en.wikipedia.org/wiki/Stagefright_(bug) https://en.wikipedia.org/wiki/Stagefright_(bug)
gnfargbl 11mo 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 https://x.com/FFmpeg/status/1984425167070630289
- vreg 11mo ago
  All code should be considered potentially vulnerable, that's why we have so many layers of exploit mitigation from the compiler to the runtime environment to the overall design of the system the code is running in.
- TZubiri 11mo ago
  > unless you pay them You can't pay for the software >"FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment" https://www.ffmpeg.org/legal.html https://www.ffmpeg.org/legal.html
  - deleted 11mo ago
    [deleted]
  - gnfargbl 11mo ago
    I edited my post to make the nature of the requested payment clearer.
tonetegeatinst 11mo 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.
mkl 11mo 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 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/140fd653aed8cad774f991ba083e2d01e86420c7/ 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/5f8cb575e83a05bc95b82d7f5f572d8f554f3705 https://github.com/FFmpeg/FFmpeg/commit/5f8cb575e83a05bc95b8..., https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6ce8482f3065e4c36c3f97 https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6c...
bawolff 11mo 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.
- hitekker 11mo ago
  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.
  - x0x0 11mo ago
    Even if they have real-world impact: ffmpeg is a volunteer project. With (ffmpeg -codecs | wc -l) 519 codecs. This will trivially exhaust available ffmpeg eng resources.
    - haskellshill 11mo ago
      There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?
      - awakeasleep 11mo ago
        Because it burns out developers and ruins the project. Its like how the treatment can be worse than the disease in medicine. The CVEs get reported, then big corps automated systems start flagging all use of ffmpeg, the big corp security software stops builds and removes it from dev laptops, then frustrated big corp engineers start harassing the volunteers and soon its not worth volunteering anymore, and the project dies, and there was never a real world impact.
hdgvhicv 11mo 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.
throwaway2046 11mo ago
https://xcancel.com/ffmpeg/status/1984207514389586050 https://xcancel.com/ffmpeg/status/1984207514389586050
Ekaros 11mo 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.
deleted 11mo ago
[deleted]
roarinelk 11mo ago
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?

107 points by trollied 11mo ago

cebert 11mo 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.

TZubiri 11mo ago
You think google uses ffmpeg for youtube?
- joatmon-snoo 11mo ago
  They do.
  - defrost 11mo ago
    Full build with all the codecs, or a custom build with a limited vetted set?
    - Telaneo 11mo ago
      Does it matter? Like, I don't expect Google to deliver patches for FFmpeg beyond bug fixes or features that directly benefit them, but that's the least you can expect.
      - defrost 11mo ago
        It matters to Google if they process public submitted videos using FFmpeg codecs that can be exploited. One would expect Google to only use FFmpeg with vetted codecs and to either reject videos with codecs that have untrusted FFmpeg modules or to sandbox any such processing, both for increased safety and perhaps to occassionally find new malware "in the wild".
- Telaneo 11mo ago
  They did once upon a time atleast.[1] Most videos probably go through dedicated hardware nowadays, but it wouldn't surprise me if some videos still have to go the FFmpeg route that catches all the videos that the dedicated hardware can't handle. [1] https://web.archive.org/web/20110315155125/https://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/ https://web.archive.org/web/20110315155125/https://multimedi...
joatmon-snoo 11mo ago
No, this is the unfortunate reality of “ffmpeg is maintained by volunteers” and “CVE discovered on specific untrusted input”. Google’s AI system is no different than the oss-fuzz project of yesteryear: it ensures that the underlying bug is concretely reproducible before filing the bug. The 90-day disclosure window is standard disclosure policy and applies equally to hobby projects and Google Chrome.
- haskellshill 11mo ago
  Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?
  - hdgvhicv 11mo ago
    “This is broken, here’s how I fixed it” Vs “this is broken, you gave 90 days to fix it” If you can’t see the difference you’re the existential threat to Free software that stems from the trillion dollar industries that just take.
    - haskellshill 11mo ago
      > you have 90 days to fix it Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here. If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.
socalgal2 11mo ago
A quick search of the ffmpeg commit history shows google has made plenty of contributions to ffmpeg. They may or may not provide a patch for this CVE but reporting it is the first step so people can then decide what action to take (like don't compile that codec in for example)
blueg3 11mo ago
I don't think Google is expecting anything here. They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe. The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse. It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it. The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.

TheChaplain 11mo 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...

cebert 11mo ago
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 11mo ago
  > FFmpeg would present a warning Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.
lukeschlather 11mo ago
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 11mo ago
  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.

PaulKeeble 11mo 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.

_flux 11mo ago
Perhaps it'll be sooner than you expect: actually having proper fixes made by AI for the issues found with AI.
Telaneo 11mo ago
I can't help but be reminded about the time that an MS employee put in a ticket on FFmpeg's bug tracker and said it was 'High priority'.[1][2] On the one hand, this one Microsoft employee was probably in a bind and actually blocked by this bug. On some level, it's hard to blame them as an individual. On the other hand, Microsoft has no leverage here and pays somewhere between a pittance and nothing for FFmpeg, while getting enormous use out of it. If they regularly donated with either money or patches, then there'd be no beef, but it's the expectation of getting something more for free while already getting so damn much for for zero cents that really grinds both mine and FFmpeg's gears. That reminds me that I should probably throw some money at FFmpeg, if only to clear my conscience. [1] https://xcancel.com/FFmpeg/status/1775178805704888726 https://xcancel.com/FFmpeg/status/1775178805704888726 [2] https://news.ycombinator.com/item?id=39912916 https://news.ycombinator.com/item?id=39912916
bawolff 11mo ago
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.
- thatguysaguy 11mo ago
  It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.

anon_oss 11mo ago

[flagged]

socalgal2 11mo ago
Because not disclosing an actual bug that could affect users would somehow be good?
- anon_oss 11mo ago
  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.
galaxy_gas 11mo ago
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
jsnell 11mo ago
So, this is the report they complained about: https://issuetracker.google.com/issues/440183164 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 11mo ago
  Fair enough, I hadn't seen the bug report and assumed it was the usual AI slop.

vqtska 11mo ago

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.

chemotaxis 11mo ago
The somewhat depressing reality is that if you're running ffmpeg on user-supplied multimedia without putting it in a bulletproof sandbox, you're just bound to have a bad time. Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step you need to take. Maybe it's on the ffmpeg project that they don't steer people in that direction. Trying to fix these bugs piecemeal is somewhat pointless - or at least, we've been trying for several decades, throwing a ton of manpower and compute at it, and we're still nowhere near a point where you could say "this is safe".
- ozgrakkurt 11mo ago
  Does this mean we have to run vlc in a sandbox while watching a downloaded film?
  - awakeasleep 11mo ago
    In production? With a user-supplied film? You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)
ls612 11mo ago
It isn't even like this is without precedent, the FORCEDENTRY NSO kit used the shitty old JBIG2 parser that Apple was shipping as its entry point despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.

GaryBluto 11mo 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.

fabrice_d 11mo ago
It is absolutely Google's security issue if they use an open source project with that license: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING.LGPLv2.1#l435 https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING.... and then expect volunteers to provide them fixes.
- GaryBluto 11mo ago
  It's not just Google who could be affected by this. > and then expect volunteers to provide them fixes. Expect volunteers to provide everyone using the software with fixes.
  - sillywabbit 11mo ago
    For a bug in the LucasArts Smush codec? Why didn't you verify it was an mp4/h264 first?

mappu 11mo ago

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

vreg 11mo ago
He sounds bitter.
pityJuke 11mo ago
it’s very… sad, i guess, watching a lot of software engineering discourse on social media (at least, what I see from Twitter) just become this attention grabbing shitposting. ffmpeg is very much a big player in this field, and it has paid off handsomely - those tweets are often popular on site, and shared across other social media.
- Ygg2 11mo ago
  > paid off handsomely Paid off how? Did they get more funding? More contributors?
  - cratermoon 11mo ago
    "exposure"
casey2 11mo ago
Wow these people have a lot of free time... shouldn't they be programming?
secondcoming 11mo ago
The most interesting part of that is the admission that they used decompilers to reverse engineer the codecs. I wonder if makign that output freely available is legal.
- ronsor 11mo ago

GeekyBear 11mo ago

Those who do not learn from Stagefright are doomed to repeat it. https://en.wikipedia.org/wiki/Stagefright_(bug) https://en.wikipedia.org/wiki/Stagefright_(bug)

gnfargbl 11mo 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 https://x.com/FFmpeg/status/1984425167070630289

vreg 11mo ago
All code should be considered potentially vulnerable, that's why we have so many layers of exploit mitigation from the compiler to the runtime environment to the overall design of the system the code is running in.
TZubiri 11mo ago
> unless you pay them You can't pay for the software >"FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment" https://www.ffmpeg.org/legal.html https://www.ffmpeg.org/legal.html
- deleted 11mo ago
  [deleted]
- gnfargbl 11mo ago
  I edited my post to make the nature of the requested payment clearer.

tonetegeatinst 11mo 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.

mkl 11mo 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 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/140fd653aed8cad774f991ba083e2d01e86420c7/ 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/5f8cb575e83a05bc95b82d7f5f572d8f554f3705 https://github.com/FFmpeg/FFmpeg/commit/5f8cb575e83a05bc95b8..., https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6ce8482f3065e4c36c3f97 https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6c...

bawolff 11mo 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.

hitekker 11mo ago
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.
- x0x0 11mo ago
  Even if they have real-world impact: ffmpeg is a volunteer project. With (ffmpeg -codecs | wc -l) 519 codecs. This will trivially exhaust available ffmpeg eng resources.
  - haskellshill 11mo ago
    There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?
    - awakeasleep 11mo ago
      Because it burns out developers and ruins the project. Its like how the treatment can be worse than the disease in medicine. The CVEs get reported, then big corps automated systems start flagging all use of ffmpeg, the big corp security software stops builds and removes it from dev laptops, then frustrated big corp engineers start harassing the volunteers and soon its not worth volunteering anymore, and the project dies, and there was never a real world impact.

hdgvhicv 11mo 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.

throwaway2046 11mo ago

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

Ekaros 11mo 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.

deleted 11mo ago

[deleted]

roarinelk 11mo ago

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?