vLLM: Speicherauslastung durch Überschreiben von num_frames in media_io_kwargs
Zusammenfassung
vLLM-Versionen von 0.18.0 bis vor 0.31.0 erlauben API-Clients, das Limit der Frame-Anzahl für inline übermittelte video/jpeg-Daten zu umgehen, indem num_frames in media_io_kwargs gesetzt wird, beispielsweise auf -1. Das API-Frontend dekodiert und stapelt danach alle Frames eines grossen inline Videos im Speicher, was den Speicher erschöpfen und den Dienst zum Absturz oder zum OOM-Kill bringen kann. Der Angriff erfordert Netzwerkzugriff auf die API und im ungünstigsten Fall keine Authentifizierung. Die Auswirkung beschränkt sich auf eine Denial-of-Service-Situation.
Betroffen
- vLLM 0.18.0 bis vor 0.31.0
- Downstream-Builds wie Red Hat AI Inference Server und Red Hat OpenShift AI werden in einem Drittquellen-Eintrag als betroffen aufgeführt; Status des Herstellers für Ihren Build prüfen
Behoben in
- vLLM 0.31.0 (gemäss CVE-Eintrag und GHSA-4m6g-h9mv-wqjc; genaue Fix-Version im Advisory bestätigen)
- Die Korrektur weist nicht leere media_io_kwargs pro Anfrage standardmässig ab (PR #58830)
Umgehung
- Unbekannt. Für diese CVE ist kein Workaround vom Hersteller dokumentiert.
- Bis zum Patch: API nicht für nicht vertrauenswürdige Clients erreichbar machen, mit Authentifizierung und einem Gateway mit Begrenzung der Anfragegrösse absichern und sicherstellen, dass --trust-request-mm-kwargs nicht aktiviert ist.
Ausnutzung
- Nicht als aktiv ausgenutzt gelistet (kein Eintrag im CISA KEV).
- In den geprüften Quellen wurde kein öffentlicher Proof of Concept gefunden.
- CISA SSVC: Ausnutzung keine, automatisierbar ja, technische Auswirkung teilweise.
Unsere Empfehlung
- vLLM-Instanzen und Versionen inventarisieren, einschliesslich Container-Images und Red Hat AI/OpenShift AI-Deployments.
- Auf vLLM 0.31.0 oder neuer aktualisieren.
- Direkte Internetexposition der API entfernen und Authentifizierung erzwingen.
- Auf exponierten Servern prüfen, dass --trust-request-mm-kwargs deaktiviert ist.
- Auf Neustarts des API-Prozesses und Speicherspitzen überwachen.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- GitHub Security Advisory GHSA-4m6g-h9mv-wqjc github.com
- VulnCheck advisory: vLLM memory exhaustion via media_io_kwargs num_frames override www.vulncheck.com
- OSV record via Vulners vulners.com
- OpenCVE: CVE-2026-116179 app.opencve.io
- HOL Guard: CVE-2026-116179 hol.org
- OffSeq Radar: CVE-2026-116179 radar.offseq.com
- vLLM documentation: multimodal media video (v0.18.0) docs.vllm.ai
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 00:18.
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.