Twenty One Zero-Days in FFmpeg

Depthfirst's autonomous security agent discovered 21 zero-day vulnerabilities in FFmpeg, a widely used media processing library, after recent security analyses by Google and Anthropic. The agent produced reproducible proof-of-concept inputs at a fraction of the cost ($1k vs. $10k), with some bugs latent for 15-20 years, and demonstrated a remote code execution exploit primitive.

21 Zero-Days in FFmpeg TLDR: depthfirst’s production autonomous security agent discovered 21 zero-day vulnerabilities in FFmpeg, after intensive security analysis by Google and Anthropic. Moving beyond theoretical analysis, our agent produces concrete, reproducible PoC inputs to confirm its findings at a fraction of the costs $1k vs. $10k . Several of the findings had been sitting latent for 15 to 20 years. We explored the exploitability of the issues and developed a PoC demonstrating a RCE exploit primitive. FFmpeg is one of the most widely deployed pieces of software in the world. From the browsers we use daily to the infrastructure powering the large streaming platforms, it quietly processes media everywhere. As a library that routinely parses complex, untrusted media, it is inherently security critical and a prime target for zero-click attacks. Looking deeper into FFmpeg’s repository reveals the true scale of the challenge: it is massive, comprising roughly 1.5 million lines of heavily optimized C code dedicated to parsing hundreds of complex media formats. Furthermore, it has absorbed over two decades of relentless fuzzing and manual audits. Recently, Google’s Big Sleep team disclosed 13 vulnerabilities in FFmpeg https://goo.gle/bigsleep . Soon after, Anthropic used their Mythos model to scan FFmpeg and successfully discovered some security issues https://red.anthropic.com/2026/mythos-preview/ . These milestones demonstrated that advanced models are increasingly capable of reasoning through dense, hardened C code. With these recent efforts, finding vulnerabilities in FFmpeg is getting much harder. At depthfirst, we built an agentic system that can do deep scans over large codebases. Finding bugs here is a measure of our security system’s capability. While we don’t have access to Mythos, we wanted to know how far we can go just using the models that are available to us. Can we re-discover what Big Sleep and Mythos have found? And more importantly, can we find any new critical bugs that they completely missed? Depthfirst’s Security Agent A coding agent and a security agent may use the same underlying models, but they operate with very different objectives. A coding agent is usually interactive: a human gives it a task, and the goal is to write code, rather than focusing on edge cases and adversarial inputs. A security agent has a narrower and more targeted goal. It is not trying to write useful application code, but trying to find real, exploitable security issues in an existing system without specific instructions. That changes the shape of the agent. A security agent has to begin by threat modeling the codebase: understanding its architecture, identifying exposed parsers and protocol handlers, and mapping where attacker-controlled input can enter the system. From there, it audits the attack surface code directly, following data flow through the relevant components instead of treating the repository as a flat collection of files. In addition, a practical security agent needs guardrails that prevent it from fabricating missing conditions, over-claiming theoretical bugs, or flooding with false positives. It must check whether the attacker actually controls the right input, whether the vulnerable path is reachable, and whether the suspected flaw can be reproduced. When needed, it should identify or generate appropriate harnesses to interact with the target components and test those hypotheses concretely. At depthfirst, our specialized security agents deeply analyze the code, branching out in parallel to test various hypotheses. They trace execution paths, validate whether an attacker controls the right inputs, and determine if the data flow actually reaches a vulnerable sink. Crucially, the outcome of this process isn’t just a theoretical report or a vague warning. The system automatically pinpoints the exact security issue with a reproducible concrete input, confirming the vulnerability by execution. This ensures that every finding delivered is real, reachable, and actionable. The Findings In total, our agents discovered 21 zero-days, spanning components from the TS demuxer to the VP9 decoder, with a total cost of roughly $1k 10% of what Anthropic spent using Mythos https://red.anthropic.com/2026/mythos-preview/ . Eight of the issues have already been assigned CVEs: CVE-2026-39210 Heap Buffer Overflow : Introduced in 2010 in the TS demuxer, lacking length bounds checks before reading two bytes. CVE-2026-39211 Integer Overflow : Introduced in 2010 during a swscale refactor, via a size factor formula with no upper bounds that allowed user-controlled parameters to trigger arbitrarily large scaling. CVE-2026-39212 Stack Overflow : A recent regression from July 2025 inside ffmpeg opt.c , where a preset file could trigger option parsing recursively without a depth limit. CVE-2026-39213 Heap Buffer Overflow : Introduced in 2023 in the yuv4mpegenc rawvideo input path without validating dimensions against packet size. CVE-2026-39214 Stack Buffer Overflow : Introduced in 2003 during the original SDT implementation, this bug writes service entries without tracking remaining space. It sat latent for 23 years. CVE-2026-39215 Heap Buffer Overflow : Introduced in 2012 inside update mb info , where a logic error allows a subsequent call to write 12 bytes past the allocated buffer. CVE-2026-39216 Heap Buffer Overflow : Introduced in 2012 in img2enc.c due to replacing a safe chroma size with an unbounded dimension-derived size. CVE-2026-39217 Heap Buffer Overflow : A recent regression from March 2025 in the VP9 decoder, where a refactored size update function caused tile thread buffers to miss necessary reallocations. CVE-2026-39218 Heap Buffer Overflow : Introduced in 2017 in the DASH demuxer by failing to reject negative duration values, turning fragment array indices negative. The remaining issues are fixed, but we do not have CVE identifiers assigned yet. We reference them here by our internal tracking IDs: DFVULN-127 Heap Buffer Overflow : In the RTP AV1 depacketizer rtpdec av1.c , av1 handle packet advances the output write position by obu size when skipping a Temporal Delimiter OBU without allocating matching space, so the next OBU is written well past the buffer boundary. The flaw has been present since the AV1 RTP depacketizer was first added in 2024. DFVULN-126 Heap Buffer Overflow : In the swscale graph code graph.c , run legacy unscaled mishandles interlaced YUV420P→NV12 conversion: get field doubles the plane linestrides, causing ff copyPlane ’s contiguous memcpy to overflow the destination Y-plane by 576 bytes. Introduced in 2024 with swscale’s new dynamic scaling API. DFVULN-125 Stack Buffer Overflow : In the RTP JPEG depacketizer rtpdec jpeg.c , jpeg create header builds a quantization-table section in a 1024-byte stack buffer; a crafted packet with qtable len = 1024 fills it completely, then a trailing AV WB16 writes two bytes past the end. A 2012 regression is to blame: days after the JPEG depacketizer landed, a refactor replaced the clamped table count with an unbounded qtable len / 64 , allowing enough quantization tables to overrun the fixed buffer. DFVULN-124 Heap Buffer Overflow : In the AVIF overlay path ffmpeg demux.c , istg parse tile grid fails to reject a dimg reference with zero tile entries; an unsigned wraparound then drives an out-of-bounds read on a one-byte heap allocation. Introduced in 2025 when automatic HEIF tile merging was added. 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, letting memcpy read roughly 1 GB past the end of a heap buffer. Present since the MP4A-LATM depacketizer was added in 2010. DFVULN-122 Heap Buffer Overflow : In the RTP MPEG-4 depacketizer rtpdec mpeg4.c , aac parse packet accepts an AU-headers-length of 0, which yields a one-byte allocation that is then read as a four-byte field without checking that any AU headers are present. Present since MPEG4-AAC RTP support was added in 2005 — the oldest of the set, latent for over two decades. DFVULN-121 Heap Buffer Underflow : In the CAF demuxer cafdec.c , read seek uses the return value of av index search timestamp directly as an array index without checking for -1; a crafted file makes all index timestamps negative, so a seek indexes index entries -1 . Present since the CAF demuxer was added in 2009. DFVULN-120 Integer Underflow : In the AVI demuxer avidec.c , ff read riff info is called with size - 4 without verifying size = 4 ; a LIST chunk of size 0 underflows to ~4 GB, bypassing bounds checks and triggering a ~2 GB allocation DoS . Introduced in 2011 when RIFF INFO-tag parsing was generalized, replacing a bounded call with the underflow-prone size - 4 . DFVULN-119 Heap Buffer Overflow : In the option parser ffmpeg opt.c , opt map contains a stray increment that misparses a link-label as a file index and stores a stream index of -1; the subsequent negative-map loop then reads before the AVStream array. A 2025 regression, introduced when stream-group matching helpers extended -map parsing. DFVULN-118 Heap Buffer Overflow : In the RTSP server path rtspdec.c , rtsp read announce treats a negative Content-Length as valid; a remote ANNOUNCE with Content-Length: -1 causes an out-of-bounds write at sdp -1 . A 2021 regression that removed the hardcoded SDP size cap and dropped the upper-bound check along with it. DFVULN-117 Heap Buffer Overflow : In the RTMP client rtmpproto.c , rtmp calc swfhash checks in size < 3 instead of in size < 8 , allowing memcpy to read eight bytes from a buffer allocated with as few as three. Present since automatic SWFVerification hashing was added in 2012. DFVULN-116 Heap Buffer Overflow : In RTSP SDP parsing rtsp.c , sdp parse line computes strlen control url - 1 on an empty string, wrapping a size t to SIZE MAX and producing a one-byte pre-buffer read. Present since SDP control-URI handling was added in 2010. Finding a bug is one thing; proving it is exploitable is another. To truly understand the power of our system, we need to look at one specific bug and how it was found. From a Skipped Frame Marker to PC Control Among the 21 findings, one stood out: a heap buffer overflow in FFmpeg’s AV1 RTP depacketizer libavformat/rtpdec av1.c . It is reachable from the network with no special flags. A victim only has to run ffmpeg -i rtsp://attacker/stream , the most ordinary command imaginable, and a single 183-byte packet is enough to redirect execution. To understand it, we first need a little background on how AV1 video travels over RTP. When FFmpeg pulls an RTSP stream, the server delivers the encoded video as a sequence of RTP packets. AV1 organizes its bitstream into OBUs Open Bitstream Units . The RTP payload format splits these OBUs across packets, and FFmpeg’s depacketizer is responsible for stitching them back into a clean elementary stream. One special OBU type is the Temporal Delimiter TD , a tiny marker that separates one temporal unit frame from the next. The spec explicitly tells the depacketizer to “ignore and remove” any TD it sees in the payload. That innocent-looking “ignore and remove” is exactly where things go wrong, and exactly where our agent zeroed in. The Root Cause The depacketizer builds its output packet incrementally. A cursor named pktpos tracks where the next byte will be written into pkt- data , and it starts at the current end of the packet: php // libavformat/rtpdec av1.c:199 pktpos = pkt- size; As the code loops over the OBU elements in a packet, every byte it actually emits is preceded by a matching call to av grow packet , which enlarges the heap allocation backing pkt- data . The invariant the whole routine depends on is simple: pktpos must never run ahead of the allocated size of pkt- data . The Temporal Delimiter handling breaks that invariant: // libavformat/rtpdec av1.c:250 if obu type == AV1 OBU TEMPORAL DELIMITER || obu type == AV1 OBU TILE LIST { pktpos += obu size; // advance the output cursor... rem pkt size -= obu size; // ...and the input counter obu cnt++; continue; // but never allocate, and never advance buf ptr } When a TD is skipped, pktpos is pushed forward by the attacker-declared obu size , yet no memory is allocated to back that advance. Worse, the input pointer buf ptr is not moved past the TD’s bytes. Two distinct problems fall out of this single continue : The write cursor is now poisoned. After skipping a TD with obu size = 148 , pktpos equals 148, but pkt- data is still unallocated or far smaller than 148 bytes . The attacker controls what gets written there. Because buf ptr never advanced, the next loop iteration re-parses the TD’s own bytes — its header byte is re-read as a fresh OBU length, and its payload becomes that fabricated OBU’s contents. The data that will eventually land at the poisoned offset is fully attacker-supplied. On the next iteration the loop reaches a normal OBU and grows the packet by just that OBU’s size: // libavformat/rtpdec av1.c:296 if result = av grow packet pkt, output size < 0 return result; ... // libavformat/rtpdec av1.c:304 / 336 — writes begin at pkt- data pktpos pkt- data pktpos++ = buf ptr++ | AV1F OBU HAS SIZE FIELD; ... memcpy pkt- data + pktpos, buf ptr, obu payload size ; With a fabricated OBU of 17 bytes, av grow packet allocates an 81-byte buffer 17 bytes plus FFmpeg’s 64-byte input padding . But the writes begin at pkt- data 148 , which is 67 bytes past the end of the allocation. This is a heap buffer overflow with a fully controlled offset and fully controlled contents, which is about as strong a primitive as a memory-corruption bug can offer. Exploitation A controlled overflow is only useful if there is something worth corrupting just past the buffer. Here, FFmpeg’s own allocator hands us a perfect target. When av grow packet allocates the packet’s data buffer, it routes through av buffer alloc , which performs three sequential heap allocations: the data buffer itself, an AVBuffer bookkeeping struct, and an AVBufferRef . Because FFmpeg allocates everything through posix memalign with 64-byte alignment, our 81-byte data buffer occupies a 128-byte chunk, and the AVBuffer struct lands immediately after it. That struct contains a function pointer: // libavutil/buffer internal.h struct AVBuffer { uint8 t data; // +0 size t size; // +8 atomic uint refcount; // +16 4 bytes + 4 padding void free void opaque, uint8 t data ; // +24 ← target void opaque; // +32 ... }; Counting from the start of the data buffer, the AVBuffer.free pointer sits at offset 152 . This is the callback FFmpeg invokes to release the buffer’s memory — and it is exactly what we aim the overflow at. The arithmetic is deliberately tuned. With the TD’s obu size = 148 , writes start at pkt- data 148 . The TD header byte 0x10 is re-interpreted as a length of 16, producing a fabricated 16-byte OBU whose header and payload are written starting at offset 148: // libavutil/buffer internal.h struct AVBuffer { uint8 t data; // +0 size t size; // +8 atomic uint refcount; // +16 4 bytes + 4 padding void free void opaque, uint8 t data ; // +24 ← target void opaque; // +32 ... }; There is one subtlety that makes the whole thing reliable: AVBuffer.refcount lives at offset 144–147, below where our writes begin at 148. The overflow corrupts free while leaving refcount untouched at its original value of 1 . That matters for the trigger. To actually fire the hijacked pointer, the packet needs to be freed. The exploit embeds a third fabricated OBU in the TD payload, which drives one more av grow packet . Because the buffer was created with av buffer alloc rather than av buffer realloc , it is not flagged as reallocatable, so FFmpeg takes the “allocate a fresh buffer and release the old one” path: php // libavutil/buffer.c:209 if buf- buffer- flags internal & BUFFER FLAG REALLOCATABLE || ... { ret = av buffer realloc &new, size ; // fresh buffer memcpy new- data, buf- data, ... ; // copy data across buffer replace pbuf, &new ; // release the old, corrupted buffer return 0; } buffer replace decrements the old buffer’s refcount, which we carefully left at 1 , to 0 , and invokes the freeing callback: php // libavutil/buffer.c:129 if atomic fetch sub explicit &b- refcount, 1, memory order acq rel == 1 { b- free b- opaque, b- data ; // b- free is now 0xdeadbeef } At this point the corrupted free pointer is called, and control of the instruction pointer is ours. On a release build, the single 183-byte RTP packet produces: 0 0x00000000deadbeef in ?? rip 0xdeadbeef 0xdeadbeef 1 buffer replace buffer.c:133 ← b- free b- opaque, b- data 2 av buffer realloc buffer.c:220 3 av grow packet packet.c:151 4 av1 handle packet rtpdec av1.c:296 5 rtp parse packet internal rtpdec.c:743 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. No authentication, no user interaction beyond opening the stream, and no unusual command-line flags are required — the vulnerability triggers during the normal RTSP PLAY phase that every one of these clients performs by design.You may find the PoC code here https://github.com/DepthFirstDisclosures/ffmpeg-dfvuln127 .