>The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources
Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
I've been using ffmpeg for a very long time, both personally and for services I've built. Fabrice Bellard is a genius, and the developers who have taken it so far have made the world measurably richer.
But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard.
> At this point the corrupted free pointer is called, and control of the instruction pointer is ours.
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
The article glosses over this, but it looks like the next variable in the struct is conveniently the first parameter to the function, so you can run arbitrary code with system() or whatever. But, yeah, you would need some other exploit to defeat ASLR.
Is the future of defense-against-foreign-agents-on-my-codebase to subtly hide prompt injections into one’s codebase that would defeat agents to find security bugs ?
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
Most of them involve very weird and unlikely scenarios and bad security practices or access to the ffmpeg binaries and being allowed to run arbitrary commands at an elevated permission.
In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.
That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.
Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago:
So, while it's a demo of the capabilities of LLMs, this should not be at all surprising. Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. I know that people do, and these people are taking unreasonable risks.
while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.
FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.
Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no?
I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.
You could assume that if someone has the technical level to identify a vulnerability and how to exploit it, they probably have the technical level to fix it.
In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job.
FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it.
The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible?
They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.
Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up.
They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used.
I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it.
Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?
I’m this video you will also learn that much of it is coded in assembly! The developers are prioritizing performance to the extreme, which has its benefits, but I would expect assembly to open up the code to a whole world of vulnerabilities.
FFmpeg is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain.
It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.
What about VLC's own built-in versions of decoding libraries (I think, from the FFmpeg project)? Is there a scenario here where we may have to deal with malicious MP4 files?
Inflated use of the term zero-day, while none of the described vulnerabilities is actually a zero-day. But it sounds and clicks good..
thank you for the PoC.
Even if this isn't as big a deal as this [advertisement for a security company] seems, it is a reminder that every application you release does have a security hole somewhere, and a script kiddie can now find it 5 minutes after release for $2 in credit. If you're not red-teaming your code before release, hackers are doing it after.
Help me understand: depthfirst seems to be bigging up their “security agent” here, but is it not just prompt engineering + writing skill files? What goes into producing a “security agent” beyond this? Feels like they’re really gussying up a process that is ultimately just LLM usage
I think the industry is optimizing for the wrong thing. Generating thousands of AI-written bug reports is easy, at least with Mythos (preview 1) or GPT-5.5. Getting bugs fixed is the hard part.
A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-specific kill switches or other internal mechanisms that weren’t documented, not because the vulnerability itself was misidentified.
Developers generally seem to prefer this approach. A bug report creates work. A good PR removes work. That sounds obvious, but a lot of security products still stop at the report and call it a day.
I just had an unsettling thought… those with access to Mythos/Fable finding these flaws — how many might be holding back and keeping some of these exploits in their back pocket?
> DFVULN-123 (Integer Overflow): In the RTP LATM depacketizer (rtpdec_latm.c), latm_parse_packet() performs a signed 32-bit addition that overflows and bypasses its bounds check
Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C or C++ do not have overflow checks also.
Ridiculous. It is obvious that humans cannot be trusted with writing correct arithmetics code.
The incentives structure is deeply broken in the field of Security Research.
They are the middle management of the FOSS world.
Celebrated for dumping more work on volunteers. The more urgent the work, the more they are celebrated. Acknowledging the realistic impact of issues or the pragmatic implications of an issue are at odds with their incentives.
It's hard not to see them as bottom feeders of the software industry and I wish we would starting treating them like pariah. Submit the PR or STFU.
Not suprised theres holes in codec implementations.
They are extremely complicated structurally.
Most modern codecs layer compression features endlessly in the pursuit of better compression.
The specs are insanely bloated.
Filesystems have the same problems, with huge bloated specs.
You wouldn't mount an untrusted filesystem.
Theres issues at all levels.
The filesystem, the stream muxer, the codec.
It would be nice if we could just use some simple uncompressed or lossless compression for video, and not need to have this mess of lossy codecs with endless compression features.
But computers/networks still dont have the bandwidth to practically handle uncompressed video in 2026, altho audio can be. I doubt theres many issues with lpcm.
56 comments
[ 3.6 ms ] story [ 67.2 ms ] threadWow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
Don't tranform your ffmpeg instance into a web browser.
But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard.
Secure sandboxing tends to mean opportunities to make unrestricted copies.
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.
In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.
That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.
https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
So, while it's a demo of the capabilities of LLMs, this should not be at all surprising. Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. I know that people do, and these people are taking unreasonable risks.
Yes, there are security issues but quite a few are not ffmpeg itself related - the input is pretty shabby or at least not exactly easy to deal with!
Obviously, they could do with some assistance and I'm sure you and I will both dive in with equal zeal.
You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.
I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.
In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job.
FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it.
It's an exhausting dynamic.
They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.
They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used.
I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it.
Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?
It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.
What about "ls"?
A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-specific kill switches or other internal mechanisms that weren’t documented, not because the vulnerability itself was misidentified.
Developers generally seem to prefer this approach. A bug report creates work. A good PR removes work. That sounds obvious, but a lot of security products still stop at the report and call it a day.
Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C or C++ do not have overflow checks also.
Ridiculous. It is obvious that humans cannot be trusted with writing correct arithmetics code.
Irrelevant. Simplicity here is better than complexity.
Unless you're handwriting assembly, this is a compiler's job.
It's hard not to see them as bottom feeders of the software industry and I wish we would starting treating them like pariah. Submit the PR or STFU.