vLLM: Denial of Service durch übergrosse Logprob-Token-IDs im gRPC-Frontend

Zusammenfassung

vLLM 0.22.0 vor 0.24.0 enthält eine Denial-of-Service-Schwachstelle im Rust-gRPC-Frontend. Entfernte Angreifer können Generate- oder GenerateStream-Anfragen mit aktivierten Output-Logprobs und mehr als 128 Output-Candidate-Token-IDs senden, wodurch die Python-seitige Begrenzung umgangen wird. Dies löst eine fatale Sampler-Ausnahme aus, die den EngineCore-Prozess beendet, sodass der Inferenzdienst neu gestartet werden muss. Die Auswirkung beschränkt sich auf die Verfügbarkeit; eine Codeausführung oder ein Datenzugriff wird nicht behauptet. Der CVSS-v4.0-Wert beträgt 8.2 (Hoch), während der CNA CVSS v3.1 5.9 und Positive Technologies 7.5 angeben; die Schwere hängt somit davon ab, wie gut der gRPC-Endpunkt erreichbar ist.

Betroffen

• vLLM ab 0.22.0 vor 0.24.0 (gemäss GitHub-Advisory und CNA-Eintrag)
• Einige PyPI-Einträge nennen nur 0.22.0, 0.22.1 und 0.23.0
• Red Hat AI Inference Server 3 (Paket vllm-cpu): Korrektur verschoben
• Unbekannt, ob Gaudi-Plugins oder Container-Images separate Updates benötigen

Behoben in

• vLLM 0.24.0 (Eingabevalidierung korrigiert)
• Das Gaudi-Plugin v0.24.0 basiert auf vLLM v0.24.0

Umgehung

• Kein vom Hersteller dokumentierter Workaround gefunden.
• Bis zum Update den Zugriff auf den gRPC-Port auf vertrauenswürdige Netze oder einen authentifizierten Reverse Proxy beschränken.
• Clientseitige Validierung der Anfrageparameter hilft nur, wenn die Clients vertrauenswürdig und kontrolliert sind.

Ausnutzung

• Nicht bekannt, dass die Schwachstelle ausgenutzt wird; nicht im CISA-KEV-Katalog gelistet.
• CISA SSVC: Exploitation none, nicht automatisierbar.
• Bei den Recherchen wurde kein öffentlicher Proof of Concept gefunden; dies beweist nicht, dass keiner existiert.

Unsere Empfehlung

• Alle vLLM-Instanzen inventarisieren, einschliesslich Red-Hat- und Container-Deployments.
• Auf vLLM 0.24.0 oder neuer aktualisieren; Red Hat AI Inference Server separat prüfen, da die Korrektur verschoben ist.
• Prüfen, ob der gRPC-Endpunkt aus dem Internet oder aus nicht vertrauenswürdigen Netzen erreichbar ist, und den Zugriff einschränken.
• Auf unerwartete Neustarts von EngineCore beziehungsweise der Engine überwachen.
• Zusammen mit dem Update weitere am selben Tag veröffentlichte vLLM-DoS-Schwachstellen prüfen, etwa CVE-2026-116174.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• GitHub Security Advisory GHSA-6pgw-f3pv-4h8q github.com
• VulnCheck advisory www.vulncheck.com
• OSV PYSEC-2026-4350 osv.dev
• VulDB CVE-2026-116173 vuldb.com
• OpenCVE CVE-2026-116173 app.opencve.io
• Red Hat CVE record RH:CVE-2026-116173 vulners.com
• Positive Technologies PT-2026-132753 vulners.com
• vLLM Gaudi plugin release notes v0.24.0 docs.vllm.ai

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 15:04.