21 FFmpeg zero-days expose media systems to remote code execution risk

Security researchers have disclosed 21 previously unknown vulnerabilities in FFmpeg, including a network-reachable memory corruption flaw that can demonstrate remote code execution control in some RTSP and RTP processing scenarios.

The findings were published by Depthfirst in a technical report on 21 FFmpeg zero-days. The company said its autonomous security agent found the bugs in FFmpeg after analyzing the project’s media parsers, demuxers, codecs, and protocol handlers.

FFmpeg matters because it powers media processing across browsers, streaming services, cloud transcoding systems, surveillance tools, video platforms, and many backend pipelines. A flaw in FFmpeg can affect far more than users who run the command-line tool directly.

FFmpeg bugs affect demuxers, codecs, and network parsers

The 21 findings span several FFmpeg components, including the TS demuxer, swscale, ffmpeg option parsing, yuv4mpegenc, the VP9 decoder, the DASH demuxer, RTP depacketizers, RTSP handling, RTMP client code, AVI parsing, CAF parsing, and AVIF-related paths.

Depthfirst said the agent produced reproducible inputs to confirm the issues, rather than only reporting theoretical code patterns. That point matters because the official FFmpeg security page warns that the project has seen a spike in AI-generated false positives and asks reporters to provide careful verification and easy-to-use test cases.

The company said nine of the 21 findings have CVE identifiers so far. The remaining issues were described with internal Depthfirst tracking IDs while CVE assignment remains pending.

CVE	Component	Issue type	Notes
CVE-2026-39210	TS demuxer	Heap buffer overflow	Depthfirst says the bug dates back to 2010.
CVE-2026-39211	swscale	Integer overflow	Linked to size calculations during scaling.
CVE-2026-39212	ffmpeg_opt.c	Stack overflow	Reported as a July 2025 regression.
CVE-2026-39213	yuv4mpegenc	Heap buffer overflow	Linked to dimension validation in a rawvideo path.
CVE-2026-39214	SDT implementation	Stack buffer overflow	Depthfirst says it dates back to 2003.
CVE-2026-39215	update_mb_info()	Heap buffer overflow	Linked to macroblock information handling.
CVE-2026-39216	img2enc.c	Heap buffer overflow	Reported in image output handling.
CVE-2026-39217	VP9 decoder	Heap buffer overflow	Reported as a March 2025 regression.
CVE-2026-39218	DASH demuxer	Heap buffer overflow	Linked to negative duration handling.

One AV1-over-RTP flaw stands out

The most serious public example involves FFmpeg’s AV1 RTP depacketizer. Depthfirst tracks this issue as DFVULN-127 and describes it as a heap buffer overflow in libavformat/rtpdec_av1.c.

The issue can be reached when FFmpeg processes an attacker-controlled RTSP stream carrying AV1 over RTP. According to the Depthfirst FFmpeg research, a single small RTP packet was enough in its proof of concept to redirect execution during normal stream handling.

The report said no authentication, special command-line flags, or extra user interaction were required beyond opening the stream. This makes the bug especially relevant to automated media systems that fetch remote RTSP streams from user-provided or third-party sources.

• Media ingest platforms may process streams submitted by users or partners.
• CCTV and surveillance systems often pull RTSP feeds from cameras and recorders.
• Cloud transcoding services may automatically process remote video sources.
• Security products and analysis sandboxes may inspect untrusted media streams.
• Applications that bundle FFmpeg may inherit risk even when users never install FFmpeg directly.

Why the findings matter for defenders

FFmpeg has been fuzzed and audited for many years, but the new findings show that old memory-safety bugs can still remain in complex media code. Some issues described by Depthfirst date back more than a decade, while others were introduced in recent regressions.

Anthropic also discussed AI-assisted vulnerability discovery in its Claude Mythos Preview security analysis, which included FFmpeg as one of the open-source projects where its model found security issues. Depthfirst’s work adds another public example of autonomous tools finding confirmed bugs in heavily reviewed C code.

For defenders, the main risk comes from systems that process untrusted media automatically. A desktop user opening a random media file is one scenario, but server-side ingestion, live stream processing, and surveillance pipelines create a larger enterprise exposure surface.

Environment	Why it may be exposed	Priority
Cloud media processing	Processes uploaded or remote video at scale.	High
RTSP ingest services	May connect to attacker-controlled streams.	High
CCTV and surveillance platforms	Often rely on automated RTSP feed collection.	High
Desktop media tools	May open untrusted media files or links.	Medium
Internal transcoding jobs	Risk depends on whether sources are trusted.	Variable

Admins should check FFmpeg exposure now

Organizations should first identify where FFmpeg runs. This includes servers, containers, CI pipelines, video processing workers, desktop apps, security tools, browser-adjacent workflows, and third-party products that bundle FFmpeg libraries.

Teams should then identify which systems process untrusted files, remote URLs, RTSP streams, RTP traffic, DASH inputs, AV1 video, VP9 video, or other formats named in the disclosure. These systems deserve priority because they place attacker-controlled input directly in front of vulnerable parser code.

The official FFmpeg download page lists current upstream releases, but many organizations receive FFmpeg through Linux distributions, containers, appliance firmware, or application vendors. Admins should check vendor advisories as well as upstream FFmpeg updates.

Practical mitigation steps

Where possible, organizations should update FFmpeg to a build that includes the relevant fixes once their vendor or package maintainer ships them. For systems that process untrusted remote streams, teams should also consider temporary network and input restrictions until patched builds are confirmed.

Security teams should avoid treating FFmpeg as a simple utility. It often acts as a parser for attacker-controlled data, which means it belongs in software inventories, vulnerability management workflows, and container image scans.

The FFmpeg vulnerability reporting guidance also highlights the need for reproducible test cases, which matters for internal triage. If an organization receives alerts about these issues from scanners or vendors, it should confirm the affected component and reachable attack path before prioritizing emergency changes.

• Inventory all FFmpeg binaries and linked libraries across servers, containers, and products.
• Prioritize systems that process untrusted media or remote streams.
• Restrict RTSP and RTP inputs to trusted sources where possible.
• Disable or isolate unnecessary media processing features in exposed services.
• Apply vendor-provided FFmpeg updates as they become available.
• Monitor crash logs, abnormal worker restarts, and suspicious media ingestion failures.
• Sandbox media processing jobs to reduce the impact of memory corruption.

AI-assisted vulnerability discovery is accelerating

The FFmpeg findings also show how fast vulnerability discovery is changing. Depthfirst said its autonomous agent found the 21 issues at a cost of about $1,000, while earlier work by other research teams showed that advanced models can help find security bugs in real open-source projects.

Anthropic’s Project Glasswing discussion warned that only a small share of its discovered vulnerabilities had been patched at the time of publication. That gap between finding bugs and fixing them creates pressure for maintainers, vendors, and enterprise security teams.

For companies that depend on FFmpeg, the safest response is to reduce unnecessary exposure, speed up patch validation, and track updates from upstream and operating system vendors. The official FFmpeg release page should be part of that monitoring process, but packaged deployments should still follow their own vendor’s update channel.

FAQ