21 FFmpeg Zero-Days, 429 Chrome Bugs: The AI Bug-Hunting Era Arrived

The week the throughput changed

Two data points landed close together and they tell the same story. An AI agent — an LLM driving fuzzing harnesses and triage instead of a human writing them by hand — surfaced 21 zero-days in FFmpeg's parsing code. Around the same window, Chrome closed out a record year of patched bugs north of 429, the bulk of them memory-safety issues in Blink and V8 found by fuzzers and the bug bounty pipeline.

Neither number is shocking on its own. FFmpeg has been a memory-corruption pinata for fifteen years, and Chrome is the most heavily fuzzed C++ codebase on the planet. What changed is the cost curve. Writing a good FFmpeg fuzz harness for an obscure demuxer used to be a weekend of work for someone who already knew the codebase. An agent now does the boring 80% — read the parser, infer the input grammar, generate a harness, wire it to ASan, triage the crashes — and a human only adjudicates the interesting 20%. When the marginal cost of pointing a fuzzer at a new code path drops toward zero, every under-fuzzed corner of every C codebase becomes reachable.

If FFmpeg touches your stack — and it almost certainly does, through transcoding, thumbnailing, media preview, or some transitive libav* dependency you forgot about — the question isn't whether more bugs exist. It's whether you've architected as if they do.

Why FFmpeg is the perfect target

FFmpeg is the worst-case combination of attributes for an AI bug hunter, and the best-case combination for a defender to lose sleep over:

• Enormous parsing surface. Hundreds of demuxers and decoders, most written in C, most handling fully attacker-controlled bytes. A single ffmpeg -i evil.mkv out.mp4 invocation can dispatch into thousands of lines of format-specific parsing.
• Repetitive, pattern-dense code. Decoders look alike. An integer-overflow-into-undersized-allocation bug in one codec is a template for finding the same bug in twelve others. LLMs are very good at "find me more code that looks like this known-bad pattern."
• A ready-made crash oracle. OSS-Fuzz already provides corpora, ASan/UBSan builds, and a clean signal: sanitizer abort = bug. The agent doesn't have to reason about whether a crash is exploitable to know it found something.
• Deep, dusty corners. The mainstream H.264/AAC paths are fuzzed to death. The long tail — ancient game-console video formats, niche subtitle parsers, exotic image codecs — is where the 21 live. Humans never prioritized harnesses for bink or vmd or some 1998-era FMV container. An agent doesn't get bored.

The bug classes are the usual suspects, and they matter for how you defend:

• Heap buffer overflow in decoders — a frame header lies about dimensions, the decode loop writes past the allocation.
• Out-of-bounds read in demuxers — a chunk-size field points past EOF, the parser reads attacker-influenced adjacent memory (info leak, or crash).
• Integer overflow → undersized allocation — width * height * bpp wraps, you malloc a tiny buffer and then fill it as if it were huge.
• Use-after-free in codec state — error paths free context that a later frame still references. These are the ones that turn into RCE.

What the AI actually does (and doesn't)

Strip the hype and the workflow is mechanical:

1. Reachability + grammar inference. The agent reads the demuxer/decoder source, identifies the entry point that consumes untrusted input, and infers enough of the file-format structure to generate inputs that get past the early sanity checks. This is the step that historically gated coverage — most dumb fuzzers die at the magic-byte check.
2. Harness synthesis. It writes a LLVMFuzzerTestOneInput-style harness targeting that specific path, links it against an ASan build.
3. Run, triage, dedupe. Crashes get bucketed by stack hash, minimized, and classified — OOB read vs write, controllable offset, reachable from a normal ffmpeg CLI invocation or only via the library API.
4. Human adjudication. A person confirms exploitability and severity and files upstream.

What it doesn't do well — yet — is novel architectural reasoning or weaponization into a reliable exploit chain. The 21 are bugs, not 21 turnkey RCEs. But "crash in a media parser that processes user uploads" is exactly the input you must treat as exploitable until proven otherwise.

The Chrome 429 number is the same dynamic from the reporter side: more automated discovery, a mature bounty program paying for it, and a vendor that — to its credit — counts and ships fixes at a cadence most projects can't match. High patch volume in a transparent project is a sign of health, not rot. The projects to fear are the ones with low CVE counts because nobody is looking.

Defense playbook

You cannot out-patch an AI fuzzer. You can make a memory-corruption bug in a media parser a non-event. Architect for containment, not for the absence of bugs.

1. Find every copy of FFmpeg you ship

It hides in transitive dependencies, language bindings, and base images.

# Binaries and shared libs on a host/image
find / -type f \( -name 'ffmpeg' -o -name 'ffprobe' -o -name 'libav*.so*' \) 2>/dev/null

# Pull the version + build config so you know what's compiled in
ffmpeg -hide_banner -buildconf

# Hunt the dependency trees
grep -rEi 'ffmpeg|libav|fluent-ffmpeg|imageio-ffmpeg|av\b' package-lock.json go.sum requirements*.txt Gemfile.lock 2>/dev/null

2. Build the smallest FFmpeg that does your job

The single highest-leverage move. If you only ingest MP4/H.264/AAC, you do not need the subtitle parser from 2003. Disable everything, re-enable the minimum, and you delete most of the attack surface the agents are mining.

./configure \
  --disable-everything \
  --disable-network \
  --disable-doc \
  --enable-demuxer=mov,mp4,matroska \
  --enable-decoder=h264,aac,vp9,opus \
  --enable-protocol=file \
  --enable-parser=h264,aac

3. Lock the runtime down even when you can't rebuild

The stock binary autodetects formats and speaks network protocols. Constrain it per-invocation:

ffmpeg -nostdin \
  -protocol_whitelist file \
  -f mp4 \                    # force the demuxer; don't let it probe
  -i input.mp4 \
  -t 600 -fs 100M \           # cap duration and output size
  output.webm

Never pass attacker-controlled bytes to a binary that can open http://, concat:, subfile:, or file: references. Server-Side Request Forgery via FFmpeg protocol handlers is a classic and it predates any of this AI tooling.

4. Sandbox the transcoder like it will be popped

Assume the parser falls. Make that the end of the story, not the beginning.

• Run each transcode in a disposable, network-less sandbox: gVisor, Firecracker microVM, or at minimum a locked container.
• Drop every capability, read-only root FS, dedicated non-root UID, no host mounts beyond the single input and output path.
• Enforce hard resource limits so a wrap-into-huge-alloc bug is a killed job, not an OOM cascade.

docker run --rm \
  --network none \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 64 \
  --memory 512m --memory-swap 512m \
  --cpus 1 \
  -v "$PWD/in:/in:ro" -v "$PWD/out:/out" \
  transcoder:minimal \
  ffmpeg -nostdin -protocol_whitelist file -i /in/job.mp4 /out/job.webm

Layer a seccomp profile that whitelists only the syscalls a transcode needs (read/write/mmap/futex/...) and blocks execve, socket, ptrace. A heap overflow that can't execve or open a socket is dramatically less useful to an attacker.

5. Fuzz your own integration before the agents do it for free

If an LLM-driven fuzzer can find these, so can your CI. Run a minimized ASan/UBSan build against your actual ingest path with a representative corpus.

# ASan + UBSan build for your worker, then drive it with your real harness/corpus
export CFLAGS="-fsanitize=address,undefined -g -O1"
# Reproduce a reported crash locally:
ASAN_OPTIONS=detect_leaks=1:abort_on_error=1 \
  ./ffmpeg -nostdin -protocol_whitelist file -i crash-input.bin -f null -

6. Detect the crashes you didn't prevent

Your transcoder workers crashing is a security signal, not just an SRE one.

# Alert when media workers segfault or get sanitizer-aborted in prod/canary
- alert: TranscoderAbnormalExit
  expr: increase(transcoder_worker_exit_code{code!="0"}[10m]) > 5
  labels: { severity: page }
  annotations:
    summary: "Media worker abnormal exits — possible malicious upload"

Falco/auditd rule of thumb to watch for from inside a transcode sandbox: any execve other than the expected ffmpeg process, any outbound connect, or any write outside the designated output dir. In a correctly built sandbox these should be impossible; seeing one means your containment assumptions are wrong.

Key takeaways

• The cost of finding bugs in C parsers just collapsed. Treat every untrusted-media code path as having latent memory-corruption bugs you don't know about yet. Plan for containment, not for clean code.
• FFmpeg's long tail is the target. The obscure demuxers and decoders nobody fuzzed are exactly what agents now reach. --disable-everything and re-enable the minimum — it's the cheapest, biggest win.
• A bug is not an exploit, but a media parser is the wrong place to bet otherwise. Crash-in-upload-handler is a page, not a backlog ticket.
• High patch counts signal scrutiny, not weakness. Chrome's 429 is what a healthy, heavily-fuzzed project looks like. Be more worried about your dependencies with suspiciously quiet CVE histories.
• Sandbox + seccomp + no network turns RCE into a killed job. This is the control that doesn't depend on you winning the patch race.

TL;DR

An AI agent found 21 zero-days in FFmpeg by cheaply harnessing the under-fuzzed long tail of demuxers and decoders; Chrome's record 429-bug year is the same automation trend from the reporter side. You won't out-patch this. Inventory every FFmpeg/libav* in your stack, rebuild with --disable-everything plus only the codecs you need, force the demuxer and whitelist file protocol per-invocation, and run each transcode in a network-less, capability-dropped, seccomp-confined, resource-limited sandbox. Fuzz your own ingest path with ASan in CI, and alert on worker crashes as a security event. Make a parser bug a dead job instead of a foothold.