vLLM CVE-2026-93436: Nicht freigegebene Decode-Metadaten erschöpfen den Speicher bei getrennter Prefill/Decode-Verarbeitung

TL;DR — 90 Sekunden

vLLM räumt in Deployments mit getrennter Prefill- und Decode-Phase Metadaten abgelehnter Requests nicht auf. Ein einzelner Request mit max_tokens=0 lässt die _recving_metadata-Struktur auf Decode-Workern unbegrenzt wachsen, bis der Speicher erschöpft ist und der Worker neu startet. Kein Zugangsdatum ist nötig, Angriffsvektor ist das Netzwerk. Betroffen sind vLLM-Versionen bis 0.29.0 mit aktivierter NIXL-basierter Prefill/Decode-Trennung. Ein offizieller Fix ist in Arbeit (PR #55677), aber noch nicht gemerged oder veröffentlicht. Wer diese Deployment-Form nutzt, sollte Anfragen mit max_tokens=0 vorab filtern und die Speichernutzung der Decode-Worker überwachen.

Was ist das Problem?

vLLM unterstützt eine Deployment-Form, bei der Prefill- und Decode-Phase eines Sprachmodell-Requests auf getrennten Workern laufen (disaggregated prefill/decode), verbunden über den NIXL-Transport für Key-Value-Caches. Wird ein Request auf der Decode-Seite abgelehnt, bevor er vollständig eingeplant wurde, verbleiben leere Empfangsoperationen (empty receives) im Metadaten-Dictionary _recving_metadata des Workers, ohne dass sie jemals abgeschlossen oder bereinigt werden.

Ein Angreifer mit Zugriff auf die Inference-API kann gezielt Requests mit max_tokens=0 senden. Diese werden von vLLM abgelehnt, hinterlassen aber bei jeder Ablehnung einen weiteren Eintrag im Metadaten-Dictionary. Oft genug wiederholt, wächst der Speicherverbrauch des Decode-Workers unbegrenzt, bis der Prozess neu gestartet werden muss. Betroffen sind die Pfade über /v1/completions, /v1/chat/completions sowie direkte abort_immediately-Aufrufe der Engine bei aktiviertem Remote-Prefill.

Wer ist betroffen?

Betroffen sind vLLM-Deployments, die die experimentelle Prefill/Decode-Trennung über NIXL einsetzen und ihre Inference-Endpunkte für nicht vertrauenswürdige Anfragen erreichbar machen.

Standard-Deployments ohne aktivierte Prefill/Decode-Trennung nutzen den betroffenen Codepfad nicht und sind nicht direkt betroffen. Maßgeblich ist außerdem, ob die Inference-Endpunkte aus einem nicht vertrauenswürdigen Netz erreichbar sind.

Auswirkungen

Ein Angreifer mit Netzwerkzugriff auf die betroffenen Endpunkte kann ohne Zugangsdaten und ohne Nutzerinteraktion den Speicher eines Decode-Workers unbegrenzt aufblähen. Die Folge ist ein Denial of Service: Der Worker-Prozess stürzt ab oder muss manuell neu gestartet werden, laufende Inference-Anfragen anderer Nutzer werden dabei unterbrochen.

Vertraulichkeit und Integrität der verarbeiteten Daten sind nach aktuellem Kenntnisstand nicht betroffen. Das Risiko betrifft ausschließlich die Verfügbarkeit der Inference-Infrastruktur, was bei produktiv genutzten LLM-Diensten mit Nutzern oder nachgelagerten Systemen dennoch erheblich sein kann.

Mitigation / Sofortmaßnahmen

Eine feste Patch-Version stand zum Zeitpunkt dieses Artikels noch nicht fest. PR #55677 adressiert das Problem in push_worker.py und pull_worker.py, wartet aber noch auf ein Rebase und die Freigabe durch die Code-Owner.

Bis zur Veröffentlichung eines Fixes: Filtern Sie Requests mit max_tokens=0 an einem vorgeschalteten Reverse-Proxy oder API-Gateway heraus, bevor sie vLLM erreichen. Beschränken Sie den Zugriff auf Inference-Endpunkte mit aktivierter Prefill/Decode-Trennung auf vertrauenswürdige Netze oder authentifizierte Aufrufer. Erwägen Sie ein automatisiertes Neustart- und Watchdog-Verfahren für Decode-Worker, das ungewöhnliches Speicherwachstum erkennt und den Prozess kontrolliert neu startet, bevor der Speicher vollständig erschöpft ist.

Detection / Prüfung

Überwachen Sie die Speichernutzung Ihrer Decode-Worker-Prozesse kontinuierlich. Ein stetiger, nicht durch die tatsächliche Anfragelast erklärbarer Anstieg ist ein starkes Indiz für Ausnutzung. Prüfen Sie, sofern möglich, die Größe der internen _recving_metadata-Struktur während Lastspitzen mit vielen abgebrochenen Requests.

Werten Sie Zugriffslogs auf gehäufte Requests mit max_tokens: 0 im Anfrage-Body aus, insbesondere wenn diese von einer einzelnen Quelle in kurzer Folge eintreffen. Ein Muster aus vielen abgelehnten Requests unmittelbar vor einem Worker-Neustart bestätigt eine bereits erfolgte Ausnutzung.

Betreiberempfehlung

Akut handeln, wenn: Sie vLLM mit aktivierter Prefill/Decode-Trennung betreiben und die Inference-Endpunkte aus einem nicht vollständig vertrauenswürdigen Netz erreichbar sind. Filtern Sie max_tokens=0-Requests umgehend und richten Sie eine Speicherüberwachung mit Alarmierung ein.

Beobachten genügt, wenn: Sie vLLM ohne Prefill/Decode-Trennung betreiben oder die betroffenen Endpunkte ausschließlich aus einem vertrauenswürdigen internen Netz erreichbar sind. Verfolgen Sie den Fortschritt von PR #55677 und planen Sie das Update ein, sobald eine Patch-Version veröffentlicht ist.

Fazit

Der Fall zeigt ein bekanntes Muster bei neuen, funktional komplexen LLM-Serving-Architekturen. Getrennte Prefill- und Decode-Phasen bringen Performance-Vorteile, aber auch neue Zustände, die beim Entwurf der Fehlerbehandlung leicht übersehen werden. Bis der offizielle Fix erscheint, bleibt Filterung am Rand der Infrastruktur die wirksamste Absicherung.

Quellen

• VulnCheck: vLLM through 0.29.0 Memory Exhaustion via Rejected Requests
• GitHub: vllm-project/vllm PR #55677 (Fix, offen)
• NixOS/nixpkgs Issue #564522
• Strix: CVE-2026-93436