# Twenty One Zero-Days in FFmpeg > Source: > Published: 2026-06-12 22:13:29+00:00 # 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).