Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
- 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...
by TheChaplain - 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.by cebert
- >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
by haskellshill - 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.
- 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.
by hdgvhicv - 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.
by GaryBluto - You get what you pay for.by paradox460
- Yeah, I mean if it's an actual vulnerability what are they complaining for?by haskellshill
- This is a volunteer-run open source project. Your expectations are unrealistic and, to be quite frank, offensive.by vreg
- Nah, I think they can rant as much about it as they want, nothing is unprofessional on Twitter - have you seen the state of of it?
Actually I think they are using correctly, you are suppose to post something to provoke the most reactions you can.
But getting back to the point, I agree, it is not really a problem if you actually verified your input before blindly running ffmpeg on it - like people are not just downloading random files and running ffmpeg on it are they?! You would think if you are rolling ffmpeg into production code you would know the ins and outs of it.
Anyways I feel for those open-source maintainers, they must have so deal with so much noise.
by execution - Kindly do the needful and update ticket in Jira when complete.
- 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....
and then expect volunteers to provide them fixes.
by fabrice_d - I feel like you’re misunderstanding their point.
It’s not that the vulnerability was found and reported, it’s that a trillion plus dollar organization that no doubt actively uses ffmpeg in a litany of spaces is punting the important work of fixing it to volunteers.
This is the same issue that we’re seeing over with XSLT in Chrome: they’re happy when they’re making money off the back of these projects but balk when it comes down to supporting them.
(Yes, everyone is aware Google contributes to open source. They’re still one of the most valuable companies to ever exist, there is almost no excuse for them getting away with this trade off)
by Klonoar - Those who do not learn from Stagefright are doomed to repeat it.by GeekyBear
- 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...
by mkl - 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?
by gnfargbl - > 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"
by TZubiri - 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.by vreg
- Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/by mappu
- 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.by secondcoming
- He sounds bitter.by vreg
- Wow these people have a lot of free time... shouldn't they be programming?by casey2
- 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.by pityJuke
- 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.
by hitekker - 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.by cebert
- You think google uses ffmpeg for youtube?by TZubiri
- 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.
by blueg3 - 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)by socalgal2
- 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.
by joatmon-snoo