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.
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".
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.
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.
I think that the x264 and hevc codecs are much more battle tested and a 0day for them would be worth enough that nobody would bother using it on random torrenters.
TPB? No. But 1337 and rutracker definitely do basic quality control. Nothing like a private tracker but they take down things like .mkv.lnk and similar.
> 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.
Or in, you know, external libraries. Maybe ffmeg shall be run with sanitized input (and not from a "web page" ) ? Just saying
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
ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.
If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.
If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.
Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.
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?
> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.
But it was a product using a 9 year old ffmpeg build (at the time).
I'd still consider that an academic exercise rather than an exploit that was deployed in the real world (aka against a machine the attacker did not control)
Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still.
If the exploit chain involves the user downloading and opening a file, something like >99% of the time the next step already involves executable code (or Office macros), which makes any ffmpeg vuln completely useless.
In fairness, i dont think the majority of actual exploits used in the wild get writeups.
Budget web host using outdated software getting hacked because they havent updated in 2 years isn't exactly all that interesting of a blog post even if the victim knows enough to figure out what happened.
Yes, I’m quite familiar with that. Chrome is why I added the “generally” qualifier.
And to the best of my knowledge, there has not been any in-the-wild exploit against Chrome through the handful of ffmpeg codecs they enable. Not even pwn2own type competitions either, as I recall.
I guess I'm confused - are you trying to imply the lack of a thorough, publicly reported successful exploit (or us just not casually giving you one that you care about) means that we're all released from the responsibility of taking potential exploits seriously?
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.
Yes, lots. To name an example, yt-dip uses it on all platforms, including Windows, which means that any video downloader front-end that uses it also uses FFmpeg.
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.
"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 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.
>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.
FWIW I tried replicating it and didn't get the same result. I end up with a failed conversion, exit code 69[0]. Same thing when I run with my installed version of ffmpeg.
But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.
Btw:
ffmpeg -codecs | cat | grep SANM 2&>/dev/null
ffmpeg version n8.0 Copyright (c) 2000-2025 the FFmpeg developers
... ffmpeg flags ...
D.V.L. sanm LucasArts SANM/SMUSH video
So my version does have that codec, as others are reporting.
Security vulnerability finding is a contribution. On the open market the type of service google is providing here would cost hundreds of thousands of dollars if not millions.
> 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.
That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
Be careful, the Europeans tried (had the python foundation not pushed back hard, would have) and still would love to require anyone who's ever built a piece of software to perform maintenance for them on demand.
> That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions.
> But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
In your view would it be acceptable to backdoor open source software to sell user's data to the highest bidder? That's obviously not what happened here, but seems like the obvious conclusion of your argument.
Software licenses already make the conditions íj which they are offered to you very clear.
It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.
Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no intention of fixing them.
Basically i think open source projects (like everyone) have a moral duty to be honest and not try and decieve people, regardless of what the license says.
You make it sound like this is a common problem in open source projects, like they are trying to cover up existing issues, or claiming they are fixing security issues when they are actually ignoring. Do you think this is the case? Can you name a few projects where you noticed this?
I'm somewhat with you but we're also talking about a $3.4T company that's depending on an OSS project with what... under a $1m budget? It seems they're pretty resource constrained.
I'm pretty sure Google makes more through Chrome's usage of libav than ffmpeg's entire budget. So yeah, I think Google should put effort back in and I think it's in their best interest.
Trillion dollar companies standing on top of open source projects and giving little to nothing back is not okay. It's also just stupid since they're eating their own foundations
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.
Duh no, wtf. No one has the duty to fix the security issue unless they are paid for the open source codes they give. They don't threaten you to use their codes either.
If you want the security issue to be fixed, make a PR or offer the price you are willing to pay for them to fix.
By the same token nobody has the duty to responsibly disclose security bugs. The entire premise of responsible disclosure is that security researchers give time for upstream projects to fix security issues by privately reporting the issues, in exchange the maintainers graciously accept the reports. Its a deal that benefits maintainers much more than it benefits researchers. If ffmpeg doesn't want that deal, then google should go the full disclosure route.
> If you want the security issue to be fixed,
There is no indication that google actually cared much whether the issue got fixed or not. It seems like the course of events is that they noticed something looked wrong with the code so they filed a bug. That's it.
> willing to pay for them to fix.
Should ffmpeg pay for security researchers time to find these issues? The market price for that is much much much higher than the price to fix bugs.
If you were to pay someone to do vulnerability testing in ffmpeg with sufficient skill to find this issue, it would probably cost you in the hundreds of thousands of dollars at least.
Yes, that's right. Nobody has the duty to disclosure the security bugs. It's the security researchers' principles, and if they want to follow that, they can follow that.
But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put the confidence that it "benefits maintainers" than "benefit researchers", unless the maintainers declare that themselves. In this case there's no patch, no fix, no PR either, just issue-submission. "You have more benefits" are the claims of the researchers who think that their issue-submission contributions top everything else.
Finding and disclosing the security are issue-submission contributions, and that's it. Don't make it as a gift or something. ffmpeg doesn't have the need to find these issues, and they don't pay for it for it either. And vice versa, they have no duties to fix the issues. They don't force the security researchers to find and disclose things. If security researchers want to do it themselves, they can do whatever they want, but stop at forcing duties to the maintainers. The only thing I don't agree with ffmpeg is bringing those issues social while they can just ignore them, that's it.
I mean, i agree, ffmpeg are under no obligation to do anything. (In the heat of the moment i think my previous comment went too far, i would phrase it more, as if you want to be a "quality" software project then you have to respond to real security bugs promptly).
How often do you get your bug reports fixed that fast? When i file bugs in open source projects it usually takes at least weeks if im lucky to get a response. People almost never respond within 1 day. I think that demonstrates how valuable ffmpeg views these reports.
If the report was a garbage report (like e.g. the ones the curl maintainer complains about) i'd have more sympathy, but clearly ffmpeg views this issue submission as valuable. The whole thing makes me think of choosing-beggars. They want the google report but also are trying to use social pressure to make google contribute even more.
If they didn't want google's reports that's one thing - just reject them, but both wanting them while also demanding more is scummy in my opinion. Either accept or reject them.
Nope. Don't mistake a quick fix as they are "valuable" to the maintainers. They said clearly that it's a hobby project and at the most it just simply means that some volunteers were interested and wanted to fix it, or the fix is not complex, and I would just stop at that. The "valuable" is, again, an outsider view that is forced to the maintainers. Same as "They want google report" thing. Just because they fix some issues reported from someones doesn't mean that they view all of those reports being "valuable".
At most, I would just see that they are annoyed by the issue procedures (without PRs) of the "researchers" and they complaint on the social. I don't agree with their complaints because the "researchers" did nothing wrong either. And that's it, I would stop at that. Putting the whole "duty", "valuable reports" and "demand more" on them is just as bs as their complaints.
i’m sorry, but when it comes to open source software if you want something on your timeline, you do it. the code is there. it’s _open_.
if “a duty” exists at all in this situation, it’s on the 4th wealthiest company in the world who is using that free software to serve its customers and raking in billions of dollars. (i want to be clear tho, that company does contribute a lot to the open source community. a whole lot. i’m just saying, if someone is hunting for a “duty” to fling around re: an open source project)
i was once naively saying some undeserved similar nonsense to a well known open source dev regarding some software package they were working on years ago, and he responded absolutely appropriately, [paraphrasing] “go ahead, you should absolutely do it, see if it’s better. none of us here are stopping you. we genuinely hope it is, truly. let us know. until then we’re working on other stuff.”
he was absolutely correct and i should have known better. not snotty at all, just, “you should totally do it!” that’s the appropriate answer every single time someone behaves as if your open source project owes them something. even more so when it’s the 4th richest company in the world.
so if you feel “a duty” exists somewhere to change something with ffmpeg, do it yourself. literally no one is stopping you. it’s _open source_.
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.
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.
What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug.
> currently have zero real-world impact
So better we not talk about them until someone bothers to write an exploit for it?
> the "researchers" didn't even bother to write a patch/fix
If it has no real-world impact and thus shouldn't even be reported, then why does it need to be fixed?
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.
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?
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.
My point of view is that the unpaid ffmpeg maintainers should stop playing along with the corporate "security researchers" and not prioritize a bug over everything else simply because it's a CVE. In this case, the "high priority CVE" is from a reverse-engineered codec a hobbyist wrote to decode video from 1990s LucasArts video games. I think it's unreasonable to expect the maintainers to drop everything to fix a bug in a codec that most people will never use. If the trillion-dollar companies sending AI-generated CVE reports care so strongly about getting them fixed ASAP, they should really be fixing them themselves.
My hope is that if they started responding to CVE bug reports for hobby codecs with something like “This is a codec written by someone in his free time and intended to be used for preservation purposes. We do not support using this codec with untrusted input and may not implement a fix for this bug within the 90 day CVE timeline”, it would stop the harassment. The companies doing the CVE spam would either have to start fixing things themselves, contract someone to do so, or stop using ffmpeg due to all the scary CVEs getting flagged in whatever bullshit security compliance standard they use.
It would not stop the harassment at all. These reports are effectively free for the originating organization to write using AI - and some low level junior looking for promotion within said org will be highly motivated to pump those metrics up come review time.
You’d have to basically blacklist these orgs from all bug reports and maybe open it up to a select few known trusted senior resources that care more about their personal reputation within the community vs. corporate politics.
> This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-11-20 [https://issuetracker.google.com/issues/436510153]
Sounds like a threat to me. ffmpeg is a tiny team and Google is a goliath. Not to mention Google has used their AI to spam the same threat, about 8 times in the last few months https://ffmpeg.org/security.html
Google is hardly the first people to come up with the notion of responsible disclosure. Whether you agree or not with the practise, the goal is to balance the needs of the maintainer with the needs of consumers. In practise such practises have massively boosted security of computer systems.
There is a lot of historical context with this sort of thing that has lead to systems like this that has nothing to do with google.
Besides google did not sign an NDA, they aren't under any obligation to keep anything secret. 90 days is a courtesy. They are fully within their rights to just publish their findings immediately if they felt like it.
If you don't then your users should have the right know, so they can decide for themselves whether or not the risk is worth it.
Do you think that just because a project doesn't disclose something it goes away, or that if google can find the bug that much better funded groups like the NSA or malware vendors can't. Shoving things under the rug is the worst outcome.
What absolute nonsense. There's a gulf of difference between "there's no way 500+ codecs contributed mostly by unpaid hobbyists is robust to hostile input" and "here's working exploit code."
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.
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".
Does this mean we have to run vlc in a sandbox while watching a downloaded film?
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)
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.
> despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.
Then why it has been enabled ? Asking for a friend. /s
Unless Apple, ffmpeg has a reason to enable old codecs. If you only need a subset: configure; make; make install
> Then why it has been enabled ? Asking for a friend. /s
Because it's in the PDF spec, and you can't randomly disable parts of that.
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.
I think that the x264 and hevc codecs are much more battle tested and a 0day for them would be worth enough that nobody would bother using it on random torrenters.
But you don't need to use a popular codec, because all codecs are enabled by default.
Yeah but most public trackers will give lots of side eye to torrents that contain an mkv that isn’t in one of those two formats.
Really? You think trackers download files and analyse their contents before listing them? I don't.
TPB? No. But 1337 and rutracker definitely do basic quality control. Nothing like a private tracker but they take down things like .mkv.lnk and similar.
You can report viruses on TPB's forum, there's usually entire accounts which upload viruses which are easy to find.
> 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.
Or in, you know, external libraries. Maybe ffmeg shall be run with sanitized input (and not from a "web page" ) ? Just saying
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
ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.
If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.
If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.
Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.
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?
Does this count?
https://signal.org/blog/cellebrite-vulnerabilities/
> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.
But it was a product using a 9 year old ffmpeg build (at the time).
I'd still consider that an academic exercise rather than an exploit that was deployed in the real world (aka against a machine the attacker did not control)
Yeah, that’s just how life is. We used to run with Heartbleed and Spectre turned off.
> Does this count?
If Signal relies on ffmpeg to play videos instead of an externall app, i would say it is broken by design.
I'm certain it's happened but since I don't have one off the top of my head I'll instead point out a related issue: https://en.wikipedia.org/wiki/Stagefright_(bug)
It's worth pointing out that many, many, many things use the libav* library family.
Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still.
If the exploit chain involves the user downloading and opening a file, something like >99% of the time the next step already involves executable code (or Office macros), which makes any ffmpeg vuln completely useless.
In a past life as a managed hosting provider ffmpeg exploits were used to gain access to systems.
It’s used for pretty much any platform you can upload video to. Some places far more competently than others.
See, I’d be interested in any actual evidence/writeups of that in the wild.
In fairness, i dont think the majority of actual exploits used in the wild get writeups.
Budget web host using outdated software getting hacked because they havent updated in 2 years isn't exactly all that interesting of a blog post even if the victim knows enough to figure out what happened.
Chrome uses ffmpeg's underlying libraries.
It's used way, way more than you think.
Yes, I’m quite familiar with that. Chrome is why I added the “generally” qualifier.
And to the best of my knowledge, there has not been any in-the-wild exploit against Chrome through the handful of ffmpeg codecs they enable. Not even pwn2own type competitions either, as I recall.
I guess I'm confused - are you trying to imply the lack of a thorough, publicly reported successful exploit (or us just not casually giving you one that you care about) means that we're all released from the responsibility of taking potential exploits seriously?
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.
Yes, lots. To name an example, yt-dip uses it on all platforms, including Windows, which means that any video downloader front-end that uses it also uses FFmpeg.
...I mean "yt-dlp", of course. Phone autocorrected >_<
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.
Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists
"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 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
[2] https://news.ycombinator.com/item?id=39912916
YouTube made $36.7 billion last year. Time they started pulling their weight.
They have around at least 3000 commits, assuming this search is right?
https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+%40google...
And they have done large pushes in the past: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
Perhaps it'll be sooner than you expect: actually having proper fixes made by AI for the issues found with 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.
I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of *your code*.
> Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.
Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.
FWIW I tried replicating it and didn't get the same result. I end up with a failed conversion, exit code 69[0]. Same thing when I run with my installed version of ffmpeg.
But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.
Btw:
So my version does have that codec, as others are reporting.[0] Will expire soon https://0x0.st/KL6K.log
[DISCLOSURE]: I AM NOT A SECURITY PROFESSIONAL. If I am wrong please correct me
Security vulnerability finding is a contribution. On the open market the type of service google is providing here would cost hundreds of thousands of dollars if not millions.
> 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.
That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
Be careful, the Europeans tried (had the python foundation not pushed back hard, would have) and still would love to require anyone who's ever built a piece of software to perform maintenance for them on demand.
> That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions.
> But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
In your view would it be acceptable to backdoor open source software to sell user's data to the highest bidder? That's obviously not what happened here, but seems like the obvious conclusion of your argument.
Software licenses already make the conditions íj which they are offered to you very clear.
It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.
Morality and legality are not the same thing.
Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no intention of fixing them.
Basically i think open source projects (like everyone) have a moral duty to be honest and not try and decieve people, regardless of what the license says.
You make it sound like this is a common problem in open source projects, like they are trying to cover up existing issues, or claiming they are fixing security issues when they are actually ignoring. Do you think this is the case? Can you name a few projects where you noticed this?
Doesn't Chrome use libavcodec?
I'm somewhat with you but we're also talking about a $3.4T company that's depending on an OSS project with what... under a $1m budget? It seems they're pretty resource constrained.
I'm pretty sure Google makes more through Chrome's usage of libav than ffmpeg's entire budget. So yeah, I think Google should put effort back in and I think it's in their best interest.
Trillion dollar companies standing on top of open source projects and giving little to nothing back is not okay. It's also just stupid since they're eating their own foundations
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.
It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.
Duh no, wtf. No one has the duty to fix the security issue unless they are paid for the open source codes they give. They don't threaten you to use their codes either.
If you want the security issue to be fixed, make a PR or offer the price you are willing to pay for them to fix.
By the same token nobody has the duty to responsibly disclose security bugs. The entire premise of responsible disclosure is that security researchers give time for upstream projects to fix security issues by privately reporting the issues, in exchange the maintainers graciously accept the reports. Its a deal that benefits maintainers much more than it benefits researchers. If ffmpeg doesn't want that deal, then google should go the full disclosure route.
> If you want the security issue to be fixed,
There is no indication that google actually cared much whether the issue got fixed or not. It seems like the course of events is that they noticed something looked wrong with the code so they filed a bug. That's it.
> willing to pay for them to fix.
Should ffmpeg pay for security researchers time to find these issues? The market price for that is much much much higher than the price to fix bugs.
If you were to pay someone to do vulnerability testing in ffmpeg with sufficient skill to find this issue, it would probably cost you in the hundreds of thousands of dollars at least.
Yes, that's right. Nobody has the duty to disclosure the security bugs. It's the security researchers' principles, and if they want to follow that, they can follow that.
But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put the confidence that it "benefits maintainers" than "benefit researchers", unless the maintainers declare that themselves. In this case there's no patch, no fix, no PR either, just issue-submission. "You have more benefits" are the claims of the researchers who think that their issue-submission contributions top everything else.
Finding and disclosing the security are issue-submission contributions, and that's it. Don't make it as a gift or something. ffmpeg doesn't have the need to find these issues, and they don't pay for it for it either. And vice versa, they have no duties to fix the issues. They don't force the security researchers to find and disclose things. If security researchers want to do it themselves, they can do whatever they want, but stop at forcing duties to the maintainers. The only thing I don't agree with ffmpeg is bringing those issues social while they can just ignore them, that's it.
I mean, i agree, ffmpeg are under no obligation to do anything. (In the heat of the moment i think my previous comment went too far, i would phrase it more, as if you want to be a "quality" software project then you have to respond to real security bugs promptly).
My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within 1 day: https://github.com/FFmpeg/FFmpeg/commit/c41a70b6bb79707e1e3a...
How often do you get your bug reports fixed that fast? When i file bugs in open source projects it usually takes at least weeks if im lucky to get a response. People almost never respond within 1 day. I think that demonstrates how valuable ffmpeg views these reports.
If the report was a garbage report (like e.g. the ones the curl maintainer complains about) i'd have more sympathy, but clearly ffmpeg views this issue submission as valuable. The whole thing makes me think of choosing-beggars. They want the google report but also are trying to use social pressure to make google contribute even more.
If they didn't want google's reports that's one thing - just reject them, but both wanting them while also demanding more is scummy in my opinion. Either accept or reject them.
Nope. Don't mistake a quick fix as they are "valuable" to the maintainers. They said clearly that it's a hobby project and at the most it just simply means that some volunteers were interested and wanted to fix it, or the fix is not complex, and I would just stop at that. The "valuable" is, again, an outsider view that is forced to the maintainers. Same as "They want google report" thing. Just because they fix some issues reported from someones doesn't mean that they view all of those reports being "valuable".
At most, I would just see that they are annoyed by the issue procedures (without PRs) of the "researchers" and they complaint on the social. I don't agree with their complaints because the "researchers" did nothing wrong either. And that's it, I would stop at that. Putting the whole "duty", "valuable reports" and "demand more" on them is just as bs as their complaints.
> volunteers were interested and wanted to fix
If that's not the definition of valuable then what is?
As you said, its a volunteer project. What other metric of value is there other than a volunteer being interested?
No person, ever, has a duty to fix security issues in free software with a no-warranty license. If you want your security fixes, pay for them.
i’m sorry, but when it comes to open source software if you want something on your timeline, you do it. the code is there. it’s _open_.
if “a duty” exists at all in this situation, it’s on the 4th wealthiest company in the world who is using that free software to serve its customers and raking in billions of dollars. (i want to be clear tho, that company does contribute a lot to the open source community. a whole lot. i’m just saying, if someone is hunting for a “duty” to fling around re: an open source project)
i was once naively saying some undeserved similar nonsense to a well known open source dev regarding some software package they were working on years ago, and he responded absolutely appropriately, [paraphrasing] “go ahead, you should absolutely do it, see if it’s better. none of us here are stopping you. we genuinely hope it is, truly. let us know. until then we’re working on other stuff.”
he was absolutely correct and i should have known better. not snotty at all, just, “you should totally do it!” that’s the appropriate answer every single time someone behaves as if your open source project owes them something. even more so when it’s the 4th richest company in the world.
so if you feel “a duty” exists somewhere to change something with ffmpeg, do it yourself. literally no one is stopping you. it’s _open source_.
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.
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.
What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug.
> currently have zero real-world impact
So better we not talk about them until someone bothers to write an exploit for it?
> the "researchers" didn't even bother to write a patch/fix
If it has no real-world impact and thus shouldn't even be reported, then why does it need to be fixed?
ffmpeg is getting DDOS'd by AI generated security CVEs.
Not by classic bug reports.
It's a pretty good report by bigsleep. It even comes with a good explanation and reproducer.
I like to get such reports from the occasional fuzzer. Just ignore the CVE, it's a bug
This particular issue has a PoC to reproduce it. It seems very much that it would have real world impact
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.
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?
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.
My point of view is that the unpaid ffmpeg maintainers should stop playing along with the corporate "security researchers" and not prioritize a bug over everything else simply because it's a CVE. In this case, the "high priority CVE" is from a reverse-engineered codec a hobbyist wrote to decode video from 1990s LucasArts video games. I think it's unreasonable to expect the maintainers to drop everything to fix a bug in a codec that most people will never use. If the trillion-dollar companies sending AI-generated CVE reports care so strongly about getting them fixed ASAP, they should really be fixing them themselves.
You're completely missing the point.
The problem isn't that volunteer devs are harassed into work.
The problem is being harassed.
Whether or not you "care" or feel the need to do any work or accept responsibility, constant harassment will destroy anyone, even you.
My hope is that if they started responding to CVE bug reports for hobby codecs with something like “This is a codec written by someone in his free time and intended to be used for preservation purposes. We do not support using this codec with untrusted input and may not implement a fix for this bug within the 90 day CVE timeline”, it would stop the harassment. The companies doing the CVE spam would either have to start fixing things themselves, contract someone to do so, or stop using ffmpeg due to all the scary CVEs getting flagged in whatever bullshit security compliance standard they use.
It would not stop the harassment at all. These reports are effectively free for the originating organization to write using AI - and some low level junior looking for promotion within said org will be highly motivated to pump those metrics up come review time.
You’d have to basically blacklist these orgs from all bug reports and maybe open it up to a select few known trusted senior resources that care more about their personal reputation within the community vs. corporate politics.
Getting a polite bug report is not being harrased.
> This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-11-20 [https://issuetracker.google.com/issues/436510153]
Sounds like a threat to me. ffmpeg is a tiny team and Google is a goliath. Not to mention Google has used their AI to spam the same threat, about 8 times in the last few months https://ffmpeg.org/security.html
Google is hardly the first people to come up with the notion of responsible disclosure. Whether you agree or not with the practise, the goal is to balance the needs of the maintainer with the needs of consumers. In practise such practises have massively boosted security of computer systems.
There is a lot of historical context with this sort of thing that has lead to systems like this that has nothing to do with google.
Besides google did not sign an NDA, they aren't under any obligation to keep anything secret. 90 days is a courtesy. They are fully within their rights to just publish their findings immediately if they felt like it.
Fix it or we publish exploit code is not far off.
Well either you care about security or you don't.
If you don't then your users should have the right know, so they can decide for themselves whether or not the risk is worth it.
Do you think that just because a project doesn't disclose something it goes away, or that if google can find the bug that much better funded groups like the NSA or malware vendors can't. Shoving things under the rug is the worst outcome.
What absolute nonsense. There's a gulf of difference between "there's no way 500+ codecs contributed mostly by unpaid hobbyists is robust to hostile input" and "here's working exploit code."
So let them publish exploit code. What's the problem?
There is no law you can't complain about lack of help on Twitter
Also, could you quote the request to sweep bugs under the rug?
The main ask seems to be "send patches" later in the thread
> Recieving vuln reports is a gift.
A real gift would be to include a patch for it. Not just to run off into the sunset.
[flagged]