alt Hacker NewsFFmpeg dealing with a security researcher
Comments
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.
"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.
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.
Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/
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?
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...
Those who do not learn from Stagefright are doomed to repeat it.
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.
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.
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.
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...
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.
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.
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.