vLLM: Denial of Service über ungeprüfte Multimodal-Processor-kwargs
Zusammenfassung
vLLM-Versionen ab 0.7.3 vor 0.31.0 erlauben entfernten Clients, multimodale Processor-Parameter pro Anfrage zu setzen, etwa Bildgrösse, Patch-Anzahl, Crop-Anzahl oder Frame-Anzahl. Bei einigen Processoren (zum Beispiel Isaac, InternVL und H2OVL) kann eine einzelne präparierte Anfrage den Speicher erschöpfen und den gemeinsam genutzten Serverprozess beenden. Laut Herstellerhinweis ist der API-Schlüssel optional, weshalb Deployments ohne externe Authentifizierung ohne Berechtigungen erreichbar sind. Die Auswirkung beschränkt sich auf die Verfügbarkeit; ein Verlust der Vertraulichkeit oder Integrität wird nicht angegeben.
Betroffen
- vLLM ab 0.7.3 vor 0.31.0
- Relevant vor allem für Deployments, die multimodale Anfragen (Bild oder Video) verarbeiten
- Nicht betroffen: 0.31.0 und neuer (laut Hersteller)
Behoben in
- Auf vLLM 0.31.0 oder neuer aktualisieren (Fix in PR #58830 zusammengeführt)
Umgehung
- Unbekannt. Der Hersteller dokumentiert für betroffene Versionen keine Workaround-Massnahme ausser dem Update.
- Einen authentifizierenden Reverse-Proxy vor die API stellen und den Zugriff auf vertrauenswürdige Clients beschränken (allgemeine Massnahme, nicht vom Hersteller).
Ausnutzung
- Keine bestätigte Ausnutzung in freier Wildbahn bekannt.
- Laut einem Drittanbieter-Aggregator nicht im CISA-KEV-Katalog; der CISA-Katalog wurde nicht direkt geprüft.
- CISA-SSVC-Bewertung: Exploitation none, Automatable yes, Technical Impact partial.
- Kein öffentlicher Proof of Concept gefunden.
Unsere Empfehlung
- Alle vLLM-Instanzen, Versionen, Container-Images und mitgelieferten Abhängigkeiten inventarisieren.
- Auf vLLM 0.31.0 oder neuer aktualisieren.
- Pro Anfrage gesetzte multimodale Processor-Einstellungen für nicht vertrauenswürdige Clients ablehnen oder einschränken; benötigte Einstellungen in die Serverkonfiguration verschieben.
- vLLM nicht ohne Authentifizierung aus dem Internet erreichbar machen; auf wiederholte Abstürze oder Out-of-Memory-Ereignisse achten.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- GitHub Security Advisory GHSA-gx7p-2j49-hfq4 (vendor) github.com
- VulnCheck advisory www.vulncheck.com
- OSV GHSA-gx7p-2j49-hfq4 osv.dev
- GitLab Advisory Database CVE-2026-114055 advisories.gitlab.com
- beri.net vLLM October 2026 advisories www.beri.net
- VulDB 423891 vuldb.com
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 01:11.
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.