FFmpeg is everywhere. It powers browser media playback, transcoding pipelines, surveillance systems, streaming platforms, and video conferencing infrastructure. If your application handles audio or video — and most do — FFmpeg is almost certainly in your stack, whether you realise it or not.
This week, security research firm Depthfirst published findings that should give every development team pause: their autonomous AI security agent discovered 21 zero-day vulnerabilities in FFmpeg, including several that enable full remote code execution. The cost? Approximately $1,000. Some of these bugs had been hiding in the codebase for over two decades.
TL;DR
- An AI-driven security agent discovered 21 zero-day vulnerabilities in FFmpeg at a cost of roughly $1,000 — including heap overflows, stack overflows, and integer overflows across demuxers, decoders, and protocol handlers
- Several vulnerabilities had been latent for over 20 years in one of the most widely audited open-source projects in existence, proving that human code review alone is insufficient
- A single 183-byte RTP packet can achieve full remote code execution via the AV1 depacketiser — no authentication required
- Media processing infrastructure is a massively overlooked attack surface: most teams treat FFmpeg as a black box and never audit it
- AI-powered vulnerability discovery is now cheaper and faster than traditional security audits, fundamentally changing the economics of both attack and defence
What Was Found
Depthfirst’s findings span FFmpeg’s entire architecture. The 21 vulnerabilities break down across several classes:
- 9 heap buffer overflows — the most dangerous category, enabling arbitrary memory corruption
- 3 stack buffer overflows — potential for control-flow hijacking
- 3 integer overflows/underflows — classic arithmetic bugs that cascade into memory corruption
- 1 heap buffer underflow — reading or writing before allocated memory
- Multiple remote code execution primitives — demonstrated with working proof-of-concept
The affected components read like a tour of FFmpeg’s core: the TS demuxer, VP9 decoder, swscale library, RTP depacketisers for AV1, JPEG, LATM, and MPEG-4, DASH/RTSP/RTMP protocol handlers, AVIF overlay processing, option parsing, SDP parsing, and the CAF and AVI demuxers.
Eight vulnerabilities have already received formal CVE assignments (CVE-2026-39210 through CVE-2026-39218), with thirteen more tracked internally pending assignment.
The 183-Byte Kill Shot
The most alarming finding is the RCE demonstration in the AV1 RTP depacketiser. A specially crafted 183-byte RTP packet — barely larger than a tweet — exploits a flaw in Temporal Delimiter OBU handling to corrupt heap metadata and hijack function pointers. The attack requires nothing more than pointing FFmpeg at a malicious stream:
ffmpeg -i rtsp://attacker/stream
No authentication. No unusual configuration. No user interaction beyond processing media from an untrusted source — which is precisely what media pipelines do all day, every day.
For teams running transcoding services, media ingest pipelines, or any form of user-uploaded video processing, this should be a wake-up call. Your media processing layer is almost certainly running with more privileges than it needs, handling untrusted input by design, and nobody has audited it since it was deployed.
Twenty-Three Years of Hiding in Plain Sight
Perhaps the most sobering detail is the age of these vulnerabilities. One bug dates back to 2003 — it has been sitting in the FFmpeg codebase for 23 years. Multiple others were introduced between 2005 and 2010, meaning they survived 15 to 20 years of development, code review, fuzzing campaigns, and security audits.
FFmpeg is not some neglected side project. It is one of the most scrutinised open-source projects in existence, with active maintainers, corporate sponsors, and a long history of security research. If bugs can hide this long in FFmpeg, they can hide anywhere.
This should recalibrate how teams think about “well-audited” dependencies. Manual code review and traditional fuzzing are necessary but clearly not sufficient. The attack surface of a complex C codebase like FFmpeg is simply too large for human reviewers to cover comprehensively.
The AI Economics of Vulnerability Discovery
The $1,000 price tag is the real story here. Traditional security audits of a codebase as complex as FFmpeg would cost tens of thousands of pounds and take weeks. Depthfirst’s autonomous agent achieved 21 zero-days for the price of a decent monitor.
This cuts both ways. On the defensive side, it means that small and mid-sized teams can now afford the kind of deep security analysis that was previously reserved for large enterprises with dedicated security budgets. At REPTILEHAUS, we have been integrating AI-powered security tooling into our DevSecOps pipelines for precisely this reason — the cost-to-coverage ratio has fundamentally shifted.
On the offensive side, however, the economics are equally compelling for attackers. If a research firm can find 21 zero-days for $1,000, so can a motivated threat actor. The barrier to discovering exploitable vulnerabilities in critical infrastructure has dropped by orders of magnitude. This is the new reality of the threat landscape.
Media Processing: The Forgotten Attack Surface
Most development teams spend their security budget on web application firewalls, authentication hardening, API security, and supply chain integrity. These are all important. But media processing infrastructure — the FFmpeg instances, ImageMagick installations, and transcoding workers humming away in the background — rarely gets the same attention.
Consider how many touchpoints your application has with media processing:
- User uploads: Profile pictures, video content, document previews — all processed by libraries that parse complex binary formats
- Streaming infrastructure: WebRTC, HLS, DASH — protocol handlers that accept data from potentially untrusted sources
- Thumbnail generation: Every image resize operation runs through code that parses untrusted input
- Media transcoding: Format conversion services that decompose and reconstruct media containers
- Surveillance and IoT: RTSP streams from cameras feeding directly into processing pipelines
Each of these is an entry point. Each runs code that was written in C, handles complex binary formats with countless edge cases, and was probably deployed once and never audited again.
What Your Team Should Do Now
This is not a “patch and forget” situation. The FFmpeg findings represent a systemic issue with how teams treat media processing infrastructure. Here is what we recommend:
1. Audit Your Media Processing Stack
Map every point in your infrastructure where media is processed. This includes obvious services like transcoding workers, but also less visible ones: thumbnail generators, document preview services, avatar processors, and video chat infrastructure. Know what versions of FFmpeg, ImageMagick, libvips, and similar libraries you are running.
2. Patch FFmpeg Immediately
If you are running any version of FFmpeg prior to the latest patched release, update now. The RCE via the AV1 RTP depacketiser is particularly critical for any service that handles RTSP streams or processes AV1 content.
3. Sandbox Media Processing
Media processing should run in isolated, sandboxed environments with minimal privileges. Use containers with restricted capabilities, seccomp profiles, and no network access beyond what is strictly required. If a heap overflow is exploited, the blast radius should be contained to a disposable container — not your application server.
4. Treat Media Input as Hostile
Apply the same input validation rigour to media files that you apply to API requests. Validate file headers before processing, enforce strict size and format limits, and reject anything that does not match expected parameters. Defence in depth applies to binary formats just as much as JSON payloads.
5. Integrate AI-Powered Security Scanning
The economics have shifted. AI-driven vulnerability scanning is now affordable for teams of all sizes. Tools like Depthfirst’s autonomous agent, alongside established platforms like Snyk and Semgrep, can catch the kinds of deep memory safety bugs that traditional SAST tools miss. If you are not already running AI-enhanced security analysis in your CI/CD pipeline, now is the time to start.
The Bigger Picture
The FFmpeg disclosure is a milestone moment. It demonstrates that AI-powered security research has crossed a threshold where it can systematically outperform decades of human analysis on complex C codebases — at a fraction of the cost. For defenders, this is an opportunity to dramatically improve their security posture. For the industry, it is a warning that the vulnerability discovery landscape has permanently changed.
Every team that processes media — and that is nearly every team — needs to reassess their assumptions about the security of their media processing infrastructure. The bugs that have been hiding for 23 years in FFmpeg are almost certainly not unique. Similar vulnerabilities are waiting in ImageMagick, libavcodec forks, GStreamer, and countless other media libraries that teams deploy and forget.
The question is not whether your media processing stack has vulnerabilities. It is whether you will find them before someone else does.
If your team needs help auditing your media processing infrastructure, integrating AI-powered security tooling into your pipeline, or building sandboxed processing architectures, get in touch. This is exactly the kind of deep infrastructure work our team specialises in.
📷 Photo by Markus Spiske on Unsplash
