A security startup called depthfirst pointed an autonomous AI agent at FFmpeg — the media library buried inside almost everything that touches video — and came back with 21 confirmed zero-days, each with a reproducible proof-of-concept input. The agent scanned roughly 1.5 million lines of C. The company puts the cost of the entire run at around $1,000.

That price tag is the headline, but the relevant detail for infrastructure teams is where these bugs live and how many places FFmpeg is quietly running.

What was found

Most of the 21 issues are heap or stack overflows in parsers and demuxers — the code paths that crack open a container or stream before anything gets decoded. The reported components span the MPEG-TS demuxer through the VP9 decoder. Several had been latent for 15 to 20 years. One stack overflow in the service-description-table code dates to 2003 and sat untouched for 23 years.

Nine of the bugs already carry identifiers: CVE-2026-39210 through CVE-2026-39218. depthfirst says the remainder are fixed upstream but not yet numbered, and it has published proof-of-concept inputs alongside the writeup.

Why this is an infrastructure problem, not a desktop one

FFmpeg is not just a command-line tool people use to re-encode movies. It is a dependency. It ships inside transcoding services and CDNs, gets statically linked into appliances and IoT firmware, and rides along in Python wheels (av, imageio-ffmpeg, moviepy, many OpenCV builds), Node modules, Electron apps, and a large fraction of container base images that do anything with media.

Memory-corruption bugs in demuxers matter because the attacker controls the input. A crafted file or stream hits a parser before any authentication or validation logic you wrote ever runs. If you accept user-uploaded media and transcode it server-side, that decode is happening in a process on your infrastructure, on bytes a stranger chose. The practical worst case is the service that ingests untrusted RTSP or AV1-over-RTP, where the data is remote and live.

This is now a pattern

The FFmpeg haul is the latest in a fast-moving run of machine-found bugs. Google’s Big Sleep agent reported a batch of FFmpeg issues last year (tagged BIGSLEEP on the project’s security page). Anthropic’s Mythos model pulled a 16-year-old H.264 flaw and others out of FFmpeg for about $10,000, three of which shipped fixed in FFmpeg 8.1. Days ago a separate autonomous tool surfaced a two-year-old authenticated RCE in Redis, present since 7.2.0. A February study had an agent reproduce working PoCs for more than half of 100 real Linux kernel N-day bugs — beating fuzzing.

The economics have flipped. Finding bugs has gotten cheap. Triaging the reports, shipping the fixes, and getting them installed has not, and much of that work still lands on volunteer maintainers and a thin layer of human triagers. Defenders should assume the discovery rate against everything they run goes up from here.

What to do right now

Pull the fixed upstream FFmpeg build, or your distribution’s security update, as soon as it lands. Then keep going — the system package is the easy part.

Inventory your embedded copies. Container images, Python wheels (av, imageio-ffmpeg, moviepy), bundled desktop apps, and appliances all carry their own FFmpeg and will not be fixed by an apt upgrade on the host. Bump and rebuild them.

Prioritize anything that ingests untrusted RTSP or AV1-over-RTP, and any pipeline that transcodes user-uploaded media. Where you decode untrusted input, sandbox the worker: seccomp, an isolated low-privilege process, dropped capabilities, and hard memory limits turn a parser overflow into a contained crash instead of a foothold.

Finally, treat dependency bumps that carry CVE fixes as security work with a real SLA, not routine maintenance to be batched later. The pace of disclosure is being set by machines now; the patch cycle has to move to match it.

References