21 Zero-Days in FFmpeg | depthfirst

Open Original Page

21 Zero-Days in FFmpeg | depthfirst

Read about the Open Defense Initiative depthfirst Product Customers Research Company Sign in Request demo

Platform Your autonomous security command center

Code Find vulnerabilities scanners were never built to see

Supply chain Know what's reachable, not just what's present

Secrets Stop leaks before they leave the repo

Agentic Pentesting Find vulnerabilities in code that's already running

Dependency Firewall Detect malicious behavior before it spreads through your environment

About Learn how we help teams uncover threats before attackers do

Careers We're growing the team

Blog Insights, research, and security trends from our team

Events Join us at conferences, webinars, and live security sessions

depthfirst Open navigation

Product Platform Your autonomous security command center Code Find vulnerabilities scanners were never built to see Supply chain Know what's reachable, not just what's present Secrets Stop leaks before they leave the repo Agentic Pentesting Find vulnerabilities in code that's already running Dependency Firewall Detect malicious behavior before it spreads through your environment

Customers Research Company About Learn how we help teams uncover threats before attackers do Careers We're growing the team Blog Insights, research, and security trends from our team Events Join us at conferences, webinars, and live security sessions

Sign in Request demo

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. Soon after, Anthropic used their Mythos model to scan FFmpeg and successfully discovered some security issues. 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.

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). 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 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:

// 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.

Links

Browse another page: