FFmpeg: ein autonomer KI-Agent findet 21 Zero-Days (CVE-2026-39210–39218) — ein 183-Byte-RTSP-Paket reicht für RCE

TL;DR — 90 Sekunden

Betroffen?

Jede Umgebung, die FFmpeg gegen attacker-beeinflussbare Eingaben laufen lässt — besonders Media-Ingest, das user-gelieferte Stream-URLs zieht, Transcoding-Dienste, CCTV-/Surveillance-Clients über RTSP, sowie die unzähligen eingebetteten FFmpeg-Kopien in Container-Images, Python-Wheels und Appliances (nicht nur das System-Paket).

Risiko?

Heap-/Stack-Overflows in Parsern und Demuxern (TS-Demuxer bis VP9-Decoder). Mindestens ein Fund (AV1-RTP-Depacketizer) ist von depthfirst zu einem RCE-Primitiv mit kontrolliertem Instruction-Pointer ausgearbeitet — netzwerkerreichbar, ohne Auth, ein 183-Byte-Paket.

Sofortmassnahme?

Upstream-Fix bzw. Distributions-Security-Update einspielen, sobald verfügbar; eingebettete FFmpeg-Kopien in Images/Wheels/Appliances mitziehen; alles priorisieren, was untrusted RTSP oder AV1-over-RTP ingestiert.

Empfehlung?

Mid-Market und Enterprise: Media-Verarbeitung als untrusted-Parsing-Fläche behandeln — sandboxen, mit Demuxer-/Protokoll-Whitelists einschränken, SBOM nach ffmpeg/libav* durchsuchen, CVE-tragende Dependency-Bumps als Security-Arbeit behandeln, nicht als Routine-Wartung.

Kritikalität?

high (referenziert das Hero-Badge — dokumentierter RCE-Primitiv mit PoC, netzwerkerreichbar; im 48h-Fenster prüfen).

Was ist das Problem?

FFmpeg ist eine der am breitesten ausgerollten Software-Komponenten der Welt: vom Browser bis zur Streaming-Infrastruktur verarbeitet sie still und überall Medien. Genau das macht sie zur Zielscheibe für Zero-Click-Angriffe — sie parst routinemässig komplexe, untrusted Medien. Und sie ist gross: rund 1,5 Mio. Zeilen hochoptimiertes C für hunderte Formate, über zwei Jahrzehnte Fuzzing und manuelle Audits inklusive. Erst kürzlich hatte Googles Big-Sleep-Team 13 Lücken gemeldet, danach zog Anthropics Mythos-Modell weitere heraus. Die These war: Hier ist das Niedrighängende abgeerntet.

Trotzdem hat depthfirsts autonomer Security-Agent in einem Lauf 21 bestätigte Zero-Days produziert — jeder mit reproduzierbarem PoC-Input, für rund 1.000 US-Dollar Rechenkosten (laut Bericht etwa 10 % dessen, was Anthropic mit Mythos ausgab). Der Unterschied zu einem Coding-Agenten ist methodisch: Ein Security-Agent betreibt zuerst Threat-Modeling über die Codebasis, identifiziert exponierte Parser und Protokoll-Handler, verfolgt Datenflüsse bis zum Sink — und verifiziert per Ausführung, statt theoretisch zu warnen. Genau das trennt einen echten Fund von „CVE-Slop“.

Ein Teil der Funde trägt bereits CVE-Nummern: depthfirst listet die fortlaufenden Kennungen CVE-2026-39210 bis CVE-2026-39218 (der Fliesstext der Quelle spricht von „acht“ zugewiesenen CVEs, die Aufzählung zeigt neun aufeinanderfolgende IDs — eine kleine Unstimmigkeit der Quelle, die wir hier so kennzeichnen statt sie aufzulösen), der Rest ist gefixt, aber noch nicht nummeriert (depthfirst trackt sie als DFVULN-1xx). Die Alters-Spanne ist das eigentlich Unbequeme: ein Stack-Overflow im SDT-Code (CVE-2026-39214) stammt aus der Original-Implementierung von 2003 und lag 23 Jahre unentdeckt; ein MPEG-4-AAC-RTP-Fund (DFVULN-122) reicht bis 2005 zurück. Hart-auditiert heisst nicht bug-frei — es heisst nur, dass die verbliebenen Bugs tiefer liegen, als menschliche Reviews und klassisches Fuzzing in vertretbarer Zeit erreichen.

Wer ist betroffen?

Wichtig zur Schwere-Einordnung: depthfirst hat einen der 21 Funde bis zum funktionierenden RCE-Primitiv ausgearbeitet und den PoC veröffentlicht. Die übrigen sind als Heap-/Stack-Overflows bzw. Integer-Over-/Underflows dokumentiert und gefixt; ob jeder einzelne zu RCE führt, ist nicht für alle ausgereizt. Die operative Annahme bleibt trotzdem: Memory-Corruption in einem netzwerkerreichbaren Parser ist ernst zu nehmen, nicht zu relativieren.

Auswirkungen

Der Kern ist die Reichweite des AV1-RTP-Fundes (libavformat/rtpdec_av1.c). AV1 organisiert seinen Bitstream in OBUs; der RTP-Payload verteilt sie über Pakete, der Depacketizer fügt sie wieder zusammen. Ein spezieller OBU-Typ, der Temporal Delimiter (TD), soll laut Spec „ignoriert und entfernt“ werden. Genau diese Stelle bricht: Beim Überspringen eines TD schiebt der Code den Schreib-Cursor pktpos um die attacker-deklarierteobu_size vor — ohne passenden Speicher zu allozieren — und bewegt den Input-Zeiger buf_ptr nicht weiter. Folge: Der Schreib-Cursor zeigt hinter die Allokation, und weil der Input-Zeiger stehen bleibt, werden die TD-Bytes in der nächsten Iteration als frischer OBU re-interpretiert — Offset und Inhalt sind voll kontrolliert.

Das ist ein Heap-Overflow mit kontrolliertem Offset und kontrolliertem Inhalt — eines der stärksten Primitive, die Memory-Corruption bietet. depthfirst zielt damit auf die AVBuffer.free-Funktionszeiger-Struktur, die FFmpegs eigener Allokator direkt hinter den Datenpuffer legt: Mit obu_size = 148 landen die Writes bei pkt->data[148], der free-Zeiger sitzt bei Offset 152, refcount bei 144–147 bleibt unangetastet auf 1. Ein dritter eingebetteter Fabricated-OBU erzwingt eine Neu-Allokation, der alte (korrumpierte) Puffer wird freigegeben — und ruft den überschriebenen free-Zeiger auf. Auf einem Release-Build genügt ein einziges 183-Byte-RTP-Paket, der Instruction Pointer steht auf dem Angreifer-Wert.

Erreichbar ist das im ganz normalen RTSP-PLAY-Ablauf — Media-Ingest mit user-gelieferten Stream-URLs, CCTV/Surveillance, Transcoding remoter AV1-over-RTP-Quellen. Kein Auth, keine Nutzerinteraktion über das Öffnen des Streams hinaus, keine ungewöhnlichen Flags. Eine CVSS-Zahl liefert die Quelle für diesen Fund nicht; die operative Schwere („remote, unauthenticated, kontrollierter IP“) rechtfertigt die high-Einordnung unabhängig vom Score. Die übrigen Funde verbreitern die Angriffsfläche über praktisch alle gängigen Demuxer/Protokolle.

Mitigation / Sofortmassnahmen

Hinweis: Die folgenden Schritte sind unsere operative Empfehlung auf Basis der von depthfirst dokumentierten Funde und der allgemeinen FFmpeg-Härtungspraxis — keine herstellerzertifizierte Anleitung. Die massgebliche Patch-Liste/Versionen sind upstream bzw. bei Ihrer Distribution abzugleichen.

Operational Decision Block

• Sofort handeln, wenn … ein Dienst FFmpeg gegen attacker-beeinflussbare Eingaben laufen lässt — insbesondere untrusted RTSP / AV1-over-RTP (der ausgearbeitete RCE-Pfad).
• Priorisiert prüfen, wenn … FFmpeg eingebettet in Container-Images, Python-Wheels oder Appliances läuft (nicht nur als System-Paket).
• Reine Awareness, wenn … FFmpeg ausschliesslich gegen vollständig vertrauenswürdige, eigene Medien arbeitet und kein Netzwerk-Protokoll-Pfad exponiert ist.

Schritt 1 — Patchen, inkl. eingebetteter Kopien

# System-Paket aktualisieren, sobald die Distribution den Fix ausliefert
apt-get update && apt-get install --only-upgrade ffmpeg libavformat* libavcodec*  # Debian/Ubuntu
# Wolfi/Alpine/Container:
apk upgrade ffmpeg

# WICHTIG: eingebettete Kopien finden, die apt/apk NICHT erreicht
pip show av imageio-ffmpeg 2>/dev/null
find / -name 'ffmpeg' -type f 2>/dev/null
find / -name 'libavcodec*' -o -name 'libavformat*' 2>/dev/null

Schritt 2 — Angriffsfläche verkleinern (bis der Fix überall liegt)

# Nur benötigte Protokolle/Demuxer zulassen (Beispiel: RTSP/RTP hart einschränken)
ffmpeg -protocol_whitelist file,crypto,data -i input.mp4 ...   # kein rtsp/rtp/http

# Wo AV1-over-RTP nicht gebraucht wird: RTSP/RTP-Ingest am Rand blocken

Schritt 3 — Untrusted-Verarbeitung isolieren

Media-Parsing als untrusted-Code behandeln:
- FFmpeg-Worker in eigenem, minimal privilegiertem Container/Namespace
- seccomp/AppArmor-Profil, kein Netzugang fuer reine Datei-Transcodes
- Ressourcen-Limits (Speicher/Zeit) gegen DoS-Funde (z. B. AVI-LIST-Underflow)
- bei RTSP-Ingest: nur erlaubte, validierte Quell-Hosts; keine user-freien URLs

Detection / Prüfung

Prüfpunkte direkt aus den dokumentierten Funden und gängiger FFmpeg-Inventarisierung abgeleitet.

FFmpeg-Inventar & Version (inkl. eingebettet)

# Versionen aller erreichbaren FFmpeg-Instanzen sammeln
ffmpeg -version | head -n1
# SBOM/Image nach ffmpeg/libav durchsuchen (Beispiel mit syft)
syft packages dir:/ -o table 2>/dev/null | grep -iE 'ffmpeg|libav(codec|format|util)'
# Container-Images scannen statt nur den Host
grype <image-ref> 2>/dev/null | grep -iE 'ffmpeg|libav'

Exponierte Protokoll-Pfade finden

# Aufrufe, die untrusted Netzwerk-Protokolle an FFmpeg geben (RTSP/RTP/HTTP)
grep -RInE "rtsp://|rtp://|-i\s+\$\{?[A-Za-z_].*url" --include=*.{sh,py,js,ts,go,php} .

# Fehlt eine Protokoll-Whitelist? (kein -protocol_whitelist gesetzt)
grep -RInE "ffmpeg" --include=*.{sh,py,js,ts,go,php} . | grep -v "protocol_whitelist"

Laufzeit-Indikatoren

- Crashes/Restarts von FFmpeg-Workern bei RTSP/AV1-Ingest (moegliche Overflow-Trigger)
- Segfaults in libavformat/libavcodec in dmesg/coredumpctl
- ungewoehnliche Kindprozesse eines FFmpeg-Workers (Hinweis auf RCE-Folgeaktivitaet)
- Speicher-/Zeit-Spitzen bei manipulierten Containern (DoS-Funde wie AVI-LIST/CAF)

Betreiberempfehlung

Mittelstand

Zuerst inventarisieren, dann patchen — und zwar nicht nur das System-Paket. Die meisten Mittelstands-Stacks haben FFmpeg an mindestens drei Stellen: als Distributions-Paket, als Python-Wheel im Hintergrund-Worker und gebündelt in irgendeiner App oder Appliance. apt upgrade erwischt nur das erste. Wo ein Dienst Datei-Uploads thumbnailt oder Medien transkodiert, behandeln Sie das als untrusted-Parsing: Worker isolieren, Netzwerk und Ressourcen begrenzen, und bis der Fix überall liegt eine Protokoll-Whitelist setzen. Wer keinen RTSP-/AV1-Ingest betreibt, hat beim schärfsten Fund Luft — aber die Demuxer-Funde betreffen auch ganz normale Datei-Formate.

Enterprise

Zusätzlich: SBOM-getriebene Suche nach ffmpeg/libav* über alle Images und Artefakte, nicht nur Hosts. Behandeln Sie CVE-tragende Dependency-Bumps als Security-Arbeit mit eigenem SLA, nicht als Routine-Wartung — die Quelle bringt es auf den Punkt: Bugs zu finden ist billig geworden, das Triagen, Fixen und Ausrollen nicht. Für netzwerkerreichbare Media-Ingest-Pfade lohnt eine eigene Detection (Worker-Crash-Telemetrie, Kindprozess-Anomalien) und eine Sandbox mit seccomp/AppArmor, damit ein erfolgreicher Overflow nicht direkt zu lateraler Bewegung wird.

Kubernetes / Container

Images neu bauen, sobald der Fix in der Basis liegt — und prüfen, ob FFmpeg über das Basis-Image oder über ein App-Layer (Wheel/Node-Binding/statische Binary) hereinkommt; oft beides. FFmpeg-Transcoding-Pods gehören in einen eigenen, minimal privilegierten Namespace mit seccompProfile, ohne ausgehenden Netzzugang für reine Datei-Jobs und mit harten Memory-/CPU-Limits gegen die DoS-Funde. Wo RTSP-Ingest läuft, die erlaubten Quell-Hosts über NetworkPolicy einschränken.

Deklarative Stacks (NixOS / Talos / Flatcar)

Der Vorteil hier ist die Nachweisbarkeit: Welche FFmpeg-Version mit welchen aktivierten Demuxern/Protokollen in welchen Build floss, ist belegbar — und der Rebuild auf die gepatchte Version ist reproduzierbar statt händisch. Wer FFmpeg ohnehin mit minimierter Feature-Matrix baut (nur benötigte Demuxer/Protokolle), hat die Angriffsfläche bereits strukturell kleiner. Genau das ist hier der Hebel: Ein Build ohne RTSP/RTP-Support ist gegen den schärfsten Fund schlicht nicht erreichbar.

Was wir konkret getan haben

Wir behandeln FFmpeg in betreuten Stacks als das, was es ist: eine netzwerk-/datei-erreichbare Parsing-Fläche für untrusted Input. Anlassbezogen heisst das: FFmpeg-Inventar über alle Images, Wheels und Appliances gezogen (nicht nur System-Pakete), Aufruf-Pfade auf untrusted RTSP/RTP/HTTP geprüft, fehlende -protocol_whitelist nachgezogen, Transcoding-Worker auf Sandbox/seccomp und Ressourcen-Limits kontrolliert, und die Distribution-/Upstream-Fixes als priorisierten Bump eingeplant, sobald sie ausgeliefert sind. Wo kein AV1/RTSP-Ingest gebraucht wird, ist der entsprechende Protokoll-Pfad ohnehin aus.

Die ehrliche Lehre liegt aber eine Ebene höher und schliesst an unsere laufende KI-Security-Linie an. In unserem IronWorm-Post war „Claude“ die Angreifer-Tarnung (gefälschte Commit-Autoren); hier liefern autonome Agenten auf der Verteidiger-Seite — Big Sleep, Anthropics Mythos / Project Glasswing, und nun depthfirst — reproduzierbare Funde in genau dem Code, den zwei Jahrzehnte Fuzzing nicht ausgeschöpft haben. Dieselbe Technologie, beide Seiten der Mauer. Für Betreiber verschiebt sich der Engpass damit sichtbar: Das Finden ist auf ~1.000 Dollar pro Lauf gefallen, der Stau sitzt jetzt im Einspielen. Wer Patch-Zyklen, Auto-Update und CVE-Bumps weiter als „Routine-Wartung“ führt, gerät gegen ein Fund-Tempo ins Hintertreffen, das nicht mehr menschlich getaktet ist.

Tiefer Blick: warum ein „ignoriertes“ Paket zur RCE wird

Der AV1-RTP-Fund ist lehrreich, weil der Bug nicht in „bösem“ Code sitzt, sondern in einer harmlos klingenden Spec-Vorgabe: „Temporal Delimiter ignorieren und entfernen.“ Die Implementierung erfüllt das halbherzig — sie zählt den Schreib-Cursor um die deklarierte Grösse weiter (als hätte sie etwas geschrieben), alloziert aber nichts und konsumiert die Input-Bytes nicht. Aus diesem einen continue fallen zwei Defekte: ein vergifteter Schreib-Cursor und ein nicht fortbewegter Lese-Zeiger, der dieselben Bytes erneut als Längenfeld liest. Die Eleganz des PoC liegt in der Arithmetik: Die Werte sind so gewählt, dass der Overflow exakt den free-Funktionszeiger der direkt benachbarten AVBuffer-Struktur trifft, während der refcount knapp darunter unangetastet bei 1 bleibt — sonst würde der Free nie ausgelöst. Das ist kein Zufallstreffer, sondern präzise auf FFmpegs eigenes Allokations-Layout getuntes Engineering. Lehre: Bei untrusted Parsern ist nicht nur „was wird geschrieben“ relevant, sondern auch „stimmt der Cursor noch mit der Allokation überein“ — eine Invariante, die ein menschliches Review über 1,5 Mio. Zeilen leicht übersieht und ein zielgerichteter Agent gezielt prüft.

Fazit

Die FFmpeg-Funde sind in der Bug-Klasse nichts Neues — Heap-/Stack-Overflows in Demuxern kennt jeder, der untrusted Medien parst. Neu sind drei Dinge: dass ein dritter autonomer Agent unabhängig in hart-auditiertem Code liefert, dass die Kosten dafür auf ~1.000 Dollar gefallen sind, und dass mindestens ein Fund ein sauberes, netzwerkerreichbares RCE-Primitiv ist. Für Betreiber ist die Botschaft unspektakulär und genau deshalb wichtig: FFmpeg sitzt nicht nur im System-Paket, sondern in Images, Wheels und Appliances — patchen Sie die eingebetteten Kopien mit, behandeln Sie Media-Parsing als untrusted-Fläche und priorisieren Sie alles mit untrusted RTSP/AV1. Die massgebliche Versionsliste gehört zu Upstream/Distribution, nicht zu einer Momentaufnahme. Nicht dramatisieren — aber heute inventarisieren, und den Patch-Stau ernster nehmen als das Finden, denn das Finden ist gerade billig geworden.

Quellen

• depthfirst — 21 Zero-Days in FFmpeg (02.06.2026; vollständiger Teardown, CVE-Liste, RCE-PoC)
• The Hacker News — AI Agent Uncovers 21 Zero-Days in FFmpeg; Chrome Patches Record 429 Bugs (06.06.2026)
• depthfirst — PoC für DFVULN-127 (AV1-RTP-Depacketizer)
• FFmpeg Security-Seite (Upstream-Advisories, inkl. BIGSLEEP-Tags)