vLLM-Sicherheitslücken 2026: welche Version sie behebt, nach Erreichbarkeit des Endpunkts

Welche vLLM-Version im Oktober 2026

Stand 24. Oktober 2026 sollten Sie vLLM 0.32.0 vom 18. Oktober 2026 betreiben, mindestens aber 0.31.0 vom 5. Oktober 2026. Von den Advisories, die vLLM zwischen August und Anfang Oktober 2026 in seinem GitHub-Repository veröffentlicht hat, ist 0.31.0 das erste Release außerhalb des betroffenen Bereichs aller, deren Seite wir öffnen konnten, und 0.32.0 härtet weiter. Ein Endpunkt, den nur vertrauenswürdige interne Anwendungen erreichen, ist weniger exponiert als einer für alle Beschäftigten; die meisten dieser Fehler brauchen aber nur eine gewöhnliche Anfrage, die Version zählt also in beiden Fällen.

Diese Seite ordnet die Advisories danach, wie ein vLLM-Server erreichbar ist, denn das entscheidet, welche für Sie gelten. Die Liste wurde am 24. Oktober 2026 gelesen. vLLM strebt etwa alle zwei Wochen ein Release an, und zwischen den Releases erscheinen neue Advisories; prüfen Sie die Liste daher vor jedem Upgrade erneut und lesen Sie diese Seite als datierte Momentaufnahme.

Security Advisories im vLLM-Repository und Einträge der GitHub Advisory Database, einzeln geöffnet am 24. Oktober 2026; Daten von 0.30.0 bis 0.32.0 von den GitHub-Release-Seiten von vLLM. Die Tabellen unten nennen jedes Advisory mit seiner Bedingung.

Für die letzten drei Monate zeigt die Liste des Repositorys mindestens 17 Advisories, veröffentlicht zwischen dem 11. August und dem 6. Oktober, davon drei mit High, zwölf mit Moderate und zwei mit Low. Die Liste auf GitHub ist nicht nach Veröffentlichungsdatum sortiert, daher haben wir jeden Eintrag geöffnet. Die Sicherheitsrichtlinie von vLLM definiert Critical als „CVSS ≥ 9.0“ und High als „between 7.0 and 8.9“ und behandelt beide anders: Fixes für Critical und High entstehen in einem privaten Fork und werden vorab mit Beteiligten einer Vorabinformationsliste abgestimmt, Fixes für Moderate und Low erscheinen als öffentliche Pull Requests ohne Sperrfrist.

Angriffsfläche 1: alle, die API-Anfragen senden können

Diese Advisories brauchen nur Netzwerkzugang zum API-Port, und mehrere funktionieren ohne API-Schlüssel. Auf einem Server, dessen Port das ganze Firmennetz erreicht, gilt jedes davon.

Advisory-Seiten auf GitHub (GHSA-2phq über die GitHub Advisory Database), gelesen am 24. Oktober 2026; GHSA-v5gm aus CVE-2026-100654, gespiegelt in der GitHub Advisory Database („vLLM before 0.29.0“). Werte nach CVSS 3.1 wie auf GitHub angezeigt, außer beim CVE-Eintrag (CVSS 4.0, 7,1).

Die erste Zeile zeigt das Muster. GHSA-25q3-v2hm-8vpf, veröffentlicht am 3. September 2026, beschreibt eine Anfrage an /v1/embeddings oder /pooling mit einer negativen Token-ID, die die Engine „via a CUDA device-side assertion“ beendet; eine Anmeldung ist nicht nötig, der Server bleibt bis zum Neustart aus, und laut Advisory ist Prozessüberwachung keine Abhilfe, weil sich die Anfrage sofort wiederholen lässt. Für Server, die nicht aktualisiert werden können, empfiehlt es, negative Ganzzahlen in input am Gateway abzuweisen und den Zugang zu diesen Routen zu beschränken. Das Advisory zu cache_salt, veröffentlicht am 12. September, wirkt auf die Endpunkte für Chat, Completions, Responses und Pooling sowie auf /v1/messages im Anthropic-Format, ohne Schlüssel, weil Prefix Caching standardmäßig aktiv ist und standardmäßig keine Größengrenze für den Request-Body gilt.

Um den API-Schlüssel selbst geht es im ältesten Eintrag der Tabelle. GHSA-94f4-hr76-p5j6 (CVE-2026-48746), veröffentlicht am 2. Juni 2026 und als Critical eingestuft, erlaubte in den Versionen ab 0.3.0 bis vor 0.22.0, die OpenAI-kompatible API ohne den konfigurierten Schlüssel zu nutzen; Server hinter „an RFC-conforming web server such as nginx“ waren nicht betroffen. Auch in einem aktuellen Release deckt der Schlüssel nicht jede Route ab. Der Sicherheitsleitfaden von vLLM vom 19. Oktober 2026 sagt, der Schlüssel gelte „only for endpoints under the /v1, /v2, /inference, and /cohere path prefixes“, und nennt /invocations, /pooling, /classify, /score, /rerank, /pause, /update_weights und /metrics unter den Routen außerhalb davon. Zwei der Advisories von 2026 ergänzen /tokenize, das die Authentifizierung ebenfalls nicht abdeckt. Unser Leitfaden zum Absichern eines GPU-Servers beschreibt Reverse Proxy und Firewall, die diese Routen schließen.

Angriffsfläche 2: Bilder, Audio und Video in Anfragen

Multimodale Modelle nehmen Medien in Anfragen an, und beim Dekodieren von Medien liegen viele der Advisories von 2026. Es geht um Denial of Service über Speicher, CPU oder GPU-Decoder; keines der gelesenen erlaubt Codeausführung.

Advisory-Seiten auf GitHub (GHSA-ph3r über die GitHub Advisory Database, im Repository veröffentlicht am 28. September 2026), gelesen am 24. Oktober 2026. GHSA-x6mc steht in der Liste des Repositorys, veröffentlicht am 23. September 2026; seine Seite ließ sich nicht laden, und die Notes von vLLM 0.30.0 nennen „Request-controlled video sampling capped for GLMGA (#54935) and Qwen-VL (#56729) backends“.

Version 0.31.0 hat den Standard hinter mehreren davon geändert. Ihre Release Notes schreiben „per-request mm_processor_kwargs and media_io_kwargs are rejected unless --trust-request-mm-kwargs is set“, und der Sicherheitsleitfaden von vLLM ergänzt, dass nur Deployments mit vertrauenswürdigen API-Clients den Server mit diesem Flag starten sollten. Der Leitfaden empfiehlt außerdem --allowed-media-domains gegen Server-Side Request Forgery, VLLM_MEDIA_URL_ALLOW_REDIRECTS=0, damit Weiterleitungen die Liste nicht umgehen, und Größengrenzen wie VLLM_MAX_MEDIA_DOWNLOAD_SIZE_MB, standardmäßig 256. Release 0.32.0 öffnet nicht vertrauenswürdige Bilder mit „a raster-format allowlist“, die EPS, PostScript und WMF ablehnt. Nimmt Ihr Modell nur Text an, betrifft Sie nichts davon; nimmt es Bilder oder Videos von Nutzern an, gehören diese Einstellungen in jedes Deployment, unabhängig von der Version.

Wir liefern GPU-Server für private LLMs, auf Wunsch mit installiertem Betriebssystem, Treiber und Container-Laufzeit; nennen Sie uns das vLLM-Release, Ihre Modelle und wie Nutzer sie erreichen, und unser Team antwortet mit dem Upgrade-Weg und der Konfiguration für den nächsten Server.

Angriffsfläche 3: Modellcode und festgelegte Revisionen

Der dritte Bereich betrifft, was ein Server lädt, nicht was Nutzer senden. Zwei der drei Repository-Advisories mit High von August bis Oktober gehören hierher.

Advisory-Seiten auf GitHub, gelesen am 24. Oktober 2026; GHSA-hhv2 aus CVE-2026-100653, gespiegelt in der GitHub Advisory Database („Versions 0.22.1 through 0.28.0“, behoben in 0.28.0, CVSS 4.0 8,3).

GHSA-h3rc-6mm3-gc2m, veröffentlicht am 6. Oktober 2026, ist der Grund für das Minimum 0.31.0. Bei aktivem --trust-remote-code, einem Modell, dessen Prozessor dynamischen Code nutzt, und einer multimodalen Anfrage konnte ein Client mm_processor_kwargs.code_revision setzen und den Server Prozessorcode aus einer Revision laden lassen, die ein Angreifer kontrolliert, etwa einem Pull Request im Repository des Modells; das Advisory spricht von beliebiger Python-Ausführung im API-Prozess durch „an unauthenticated network client“. Betroffen sind die Versionen ab 0.7.3 bis vor 0.31.0; der Standard mit ausgeschaltetem Remote Code ist es nicht. GHSA-3c86-2m5g-59q7, veröffentlicht am 28. August, ist anders gelagert: Der Prozessor-Loader von LlavaOnevision2 führte den Code des Modells auch mit trust_remote_code=False aus, ein präpariertes Modell konnte also ohne das Flag Code ausführen; dazu muss jemand dieses Modell laden, und 0.28.0 hat den Fehler behoben.

Die Advisories zu Pins betreffen die Integrität. Ein Deployment mit --revision oder --code-revision erwartet, dass jede Datei aus dieser Revision stammt; GHSA-3ww4-5jv9-j5gm, veröffentlicht am 10. Juni 2026, fand Loader, die Zusatzdateien wie Prozessoren, GGUF-Dateien oder Nebengewichte stattdessen vom Standard-Branch holten, und ein späterer CVE-Eintrag fand zwei weitere Architekturen. Lassen Sie Remote Code ausgeschaltet, sofern ein Modell ihn nicht braucht, legen Sie Revisionen fest und laden Sie Modelle aus einem lokalen Modellspeicher, den Sie über einen kontrollierten Weg befüllen, wie unser Leitfaden zur Installation eines LLM-Servers ohne Internetzugang beschreibt.

Angriffsfläche 4: interne Ports, Scale-out und disaggregiertes Serving

Ein Server, der ein Modell über Knoten verteilt oder Prefill und Decode trennt, öffnet Ports neben der API. Der Sicherheitsleitfaden von vLLM hält fest: „All communications between nodes in a multi-node vLLM deployment are insecure by default“, nennt PyTorch Distributed, KV-Cache-Transfer und parallele Kommunikation, gibt 14579 als Standardport für den KV-Transfer und 29500 für den Data-Parallel-Master an und rät, alle eingehenden Verbindungen außer zum API-Port zu sperren.

Advisory-Seiten in der GitHub Advisory Database (im Repository veröffentlicht am 23. September 2026), gelesen am 24. Oktober 2026; die beiden CVE-Einträge beschreiben „vLLM through 0.29.0“, von der NVD am 21. September 2026 veröffentlicht, und nennen kein behebendes Release (sie verweisen auf die Pull Requests 54807 und 49796).

Release 0.30.0 hat die Scale-out-Endpunkte außerdem hinter einen Schalter gelegt: Laut Notes sind /render, /derender und /inference/v1/generate „no longer registered on plain vllm serve“ und werden über --enable-scale-out eingeschaltet. Prüfen Sie bei den Einträgen zu NIXL und Mooncake die verlinkten Pull Requests gegen Ihr Release, bevor Sie ein disaggregiertes Deployment für nicht vertrauenswürdige Nutzer betreiben. Ein einzelner Server, der jedes Modell auf einer Karte oder einem Tensor-Parallel-Paar betreibt, öffnet keinen dieser Ports zum Netz, wenn die Firewall nur den API-Port zulässt. Unser Leitfaden zu disaggregiertem LLM-Serving mit NVIDIA Dynamo beschreibt, wann sich die Trennung von Prefill und Decode trotz größerer Angriffsfläche lohnt.

Was 0.31.0 und 0.32.0 außer Fixes ändern

Ein Upgrade aus Sicherheitsgründen bringt die übrigen Änderungen des Releases mit. In 0.31.0 gehören zu den Breaking Changes die oben beschriebene Ablehnung multimodaler kwargs je Anfrage, das Entfernen von tokenizer_mode="slow" und ein umbenanntes Flag für den Mamba-Prefix-Cache. Release 0.32.0 nennt „Default CORS settings no longer allow every origin in the Python and Rust frontends“; ein Browser-Frontend, das vLLM direkt aufruft, braucht also eine konfigurierte Origin. Es streicht Python 3.10, Minimum ist 3.11; es verlangt transformers ab 5.16.1 und unter 5.20.0; und es behandelt max_tokens „as an upper bound on output rather than reserved from the context window“. Außerdem begrenzt es P2P-ZMQ-Sitzungen über VLLM_P2P_MAX_PEERS, standardmäßig 128, und antwortet mit 400 auf JSON-Schemata für Structured Outputs, die tiefer als 64 Ebenen verschachtelt sind. Die Notes von 0.32.0 nennen neben einigen dieser Punkte Advisory-Kennungen, darunter GHSA-q97c-p368-75c4 für einen Off-by-one-Fehler bei max_token_id im Tokenizer und GHSA-frvg-qw88-hww9 für die Erschöpfung von ZMQ-Sockets durch eindeutige Peer-Adressen. Am 24. Oktober 2026 ließ sich keine der beiden Seiten öffnen, und keine stand in der GitHub Advisory Database; erscheinen sie mit 0.31.0 im betroffenen Bereich, wird 0.32.0 zum Minimum. Prüfen Sie sie also, bevor Sie sich auf 0.31.0 festlegen.

Die Modellunterstützung zieht auf Karten der RTX PRO Blackwell in dieselbe Richtung. vLLM 0.32.0 unterstützt den NVFP4-KV-Cache auf SM12x, und 0.30.0 hat native NVFP4-Kernel auf SM120 zum Standard gemacht, wie unser Leitfaden zur Software-Unterstützung für SM120 erklärt. Ein Server, der wegen eines Modells auf einem älteren Release bleibt, verzichtet auf beides. Unser Leitfaden zum Betrieb einer privaten LLM-Plattform empfiehlt ein Upgrade bei jedem zweiten oder dritten Minor-Release und früher bei einem Sicherheitsfix, mit einem Evaluationslauf vor jedem Wechsel.

Wie Sie nach dem 24. Oktober 2026 auf dem Laufenden bleiben

Advisories erreichen Sie über drei Kanäle, die sich unterscheiden. Die Liste im GitHub-Repository enthält die eigenen Advisories von vLLM mit betroffenen und behobenen Versionen. Die GitHub Advisory Database veröffentlicht sie erneut, ergänzt CVE-Nummern und markiert sie als geprüft; die geprüften Einträge nennen das pip-Paket vllm, sodass Abhängigkeitsscanner, die die Datenbank lesen, eine installierte Version melden können. CVE-Einträge Dritter über VulDB oder VulnCheck erscheinen dort ebenfalls, als ungeprüfte Einträge ohne Paket: Zwei vom 6. Oktober 2026, CVE-2026-105922 im Penalty-Handler und CVE-2026-105775 in einer Mamba-Schicht, beschreiben „vLLM up to 0.31.0“, sind mit Low 2,1 eingestuft und nennen keinen Fix. Lesen Sie solche Einträge anhand der verlinkten Issues, nicht nur anhand der Versionsnummer.

1. Angriffsfläche festhalten. Notieren Sie, welche Routen Nutzer erreichen, ob --trust-remote-code aktiv ist, ob das Modell Medien annimmt und ob ein interner Port den Host verlässt.
2. Neue Advisories daran messen. Die meisten Einträge nennen ihre Voraussetzungen; ein Audio-Advisory betrifft keinen reinen Textserver.
3. Zuerst auf einer zweiten Instanz aktualisieren. Lesen Sie die Release Notes jeder übersprungenen Version auf Breaking Changes, lassen Sie Evaluierungsdatensatz und Lasttest laufen und wechseln Sie dann.

Unser Service Private AI/ML, umgesetzt mit unserem Engineering-Partner Vixen.UNO, baut und betreut private LLM-Plattformen auf vLLM; schreiben Sie uns, welches Release Sie betreiben und wie der Endpunkt erreichbar ist, und wir sagen Ihnen, welche Advisories gelten und was das Upgrade umfasst.

FAQ