vLLM-RCE über Video-Link: CVE-2026-22778 gefährdet Millionen KI-Server

Es braucht keinen kompromittierten Account, keinen Phishing-Link an einen Mitarbeiter und keinen physischen Zugriff auf den Server. Es genügt eine einzige HTTP-Anfrage mit einer Video-URL an eine erreichbare API – und ein Angreifer übernimmt den Prozess, der das Sprachmodell bedient. Genau das beschreibt CVE-2026-22778, eine mit CVSS 9.8 als kritisch eingestufte Schwachstelle in vLLM, einer der meistgenutzten Open-Source-Engines für den produktiven Betrieb von Sprachmodellen. Der Sicherheitsdienstleister OX Security, der die Lücke entdeckt und offengelegt hat, betitelt seinen Bericht mit "Millions of AI Servers at Risk" – eine Einschätzung, die Einordnung verdient, aber keine Übertreibung ist.

Für Betreiber selbst gehosteter Inferenz-Server ist die Lücke aus zwei Gründen unangenehm: Sie sitzt nicht in einem exotischen Feature, sondern in der ganz normalen Bildverarbeitung multimodaler Modelle. Und sie zeigt exemplarisch, wie wenig ein Perimeter-Vorteil hilft, wenn die eingesetzte Software selbst verwundbar ist.

Anders als viele Sicherheitslücken, die tief in seltenen Konfigurationskombinationen oder Randfällen stecken, trifft CVE-2026-22778 den Kern dessen, was eine moderne Inferenz-Engine leisten soll: beliebige Nutzereingaben – Text, Bilder, zunehmend auch Video – entgegenzunehmen und zu verarbeiten. Wer produktiv mit multimodalen Modellen arbeitet, kann diesen Angriffsvektor nicht einfach wegkonfigurieren, ohne die entsprechende Funktionalität vollständig abzuschalten. Genau das macht die Lücke praktisch relevanter als viele theoretisch schwerwiegendere, aber kaum ausnutzbare CVEs mit ähnlichem Score.

Die Schwachstelle im Detail: Vom Heap-Leak zum RCE

CVE-2026-22778 ist kein einzelner Bug, sondern die Verkettung zweier für sich genommen unterschiedlich schwerer Fehler. Erst in Kombination ergeben sie kontrollierte Codeausführung auf dem Server.

Stufe 1: Ein Fehlertext verrät die Speicheradresse

Der erste Schritt ist unspektakulär: Ein Angreifer sendet ein ungültiges oder absichtlich fehlerhaftes Bild an den multimodalen Endpunkt von vLLM. Die Bildverarbeitung nutzt intern die Python-Bibliothek Pillow (PIL). Bei bestimmten Fehlerzuständen wirft PIL eine Exception, deren Text die textuelle Repräsentation eines BytesIO-Objekts enthält – und diese Repräsentation schließt die rohe Speicheradresse des Objekts im Prozessspeicher ein. vLLM reicht diese Fehlermeldung ungefiltert an den Client zurück.

Das klingt nach einem kleinen Informationsleck, ist aber der eigentliche Hebel des Angriffs. Adressraum-Layout-Randomisierung (ASLR) soll genau verhindern, dass ein Angreifer weiß, wo im Speicher sich verwertbare Strukturen befinden – bei einem 64-Bit-Adressraum sind das rein rechnerisch weit über vier Milliarden mögliche Basisadressen. Sobald aber eine konkrete Heap-Adresse im Klartext in der Fehlerantwort steht, kollabiert dieser Schutz auf einen Bruchteil: In der von OX Security dokumentierten Kette bleiben effektiv noch rund acht Kombinationen übrig, die ein automatisiertes Skript in Sekunden durchprobiert. Aus Sicht der Verteidigung ist das der Moment, in dem aus einem harmlos wirkenden Server-Fehler eine Zielkoordinate für den nächsten Schritt wird.

Stufe 2: Heap-Overflow im JPEG2000-Decoder von FFmpeg

Der zweite Baustein liegt nicht im eigentlichen vLLM-Code, sondern in dessen Abhängigkeitskette. vLLM nutzt OpenCV zur Dekodierung von Video-Uploads, und OpenCV bindet intern FFmpeg ein – in der betroffenen Kette Version 5.1.x. Der JPEG2000-Decoder dieser FFmpeg-Version enthält einen klassischen Heap-Buffer-Overflow: Ein Video, dessen Frames gezielt als JPEG2000-Bilder mit manipulierten Header- und Größenangaben konstruiert wurden, schreibt beim Dekodieren über die Grenzen des dafür allokierten Speicherbereichs hinaus.

Für sich genommen ist ein Heap-Overflow ohne bekannte Zieladresse meist "nur" ein Absturzrisiko – der Prozess crasht, aber ein Angreifer weiß nicht, wohin die überschreibenden Daten geschrieben werden müssen, um etwas Nützliches zu bewirken. Genau diese Lücke schließt Stufe 1: Mit der geleakten Heap-Adresse kann der Overflow gezielt auf eine bekannte Speicherstelle gerichtet werden, wodurch aus dem Speicherfehler kontrollierte Codeausführung wird.

Warum die Verkettung so gefährlich ist

Jede der beiden Teilschwachstellen wäre für sich genommen deutlich weniger kritisch. Eine reine Information-Disclosure-Lücke, die eine Speicheradresse preisgibt, ist ärgerlich, aber ohne einen zweiten Fehler, der diese Adresse tatsächlich nutzbar macht, kein Weg zur Codeausführung. Ein Heap-Overflow ohne bekannte Zieladresse wiederum führt in der Regel "nur" zu einem Absturz des Prozesses – lästig für die Verfügbarkeit, aber kein Kontrollverlust. Erst die Kombination aus beidem macht den Exploit zuverlässig reproduzierbar: Der Angreifer muss nicht raten, sondern kennt die Zieladresse aus Schritt eins, bevor er in Schritt zwei den Overflow gezielt darauf ausrichtet. Diese Zuverlässigkeit ist der Grund, warum Sicherheitsforscher solchen Verkettungen regelmäßig höhere praktische Relevanz zuschreiben als isolierten Einzelfehlern mit ähnlichem CVSS-Wert.

Der Angriffsablauf: Wie ein einzelner Video-Link zur Übernahme führt

Zusammengesetzt ergibt sich ein Ablauf, der ohne Social Engineering, ohne gestohlene Zugangsdaten und ohne komplexe Vorbereitung am Zielsystem auskommt:

1. Adressleck erzeugen. Der Angreifer sendet ein präpariertes, ungültiges Bild an den multimodalen Endpunkt und liest die Heap-Adresse aus der zurückgegebenen Fehlermeldung.
2. Payload-Video bauen. Aus gezielt konstruierten JPEG2000-Frames wird ein Video erstellt, das beim Dekodieren den Heap-Overflow an genau der zuvor geleakten Adresse auslöst.
3. Video-Link übermitteln. Der Link auf dieses Video wird an denselben oder einen verwandten multimodalen API-Endpunkt gesendet – vLLM lädt und dekodiert das Video serverseitig über OpenCV/FFmpeg.
4. Codeausführung. Der Overflow überschreibt Speicher an der bekannten Adresse gezielt, wodurch beliebiger Code mit den Rechten des vLLM-Prozesses ausgeführt wird – potenziell mit Zugriff auf Modellgewichte, angebundene Datenquellen und das interne Netzwerk.

Bemerkenswert ist, was in diesem Ablauf fehlt: kein Login, kein API-Key-Diebstahl, keine Rechteausweitung im klassischen Sinn. Die einzige Voraussetzung ist Netzwerkerreichbarkeit des Endpunkts. Genau das ist in der Praxis häufiger der Fall, als es sein sollte – viele Deployments exponieren die OpenAI-kompatible vLLM-API direkt, ohne Gateway, ohne Authentifizierungsschicht davor, oft mit der Begründung, es handle sich ja "nur" um einen internen Dienst.

Für die Erkennung ist genau das ein Problem: Aus Sicht klassischer Netzwerküberwachung sehen alle vier Schritte wie normale API-Nutzung aus. Zwei HTTP-POST-Anfragen an einen dokumentierten Endpunkt, einmal mit einem Bild, einmal mit einer Video-URL – ohne gezieltes Logging auf Anwendungsebene, das Fehlermeldungen und deren Inhalt erfasst, geht der entscheidende Hinweis (die geleakte Adresse in der Serverantwort) im normalen Traffic unter. Das unterstreicht, warum reines Perimeter-Monitoring – Firewall-Logs, IP-Reputationslisten – gegen diese Klasse von Angriffen wenig ausrichtet und die Erkennung auf Ebene der Anwendung selbst ansetzen muss.

Betroffene Versionen, Patch-Status und ein unvollständiger Fix

Die Faktenlage laut offizieller GitHub Security Advisory ist eindeutig:

Angabe	Wert
CVE-ID	CVE-2026-22778
CVSS-Score	9.8 (kritisch)
Betroffene Versionen	vLLM 0.8.3 bis 0.14.0
Gefixt in	vLLM 0.14.1
Advisory	GHSA-4r2x-xpjr-7cvv
Entdeckt/veröffentlicht durch	OX Security

Wichtig für Betreiber, die sich mit "wir sind auf 0.14.1" bereits in Sicherheit wiegen: Der ursprüngliche Fix war nicht vollständig. Unter der Folge-CVE-2026-54236 wurde bekannt, dass über bestimmte Router-Pfade – unter anderem im Zusammenhang mit Anthropic-kompatiblen Routing-Konfigurationen – weiterhin PIL-Repräsentationsadressen ausgelesen werden konnten. Der ursprüngliche Patch hatte also die eine bekannte Codepfad-Variante der Information-Disclosure-Lücke geschlossen, aber nicht alle.

Die praktische Konsequenz: nicht nur auf 0.14.1 oder neuer aktualisieren, sondern die Advisory-Seite des vLLM-Projekts und die Release-Notes im Auge behalten, bevor man den Fall als geschlossen betrachtet. Gerade Unternehmen mit komplexeren Routing-Setups – etwa mehreren vorgeschalteten API-kompatiblen Schnittstellen für unterschiedliche Client-Ökosysteme – sollten nach jedem Update gezielt prüfen, ob der jeweils genutzte Router-Pfad tatsächlich vom Fix erfasst ist, statt sich auf die Versionsnummer allein zu verlassen. Ein pragmatischer Ansatz ist ein wiederkehrender, kalendarisch fest eingeplanter Termin – etwa monatlich –, an dem jemand im Team explizit die Advisory-Historie des eingesetzten Serving-Stacks durchgeht, statt darauf zu hoffen, die Meldung zufällig zu sehen.

Warum potenziell Millionen von Servern betroffen sind

OX Security stützt die Zahl in der Überschrift des eigenen Blogposts – "Millions of AI Servers at Risk" – nicht auf eine Zählung tatsächlich kompromittierter Systeme, sondern auf die Verbreitung des vLLM-Pakets selbst: Das Python-Paket verzeichnet nach Angaben des Unternehmens über drei Millionen Downloads pro Monat und mehr als 80.000 Sterne auf GitHub. Das ist eine Hochrechnung auf Basis von Popularitäts- und Download-Zahlen, keine bestätigte Zahl real angegriffener oder kompromittierter Server.

Trotzdem ist die Einordnung nicht aus der Luft gegriffen. Die relevante Angriffsfläche ergibt sich daraus, wie viele dieser Installationen multimodale Endpunkte aktiv erreichbar haben – und das dürfte ein nicht kleiner Anteil sein, weil moderne Vision-fähige Modelle Bild- und Video-Verarbeitung häufig standardmäßig mitbringen, auch wenn der eigentliche Anwendungsfall reiner Text ist. Wer den Endpunkt nicht bewusst deaktiviert hat, betreibt ihn wahrscheinlich, ohne es zu wissen.

Für die eigene Risikobewertung ist die genaue Zahl kompromittierter Server ohnehin zweitrangig. Entscheidend ist die einfachere Frage: Läuft bei uns eine vLLM-Instanz mit multimodalen Endpunkten in einer Version zwischen 0.8.3 und 0.14.0, die aus dem Netzwerk erreichbar ist, in dem sich potenzielle Angreifer – intern oder extern – bewegen können? Wer diese Frage nicht aus dem Stand beantworten kann, hat unabhängig von der Millionen-Schätzung bereits ein Erkenntnisproblem, das vor jeder technischen Maßnahme gelöst werden muss: eine verlässliche Inventur aller betriebenen Inferenz-Server samt Versionsstand.

Warum das gerade On-Premise- und Self-Hosting-Betreiber trifft

vLLM hat sich in den vergangenen Jahren zu einer der meistgenutzten Inferenz-Engines für produktive, selbst gehostete LLM-Stacks entwickelt. Drei Eigenschaften erklären das: PagedAttention als speichereffizientes Verfahren zur Verwaltung des Attention-Caches, eine OpenAI-kompatible API, die bestehende Client-Integrationen ohne Anpassung weiterverwenden können, und Continuous Batching, das den GPU-Durchsatz gegenüber naiven Serving-Ansätzen deutlich erhöht. Gerade Unternehmen, die bewusst auf eigene Infrastruktur statt auf Cloud-APIs setzen, um Datenhoheit zu behalten, nutzen vLLM häufig genau als diesen Serving-Layer zwischen Modellgewichten und Anwendung.

Air-Gapping schützt vor Netzwerkzugriff, nicht vor der eigenen API

Die Kernbotschaft von CVE-2026-22778 für diese Zielgruppe ist unbequem, aber wichtig: Eigene Infrastruktur bedeutet nicht automatisch mehr Sicherheit, wenn die eingesetzte Open-Source-Software und ihre Abhängigkeitskette ungepatcht bleiben. On-Premise- und Air-Gapped-Betrieb reduzieren die Angriffsfläche gegenüber dem offenen Internet erheblich – kein externer Akteur kann direkt auf einen vollständig getrennten Server zugreifen. Innerhalb des eigenen Netzwerks bleibt eine erreichbare, unauthentifizierte oder schwach abgesicherte API aber genauso angreifbar wie im Cloud-Betrieb, nur dass der Angreifer in diesem Fall bereits im internen Netz sitzen muss – etwa nach einem initialen Zugriff über Phishing, eine kompromittierte Mitarbeiter-Workstation oder einen anderen verwundbaren internen Dienst. Lateral Movement innerhalb eines Firmennetzes ist ein etabliertes Angriffsmuster, und ein ungepatchter vLLM-Server mit Zugriff auf sensible Modelldaten ist ein attraktives Ziel dafür.

Typische Fehlkonfiguration: "nur intern erreichbar"

In der Projektpraxis wiederholt sich ein bestimmtes Muster auffällig oft: Ein Serving-Container wird testweise mit einer Bindung auf alle Netzwerkschnittstellen gestartet, weil das für einen schnellen ersten Test bequemer ist als eine restriktive Konfiguration. Der Test läuft erfolgreich, das Projekt geht in den nächsten Sprint über – und die großzügige Bindung bleibt bestehen, weil niemand explizit den Auftrag hatte, sie nachträglich zu verschärfen. Aus einer geplanten Testinstanz wird so, ohne bewusste Entscheidung, ein dauerhaft erreichbarer Produktionsdienst ohne vorgeschaltete Authentifizierung. Eine regelmäßige, unabhängig vom Entwicklungsteam durchgeführte Netzwerk- und Portscan-Prüfung der eigenen Infrastruktur deckt solche schleichenden Abweichungen zuverlässiger auf als das Vertrauen auf ursprüngliche Architekturentscheidungen.

Sofortmaßnahmen für Betreiber

Für Betriebsteams, die vLLM produktiv einsetzen, lässt sich die Reaktion in eine überschaubare Checkliste fassen:

1. Sofort auf vLLM 0.14.1 oder neuer aktualisieren und danach die Advisory-Seite des Projekts sowie die Release-Notes auf Folgemeldungen wie CVE-2026-54236 prüfen.
2. Multimodale bzw. Video-Endpunkte deaktivieren, wenn sie nicht zwingend benötigt werden. Ein Endpunkt, der nicht existiert, kann nicht angegriffen werden.
3. API-Zugriff absichern. Netzwerksegmentierung, ein Zero-Trust-Ansatz oder ein vorgeschaltetes Gateway mit Authentifizierung ersetzen die direkte Exposition der Inferenz-API im internen oder gar öffentlichen Netz.
4. Input-Validierung und WAF-Regeln ergänzen, speziell für Video- und Bild-Uploads – etwa Größen- und Format-Whitelisting vor der eigentlichen Dekodierung.
5. Logging und Monitoring schärfen. Ungewöhnliche Fehlermeldungen, die Speicheradressen oder interne Objektrepräsentationen enthalten, sowie auffällige Video-Uploads sollten gezielt erkannt und alarmiert werden.
6. Eine Software Bill of Materials (SBOM) pflegen, die auch gebündelte Abhängigkeiten wie FFmpeg innerhalb von OpenCV erfasst, um künftige Lieferketten-Risiken früher zu identifizieren, statt erst durch einen Vorfall davon zu erfahren.

Maßnahme	Priorität	Aufwand
Update auf 0.14.1+	Sofort	gering
Video-Endpunkte deaktivieren (falls unnötig)	Sofort	gering
Netzwerksegmentierung / Gateway	Hoch	mittel
Input-Validierung / WAF-Regeln	Hoch	mittel
Monitoring auf Adressleaks/Uploads	Mittel	mittel
SBOM für Abhängigkeiten pflegen	Mittel	laufend

Diese sechs Punkte sind bewusst als Reihenfolge gedacht, nicht als gleichrangige Liste. Update und Deaktivierung nicht benötigter Endpunkte lassen sich in der Regel innerhalb weniger Stunden umsetzen und sollten vor jeder aufwendigeren Architekturänderung stehen. Netzwerksegmentierung, Gateway-Aufbau und Monitoring sind danach die eigentliche strukturelle Härtung – sie verhindern, dass die nächste Schwachstelle in vLLM, Ollama oder einer vergleichbaren Engine dieselbe unmittelbare Wirkung entfaltet. Vor dem produktiven Rollout eines Patches empfiehlt sich außerdem ein kurzer Testlauf in einer Staging-Umgebung, insbesondere wenn eigene Erweiterungen oder Router-Konfigurationen auf der vLLM-API aufsetzen – genau dort hätte sich im vorliegenden Fall die Unvollständigkeit des ersten Fixes am ehesten frühzeitig gezeigt.

Einordnung: Teil einer wachsenden CVE-Welle bei selbst gehosteter KI-Infrastruktur

CVE-2026-22778 steht nicht isoliert. 2026 hat eine ganze Reihe kritischer Schwachstellen in populärer Open-Source-Software für Self-Hosting von KI-Modellen hervorgebracht – darunter die als "Bleeding Llama" bekannte Lücke CVE-2026-7482 in Ollama, die Secrets leaken konnte, sowie eine Serie von Schwachstellen in Langflow und Open WebUI. Das Muster ist bei allen dieser Fälle ähnlich: Werkzeuge für den Self-Hosting-Bereich wachsen in Nutzerbasis und Funktionsumfang schneller, als ihre Security-Prozesse reifen. Neue Features – wie multimodale Verarbeitung – werden ausgeliefert, bevor deren gesamte Angriffsfläche, einschließlich gebündelter Drittanbieter-Bibliotheken, systematisch geprüft wurde.

Drei strukturelle Ursachen wiederholen sich über diese Fälle hinweg. Erstens: gebündelte Abhängigkeiten wie FFmpeg, die selten mit derselben Aufmerksamkeit versioniert und geprüft werden wie der eigentliche Anwendungscode. Zweitens: eine Entwicklungskultur, die auf schnelle Feature-Auslieferung optimiert ist – nachvollziehbar angesichts des Innovationstempos im KI-Bereich, aber mit systematischen Kosten für die Reife von Security-Reviews. Drittens: Standardkonfigurationen, die auf einfache Inbetriebnahme statt auf sichere Grundeinstellung ausgelegt sind, etwa fehlende Authentifizierung ab Werk. Keine dieser Ursachen ist vLLM-spezifisch, und keine lässt sich mit einem einzelnen Patch dauerhaft beheben.

Für Betreiber bedeutet das: Strukturiertes Patch-Management und Härtung der Inferenz-Schicht gehören als Daueraufgabe in den Betrieb, nicht als einmaliges Projekt zum Rollout. Dazu gehört ein aktueller Überblick über alle eingesetzten Self-Hosting-Komponenten samt Versionsstand, ein Abonnement der jeweiligen Security-Advisory-Feeds und ein klarer interner Verantwortlicher, der Meldungen wie CVE-2026-22778 oder CVE-2026-7482 nicht erst über die Fachpresse, sondern über die offizielle Quelle erfährt. Wer die eigenen Ollama- und vLLM-Endpunkte noch nicht systematisch gehärtet hat, findet dazu vertiefende Hinweise in unserem Beitrag zum Härten von LLMjacking-anfälligen Endpunkten.

Fazit: Air-Gapped ist nicht gleich unverwundbar

CVE-2026-22778 zeigt exemplarisch, dass Software-Lieferketten-Risiken – hier konkret FFmpeg, eingebunden über OpenCV in vLLM – unabhängig vom Hosting-Modell wirken. Ob ein Server in der Public Cloud, im eigenen Rechenzentrum oder vollständig vom Internet getrennt läuft, ändert nichts daran, dass ein Heap-Buffer-Overflow im Videodecoder ein Heap-Buffer-Overflow bleibt. On-Premise-KI bringt echte, belegbare Vorteile bei Datenhoheit, Kontrolle über Zugriffsrechte und Unabhängigkeit von externen Cloud-Anbietern – sie entbindet aber nicht von aktivem Schwachstellen-Management der eingesetzten Software.

Wer vLLM oder vergleichbare Inferenz-Engines produktiv betreibt, sollte den Patch-Status jetzt prüfen, multimodale Endpunkte auf tatsächlichen Bedarf hin durchgehen und die eigene Absicherung nicht an einer einzelnen Versionsnummer festmachen. Genauso wichtig wie die technische Reaktion auf diesen konkreten Fall ist der Blick auf den Prozess dahinter: Wer heute eine verlässliche Inventur seiner Serving-Infrastruktur, ein Abonnement der relevanten Advisory-Kanäle und einen benannten Verantwortlichen für Sicherheitsmeldungen hat, wird auf die nächste vergleichbare CVE – und es wird eine geben – in Stunden statt in Wochen reagieren können.

Für eine strukturierte Bestandsaufnahme und Härtung Ihrer On-Premise-KI-Infrastruktur – von der Netzwerksegmentierung über die Absicherung multimodaler Endpunkte bis zur SBOM-Pflege für gebündelte Abhängigkeiten – stehen wir als Ansprechpartner bereit.

Quellen & Primärbelege

1. OX Security: Millions of AI Servers at Risk – CVE-2026-22778 vLLM RCE Erstveröffentlichung/Entdeckung der Schwachstelle durch OX Security; Quelle der Einschätzung zur Reichweite basierend auf Download-Zahlen des vLLM-Pakets.
2. GitHub Security Advisory GHSA-4r2x-xpjr-7cvv: vLLM RCE In Video Processing Offizielle technische Advisory des vLLM-Projekts mit CVSS 9.8, betroffenen Versionen 0.8.3–0.14.0 und Fix in 0.14.1.
3. Red Hat Customer Portal: CVE-2026-22778 Unabhängige Bestätigung von CVSS-Score und Versionsangaben durch Red Hat Security.

Häufig gestellte Fragen zu CVE-2026-22778

Was ist CVE-2026-22778 genau?

CVE-2026-22778 ist eine kritische Sicherheitslücke (CVSS 9.8) in der Open-Source-Inferenz-Engine vLLM. Sie erlaubt Remote Code Execution (RCE), indem ein Angreifer einen präparierten Video-Link an eine multimodale vLLM-API-Endpunkt übermittelt. Technisch handelt es sich um eine Verkettung zweier Schwachstellen: eine Information-Disclosure-Lücke, die eine Heap-Speicheradresse preisgibt, und einen Heap-Buffer-Overflow im mitgelieferten FFmpeg-5.1.x-JPEG2000-Decoder, der von vLLM zur Video-Dekodierung über OpenCV genutzt wird. Betroffen sind die Versionen 0.8.3 bis 0.14.0, gefixt in 0.14.1 (GitHub-Advisory GHSA-4r2x-xpjr-7cvv).

Muss ich sofort patchen, auch wenn ich (bewusst) keine Video-Modelle einsetze?

Ja. Viele vLLM-Deployments aktivieren multimodale Endpunkte standardmäßig mit, auch wenn der primäre Use-Case Text ist – etwa weil ein Vision-fähiges Modell geladen wurde. Da die Lücke keine Authentifizierung jenseits des API-Zugriffs voraussetzt, reicht ein erreichbarer Endpunkt aus. Der sicherste Weg ist ein Update auf 0.14.1 oder neuer plus eine Prüfung, ob multimodale/Video-Endpunkte überhaupt benötigt werden – falls nicht, deaktivieren.

Reicht das Update auf vLLM 0.14.1 vollständig aus?

0.14.1 schließt die in CVE-2026-22778 beschriebene Kette. Allerdings wurde danach unter CVE-2026-54236 bekannt, dass ein Teilaspekt – das Leaken von PIL-Repr-Adressen über bestimmte Router-Pfade – im ursprünglichen Fix nicht vollständig behoben war. Betreiber sollten daher den aktuellen Patch-Stand und die Advisory-Historie des vLLM-Projekts laufend prüfen, statt sich auf einen einzelnen Versionssprung zu verlassen.

Schützt On-Premise-Hosting automatisch vor solchen Lücken?

Nein. On-Premise oder Air-Gapped-Betrieb reduziert bestimmte Angriffsflächen (z. B. Cloud-Zugriffsrechte, Datenabfluss über Internet), ändert aber nichts an Schwachstellen in der eingesetzten Software selbst. CVE-2026-22778 sitzt in der Inferenz-Engine und ihrer Abhängigkeitskette (FFmpeg via OpenCV) – unabhängig davon, ob der Server in der Cloud, im eigenen Rechenzentrum oder komplett getrennt vom Internet läuft. Patch-Management bleibt Pflicht.