vLLM 0.32.0 schließt neun Lücken und ändert den CORS-Standard: Prüfliste, Update-Ablauf und was warten darf

/01Was am 18. und 20. Oktober veröffentlicht wurde

vLLM 0.32.0 ist seit dem 18. Oktober 2026 auf GitHub und PyPI. Zwei Tage später, am 20. Oktober, hat das Projekt die dazugehörigen Sicherheitshinweise freigegeben: neun GitHub Security Advisories, die 0.32.0 als behobene Version nennen. Zwei davon stuft das Projekt als hoch ein, sechs als mittel, einen als niedrig. Wer vLLM als Model Serving-Schicht für eigene Sprachmodelle betreibt, sollte diese Woche entscheiden, wann er aktualisiert.

Die Release Notes nennen 814 Commits von 363 Beitragenden, davon 121 neue. Der größte Teil betrifft Leistung und Modellunterstützung: NVFP4-KV-Cache auf weiteren GPU-Generationen, Model Runner V2 mit neuen Spekulationsverfahren, schnellere Starts. Für den Betrieb zählen drei andere Zeilen. Unter „Security" steht, dass CORS nicht mehr standardmäßig jede Herkunft erlaubt, dass nicht vertrauenswürdige Bilder auf Rasterformate beschränkt werden und dass Handles im Shared-Memory-Cache für multimodale Eingaben jetzt signiert sind. Unter „Breaking changes" steht an erster Stelle: Python 3.10 entfällt.

Das ist die Nachricht. Dieser Artikel macht daraus eine Prüfliste: welche der neun Lücken Ihren Server betrifft, mit welchen Befehlen Sie das in zehn Minuten feststellen, wie der Wechsel von 0.31 auf 0.32 ohne Überraschung abläuft und was Sie tun, wenn Sie heute nicht aktualisieren können. Die Grundlagen zum Härten eines vLLM-Endpunkts – kein offener Port, API-Schlüssel, Reverse-Proxy – stehen im Artikel zu LLMjacking und werden hier vorausgesetzt.

/02Prüfliste: die neun Advisories und wann Sie betroffen sind

Die meisten der neun Hinweise setzen eine bestimmte Konfiguration oder ein bestimmtes Modell voraus. Das ist die gute Nachricht: Für einen reinen Text-Server mit einem gängigen Modell bleiben wenige übrig. Die Tabelle übersetzt jeden Hinweis in eine Bedingung, die Sie an Ihrer Startzeile und Ihrer Modellliste prüfen können. CVSS-Werte und Versionsfelder stammen aus den Advisories selbst, Stand 22. Oktober 2026.

Zwei Hinweise zur Lesart. Erstens: Die Versionsfelder der Advisories sind uneinheitlich gepflegt. Beim Ghostscript-Fall steht „0.30.0", weil der Melder nur diese Version geprüft hat; der Fix kam erst nach 0.31.0. Behandeln Sie deshalb jede Version unter 0.32.0 als betroffen, sobald die Bedingung in der rechten Spalte zutrifft. Zweitens: Beim Pickle-Fall nennt das CVSS-Feld 7,5, der Text des Melders 8,8. Für Ihre Entscheidung ändert das nichts – es bleibt Codeausführung im Worker.

Die rechte Spalte hat noch eine dritte Lesart: Sie zeigt, welche Funktionen Sie gar nicht brauchen. Wer keine OCR-Modelle betreibt, kein KV-Offloading zwischen Knoten nutzt und keine Responses-API anbietet, kann diese Pfade beim Reverse-Proxy schließen – unabhängig von der Version.

/03Die zwei hohen Lücken: Pickle über Shared Memory und Ghostscript über EPS

Shared-Memory-Handles, die niemand geprüft hat

vLLM kann vorverarbeitete multimodale Eingaben in einem Shared-Memory-Ringpuffer halten, damit ein Bild nicht für jeden Worker neu dekodiert wird. Ein Eintrag wird dabei nur über ein Paar aus Adresse und laufender Nummer referenziert. Der Melder hat gezeigt, dass ein angemeldeter Aufrufer über die öffentliche Scale-out-Route eigene Einträge mitschicken kann. Der Worker nimmt das Paar als Berechtigung, liest die Stelle im Shared Memory und entpackt dort abgelegte Bytes mit pickle.loads(). Wer Pickle-Daten kontrolliert, kontrolliert Python-Code. Der Weg funktionierte laut Advisory ausdrücklich auch mit VLLM_ALLOW_INSECURE_SERIALIZATION=0.

Die Kette nutzte drei Routen: /v1/chat/completions/render für eine gültige Hülle, /v1/chat/completions zum Ablegen der Bytes und /inference/v1/generate für das gefälschte Handle. Der Fix (PR 59357) signiert jedes Handle mit einem HMAC über Cache-Schlüssel, Adresse und Nummer; das Geheimnis bleibt im Server. Die Einschränkung ist wichtig: Betroffen ist nur, wer den SHM-Cache ausdrücklich eingeschaltet hat. Das tun vor allem Häuser mit großen Vision-Language-Modell-Lasten, die den Durchsatz optimiert haben – also genau die, die viel über die Schnittstelle schicken.

EPS, das sich als PNG ausgibt

Der zweite Fall ist eine Kette aus bekannten Teilen. vLLM übergab Bildbytes an Pillow, ohne die erlaubten Formate einzuschränken; der MIME-Typ der Anfrage steuerte die Dekodierung nicht. Pillow erkennt EPS an der Signatur und ruft dafür Ghostscript auf. Ist dieses Ghostscript für CVE-2024-29510 anfällig, entkommt PostScript dem -dSAFER-Modus und führt Befehle aus. Der Melder hat das mit dem PyPI-Paket 0.30.0, Pillow 12.3.0 und Debian-Ghostscript 10.03.0 auf Ebene des Bildladers nachgewiesen; den vollständigen HTTP-Weg hat er im Quelltext verfolgt, aber nicht ausgeführt.

vLLM selbst bringt Ghostscript nicht mit. Ob Sie betroffen sind, entscheidet also Ihr Image: Ein schlankes Basis-Image hat kein gs, ein „praktisches" Image mit Office- oder PDF-Werkzeugen oft schon. Der Fix (PR 60022) öffnet Bilder nur noch mit einer Liste erlaubter Rasterformate; EPS, WMF und ähnliche sind ausgeschlossen. Zur Verwandtschaft: Der Fall erinnert an die RCE über einen Video-Link (CVE-2026-22778) – wieder ist es der Medienpfad, über den fremde Bytes in eine Bibliothek geraten, die nie für feindliche Eingaben gebaut war.

/04CORS: warum ein niedriger Wert trotzdem zählt

Der CORS-Hinweis hat nur CVSS 3,4 und ist trotzdem der, der die meisten Häuser betrifft. Bis 0.31 registrierte der API-Server die Starlette-CORS-Middleware mit allowed_origins = ["*"]. Authentifizierung gibt es nur, wenn --api-key oder VLLM_API_KEY gesetzt ist. Das Advisory beschreibt die Folge nüchtern: Eine beliebige Webseite kann über den Browser eines Mitarbeiters Anfragen an einen vLLM-Server stellen, den dieser Browser erreicht – localhost, eine interne Adresse, ein VPN-Ziel – und die Antworten lesen.

Übersetzt: Der Browser wird zum Proxy ins interne Netz. Ein Server, der „nur intern" erreichbar ist und deshalb keinen Schlüssel hat, ist für jede Webseite erreichbar, die ein Mitarbeiter öffnet. Die Seite kann die Modellliste auslesen, Anfragen absetzen, GPU-Zeit verbrauchen. Cookies spielen keine Rolle, weil vLLM über einen Bearer-Header authentifiziert; ohne Schlüssel gibt es schlicht nichts zu umgehen.

Ab 0.32 ist die Standardliste leer. Fremde Herkünfte bekommen keinen Access-Control-Allow-Origin-Header mehr, Preflight-Anfragen für JSON werden nicht autorisiert. Wer bewusst eine Browser-Anwendung direkt mit vLLM sprechen lässt, muss die Herkunft jetzt ausdrücklich freigeben. Das Argument ist eine JSON-Liste:

# Prüfen, was der laufende Server antwortet (Preflight von fremder Herkunft)
curl -s -i -X OPTIONS http://127.0.0.1:8000/v1/chat/completions \
  -H 'Origin: https://irgendwas.example' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: content-type,authorization' | grep -i '^access-control'

# 0.31 mit Standard:  access-control-allow-origin: *   -> jede Webseite darf lesen
# 0.32 mit Standard:  keine Zeile                       -> Browser blockiert

# Nur wenn eine Web-Oberfläche direkt mit vLLM spricht: Herkunft ausdrücklich freigeben
vllm serve /models/qwen3-27b --api-key "$(cat /etc/vllm/api-key)" \
  --allowed-origins '["https://chat.firma.local"]'

In der Praxis spricht kaum eine Oberfläche direkt mit vLLM. Open WebUI, ein Gateway oder ein eigenes Backend rufen den Server serverseitig auf, und dafür ist CORS bedeutungslos. Prüfen Sie trotzdem, ob nach dem Update eine selbstgebaute Testseite oder ein Entwickler-Notebook im Browser plötzlich scheitert – das ist dann kein Fehler, sondern die neue Voreinstellung. Und das Advisory sagt es selbst: CORS ersetzt keine Authentifizierung. Ein API-Schlüssel gehört auf jeden vLLM-Server, auch auf den internen.

/05Bestandsaufnahme in zehn Minuten: Version, Python, Flags, Ghostscript

Bevor Sie aktualisieren, halten Sie fest, was läuft. Die Befehle gehen von einem Container namens vllm aus; für eine Installation in einer virtuellen Umgebung ersetzen Sie docker exec vllm durch den Pfad zum Python der Umgebung.

# 1) vLLM-, Python-, PyTorch- und Pillow-Version im laufenden Container
docker exec vllm python3 -c "import sys, vllm, torch, PIL; \
print('vllm', vllm.__version__, '| python', sys.version.split()[0], \
'| torch', torch.__version__, '| pillow', PIL.__version__)"

# 2) Mit welchen Argumenten läuft der Server? Die Flags aus der Prüfliste herausfiltern
docker inspect vllm --format '{{json .Args}}' | tr ',' '\n' | \
  grep -nE 'mm-processor-cache-type|chat-template|api-key|allowed-origins|kv-transfer|tensor-parallel'
docker exec vllm sh -c 'env | grep -E "^VLLM_(API_KEY|ALLOW_INSECURE)" | sed "s/=.*/=…gesetzt/"'

# 3) Ghostscript im Image? (EPS-Kette braucht es)
docker exec vllm sh -c 'command -v gs >/dev/null && gs --version || echo "kein Ghostscript"'

# 4) Welche Modelle werden bedient? (Llama-2-Familie, OCR, Phi-4-multimodal?)
curl -s -H "Authorization: Bearer $(cat /etc/vllm/api-key)" \
  http://127.0.0.1:8000/v1/models | python3 -m json.tool | grep '"id"'

# 5) Welcher Image-Digest läuft? (für den Rückweg notieren)
docker inspect vllm --format '{{.Image}} {{.Config.Image}}'

Deutung der Ausgaben: Steht in Schritt 1 eine Version unter 0.32.0, gilt die Prüfliste. Steht dort Python 3.10, kommt die Umgebung nicht mit auf 0.32 – das betrifft vor allem pip-Installationen auf älteren Distributionen, nicht das offizielle Image. Findet Schritt 2 shm, ist die Pickle-Lücke relevant. Findet er kein --api-key und Schritt 2b keine Variable, ist der Server ohne Schlüssel unterwegs – das ist unabhängig von 0.32 der erste Befund. Liefert Schritt 3 eine Ghostscript-Version unter 10.03.1 und bedient der Server ein Bildmodell, ist die EPS-Kette offen. Pillow 12.0.0 bis 12.2.0 bedeutet die zusätzliche DoS-Variante.

Schreiben Sie die Ausgabe in Ihr Betriebshandbuch. Beim nächsten Advisory sparen Sie sich die Hälfte der Arbeit, weil die Bedingungen in der rechten Spalte fast immer dieselben sind: welches Modell, welche Flags, welche Bibliotheken.

/06Update-Ablauf 0.31 auf 0.32: Docker und virtuelle Umgebung

Das Update selbst ist unspektakulär, wenn Sie den Rückweg vorher anlegen. Die Reihenfolge: neues Image ziehen, Digest festhalten, alten Container umbenennen statt löschen, neuen mit gleicher Konfiguration starten, Gegenprobe, alten Container erst nach einer Woche entfernen.

# Docker: Image ziehen und Digest festhalten
docker pull vllm/vllm-openai:v0.32.0
docker image inspect vllm/vllm-openai:v0.32.0 --format '{{index .RepoDigests 0}}' | tee -a /etc/vllm/digests.log

# Alten Container behalten, neuen mit identischen Argumenten starten
docker stop vllm && docker rename vllm vllm-0.31
docker run -d --name vllm --gpus all --restart unless-stopped \
  -p 127.0.0.1:8000:8000 --ipc=host \
  -e VLLM_API_KEY="$(cat /etc/vllm/api-key)" -e VLLM_NO_USAGE_STATS=1 \
  -v /models:/models:ro \
  vllm/vllm-openai:v0.32.0 \
  --model /models/qwen3-27b --served-model-name assistent \
  --chat-template /models/qwen3-27b/chat_template.jinja

# Gegenprobe: Gesundheit, Schlüsselpflicht, eine echte Antwort
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/health          # 200
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/v1/models       # 401 ohne Schlüssel
curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H "Authorization: Bearer $(cat /etc/vllm/api-key)" -H 'Content-Type: application/json' \
  -d '{"model":"assistent","messages":[{"role":"user","content":"Antworte mit OK."}],"max_tokens":5}'

# Rückweg, falls etwas klemmt
docker rm -f vllm && docker rename vllm-0.31 vllm && docker start vllm

Das --chat-template in der Startzeile ist kein Zufall. Ein fest gesetztes Template schließt den Angriffsweg der beiden Jinja-Advisories auch für den Fall, dass Sie später auf eine Version zurückfallen müssen. Prüfen Sie aber, dass die Datei dem Template des Modells entspricht; ein falsches Chat-Template verschlechtert die Antworten leise, ohne dass ein Fehler erscheint.

Für Installationen ohne Docker gilt dasselbe Prinzip mit einer zweiten Umgebung. Die Release Notes nennen uv pip install vllm --torch-backend=auto; 0.32.0 verlangt Python 3.11 bis 3.14.

# Neue Umgebung neben der alten (Python 3.11 oder neuer)
uv venv /opt/vllm-0.32 --python 3.12
uv pip install --python /opt/vllm-0.32/bin/python "vllm==0.32.0" --torch-backend=auto
/opt/vllm-0.32/bin/python -c "import vllm; print(vllm.__version__)"   # 0.32.0

# systemd auf die neue Umgebung umstellen, alte bleibt als Rückweg liegen
sudo systemctl edit vllm.service     # ExecStart=/opt/vllm-0.32/bin/vllm serve …
sudo systemctl daemon-reload && sudo systemctl restart vllm
journalctl -u vllm -b --no-pager | tail -20

Rechnen Sie für einen Server mit einem 27B-Modell mit einer Unterbrechung von einigen Minuten – Gewichte laden, CUDA-Graphen erzeugen. Wer zwei Instanzen hinter einem Gateway betreibt, aktualisiert nacheinander und hat keine Unterbrechung. Der Durchsatz nach dem Update sollte gleich bleiben oder steigen; belastbar wissen Sie das nur nach einer Messung mit Ihrem eigenen Prompt-Mix.

/07Breaking Changes und Stolpersteine – und wann das Update warten kann

Die Release Notes listen acht Breaking Changes. Für einen typischen Mittelstands-Server sind vier relevant:

• Python 3.10 entfällt. requires-python ist jetzt >=3.11,<3.15. Ubuntu 22.04 bringt als System-Python 3.10 mit; wer dort vLLM direkt ins System-Python installiert hat, braucht eine neue Umgebung. Das offizielle Image ist nicht betroffen.
• CORS-Standard leer. Browser-Clients, die direkt mit vLLM sprechen, brauchen --allowed-origins. Serverseitige Clients merken nichts.
• max_tokens wird nicht mehr vom Kontextfenster reserviert. Anfragen, die bisher wegen zu langer Eingabe plus max_tokens abgelehnt wurden, laufen jetzt womöglich an und brechen später ab. Prüfen Sie Fehlerraten und Abbruchgründe in den ersten Tagen.
• Feste Abhängigkeiten: transformers>=5.16.1,<5.20.0 und tokenizers>=0.23.2. Wer eigene Pakete in dieselbe Umgebung installiert, riskiert Konflikte – ein weiterer Grund für eine getrennte Umgebung je Version.

Dazu kommt ein Punkt, der nicht in den Breaking Changes steht: Das Standard-Image ist mit CUDA 13.0 gebaut. Für Hosts mit älterem Treiber gibt es das Tag v0.32.0-cu129. Welche Treiberversion CUDA 13 verlangt, steht in NVIDIAs Kompatibilitätstabelle; prüfen Sie nvidia-smi, bevor Sie das Standard-Image ziehen. Wer Reasoning-Ausgaben über die Responses-API streamt, muss die umbenannten Ereignisse im Client nachziehen.

Wenn Sie heute nicht aktualisieren können

Ein Release mit Breaking Changes lässt sich nicht immer am Montag einspielen. Diese Schritte senken das Risiko bis zum Wartungsfenster, ohne die Version zu ändern:

1. API-Schlüssel setzen, falls keiner da ist. Das entschärft CORS und erhöht die Hürde für alle Fälle mit „angemeldetem Aufrufer".
2. --mm-processor-cache-type shm entfernen, wenn gesetzt. Der Standard-Cache ist nicht betroffen; Sie verlieren etwas Durchsatz bei Bildlasten.
3. Ghostscript aus dem Image entfernen oder auf 10.03.1 oder neuer bringen; Pillow auf 12.3.0.
4. Ein festes --chat-template setzen.
5. Am Reverse-Proxy nur die Routen durchlassen, die Ihre Anwendungen nutzen – meist /v1/chat/completions, /v1/models, /health. /inference/v1/generate, /v1/responses und die LoRA-Ladepfade bleiben zu, solange niemand sie braucht.

Ehrlich: Für einen Server, der nur intern erreichbar ist, einen Schlüssel hat, ein Textmodell wie Qwen3 bedient und keinen SHM-Cache nutzt, bleiben von neun Hinweisen im Kern die beiden Jinja-Fälle – und die setzen einen angemeldeten Aufrufer voraus. Dort darf das Update auf das nächste reguläre Wartungsfenster warten. Wer Ollama statt vLLM betreibt, ist von keinem dieser Hinweise betroffen.

/08Entscheidung: sofort, im Wartungsfenster oder später

Die Prüfliste aus Abschnitt /02 und die Ausgaben aus Abschnitt /05 ergeben drei Fälle. Die Zuordnung richtet sich nicht nach der Größe des Hauses, sondern nach dem, was der Server bedient und wer ihn erreicht.

Die meisten Mittelständler mit einem einzelnen Textmodell landen in der dritten Zeile. Das ist kein Freibrief: Wer heute nicht aktualisiert, sollte die Bestandsaufnahme trotzdem machen, weil sie zeigt, ob der Server überhaupt so konfiguriert ist, wie alle glauben. Ein fehlender API-Schlüssel ist der häufigste Befund und verschiebt den Server sofort in die erste Zeile.

Wo die Schwelle für „sofort" liegt, hängt auch davon ab, wie schnell Angreifer heute aus einem Advisory einen Angriff bauen. Das BSI hat dazu im September gewarnt; die Einordnung steht im Artikel zum Patch-Fenster. Für die beiden hohen Lücken liegen die Details öffentlich in den Advisories, samt betroffener Codezeilen.

/09Aus dem Einzelfall eine Routine machen

vLLM erscheint derzeit etwa alle zwei Wochen: 0.30.0 am 22. September, 0.31.0 am 5. Oktober (was diese Version lokal ändert: vLLM 0.31 und die Ollama-Websuche), 0.32.0 am 18. Oktober. Die Advisories folgen teils Tage später und gelten oft rückwirkend für mehrere Versionen. Am 6. und 9. Oktober hat das Projekt bereits mehrere Hinweise mit Fix in 0.31.0 oder älter veröffentlicht. Wer jedes Release als Einzelereignis behandelt, ist dauerhaft im Rückstand.

Eine Routine braucht drei Dinge. Erstens eine maschinenlesbare Quelle: Die Advisories lassen sich über die GitHub-API abfragen, etwa mit gh api repos/vllm-project/vllm/security-advisories --jq '.[] | [.published_at, .severity, .ghsa_id, .summary] | @tsv', und in einen täglichen Bericht schreiben. Zweitens die dokumentierte Startkonfiguration aus Abschnitt /05, gegen die jeder neue Hinweis in fünf Minuten geprüft ist. Drittens ein festes Wartungsfenster mit Rückweg, damit „im nächsten Fenster" ein Datum hat.

Zur Einordnung des Aufwands: vLLM ist ein Open-Source-Projekt mit hohem Tempo, und die Zahl der Advisories ist auch ein Zeichen dafür, dass Forscher genau hinsehen und das Projekt Meldungen bearbeitet. Das ist besser als ein ruhiges Projekt, in dem niemand sucht. Es heißt aber, dass ein On-Premise-Inferenzserver dieselbe Patch-Disziplin braucht wie ein Mailserver. Die GPU ist teuer, die Software darauf ändert sich alle zwei Wochen.

Das ist keine Formsache: Von neun Hinweisen dieser Runde betreffen sechs Funktionen, die nur ein Teil der Häuser nutzt. Wer seine Konfiguration kennt, kann zwei Drittel der Liste in Minuten abhaken und den Rest gezielt behandeln. Wer sie nicht kennt, muss alles sofort einspielen – mit allen Breaking Changes auf einmal.