FFmpeg Dealing with a Security Researcher
62 comments
·November 1, 2025vqtska
chemotaxis
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".
ls612
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.
IshKebab
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 as an attack vector, e.g. via torrents.
haskellshill
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
michaelt
Depends if any important websites are re-compressing user-uploaded videos. If there's a website converting user-uploaded gifs to mp4 to save on bandwidth or something, I wouldn't be surprised if they used ffmpeg to do it.
plorkyeran
No, all the ancient video game codecs and other such things that are there for historical preservation purposes but are rarely actually used are disabled by default and you have to really go out of your way to enable them. This was originally for binary size/build time reasons.
IshKebab
Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists
D.V.L. sanm LucasArts SANM/SMUSH videoPaulKeeble
"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.
Telaneo
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.
_flux
Perhaps it'll be sooner than you expect: actually having proper fixes made by AI for the issues found with AI.
cebert
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.
socalgal2
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)
joatmon-snoo
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
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?
TZubiri
You think google uses ffmpeg for youtube?
Telaneo
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://multimedi...
joatmon-snoo
They do.
defrost
Full build with all the codecs, or a custom build with a limited vetted set?
mappu
Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/
pityJuke
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
> paid off handsomely
Paid off how? Did they get more funding? More contributors?
secondcoming
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.
casey2
Wow these people have a lot of free time... shouldn't they be programming?
vreg
He sounds bitter.
GeekyBear
Those who do not learn from Stagefright are doomed to repeat it.
mkl
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...
gnfargbl
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?
vreg
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.
tonetegeatinst
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.
TheChaplain
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
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
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
Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?
chris_wot
Then they can certainly afford to supply patches.
cebert
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
> FFmpeg would present a warning
Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.
haskellshill
>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
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
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
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.
Klonoar
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)
haskellshill
Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.
fabrice_d
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.
joatmon-snoo
Google never asked a volunteer for a fix.
This is part of Google’s standard disclosure policy: it gets disclosed within 90 days starting from confirmation+contact.
If ffmpeg didn’t want to fix it, they could’ve just let the CVE get opened.
GaryBluto
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
For a bug in the LucasArts Smush codec? Why didn't you verify it was an mp4/h264 first?
execution
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.
vreg
This is a volunteer-run open source project. Your expectations are unrealistic and, to be quite frank, offensive.
spongebobstoes
What are their expectations, and which are unrealistic?
It reads to me like the only expectation is civility, not even necessarily an expectation of fixing it.
If Google can identify a vulnerability, what should they do? If they don't report it, they're effectively stockpiling weapons.
I'd wager that every usage of ffmpeg in Google infra is sandboxed, so calling this "Google's problem" seems silly to me.
Google can't be responsible for fixing everyone's sloppy C code.
GaryBluto
If a volunteer-run project wants to be full of CVEs and inevitably bleed users because of it, fine, but to whine about someone reporting a CVE in the first place is ridiculous. I'm not annoyed they haven't fixed it, I'm annoyed they're complaining about the problem being acknowledged.
herpessimplex10
Kindly do the needful and update ticket in Jira when complete.
haskellshill
Yeah, I mean if it's an actual vulnerability what are they complaining for?
paradox460
You get what you pay for.
anon_oss
I help maintain a popular open source project. It's bad enough getting reports from human idiot "researchers" who have no understanding of the attack surface nor what constitutes a vulnerability, and are just spamming their bullshit to try to collect worthless CVEs.
But now Google using the full power of their AI to do the same? Fuck off.
"Don't be evil" is long dead and buried. These worthless corporations taking and taking and rarely giving back, and even if they do it's poisoned.
galaxy_gas
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
socalgal2
Because not disclosing an actual bug that could affect users would somehow be good?
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.