flawopen.com/Teardowns/cve-2026-105752-vllm-harmony-cache-salt-omission
CVE-2026-105752: fehlendes cache_salt in vLLM
Eine GPT-OSS-Werkzeugfortsetzung in vLLM Responses konnte cache_salt auslassen und einen ungesalzenen Prefix-Cache-Namensraum verwenden. Aktualisieren Sie auf vLLM 0.30.0 oder neuer und erhalten Sie mandantenspezifische Salts in jeder Fortsetzung.[1], [5]
Stellen Sie sich Unterlagen jedes Kunden in Schließfächern mit privaten Farbmarkierungen vor. Die erste Anfrage erhält die richtige Markierung, doch ein Werkzeug verliert sie beim Zurückgeben der Unterlagen für den nächsten Schritt. Ein gemeinsames Regal kann per Cache-Treffer anzeigen, ob vermutete Seiten bereits dort liegen; die Seiten selbst gibt es nicht heraus.[1]
Kernkonzepte & Begriffe
Prefix caching- Verwendet Modell-Schlüssel/Wert-Blöcke für gleiche Präfixe erneut.[6]
cache_salt- Wert im Hash des ersten Blocks zur Trennung von Caches mit unterschiedlichen Salts.[6]
Harmony continuation- Nächste Modelleingabe nach einer Harmony-Antwort, auch nach einem Werkzeugaufruf.[1]
Membership oracle- Signal für einen vermuteten Präfix, ohne dessen Inhalt offenzulegen.[1]
CWE-524- Verwendung eines Caches mit sensiblen Informationen; primäre Einstufung der Meldung.[1]
Framework-Zuordnungen
- CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-524
Ursachenanalyse
Die vLLM-Meldung beschreibt GPT-OSS Harmony unter POST /v1/responses. Die erste Engine-Eingabe übergab request.cache_salt an tokens_input; nach einem integrierten oder MCP-Werkzeugaufruf nutzte die Fortsetzung tokens_input(token_ids) ohne Salt. Der Helper speichert das Salt nur, wenn es übergeben wird. Mit automatischem Prefix-Caching in einer gemeinsamen Bereitstellung nutzte die Fortsetzung daher den ungesalzenen Namensraum. Die Meldung nennt Versionen vor 0.30.0, bestätigt das Verhalten auf 0.25.1 und sagt, dass die untere Grenze nicht feststeht. Das Ergebnis ist ein Cache-Mitgliedschaftssignal über cached_tokens_per_turn, keine direkte Offenlegung beliebigen Prompt-Texts. CWE-200 wird ebenfalls als Auswirkung genannt; hier ist CWE-524 die einzige primäre Schwachstelle.[1], [3], [4]
Schritt-für-Schritt Angriffsablauf
Ein gemeinsamer Dienst erfüllt die Voraussetzungen
Nötig sind eine betroffene Version, GPT-OSS Harmony Responses, Prefix-Caching und ein Werkzeug; das Opfer setzt cache_salt und erreicht eine Fortsetzung.[1]
Die erste Engine-Eingabe erhält das Salt
Der erste tokens_input-Aufruf enthält request.cache_salt und ordnet das Präfix dem gesalzenen Namensraum des Aufrufers zu.[1]
Die Werkzeugfortsetzung verliert das Salt
Nach dem Werkzeugergebnis ruft die Fortsetzung tokens_input(token_ids) ohne das ursprüngliche Salt auf; das Präfix kann im gemeinsamen ungesalzenen Namensraum landen.[1]
Ein Cache-Zähler kann Mitgliedschaft offenbaren
Ein Mitnutzer, der das Präfix rekonstruiert, kann cached_tokens_per_turn zur Mitgliedschaftsprüfung nutzen, aber keinen beliebigen Prompt abrufen.[1]
Quellcode: Verwundbar vs. Sicher
Die vLLM-Meldung beschreibt GPT-OSS Harmony unter POST /v1/responses. Die erste Engine-Eingabe übergab request.cache_salt an tokens_input; nach einem integrierten oder MCP-Werkzeugaufruf nutzte die Fortsetzung tokens_input(token_ids) ohne Salt. Der Helper speichert das Salt nur, wenn es übergeben wird. Mit automatischem Prefix-Caching in einer gemeinsamen Bereitstellung nutzte die Fortsetzung daher den ungesalzenen Namensraum. Die Meldung nennt Versionen vor 0.30.0, bestätigt das Verhalten auf 0.25.1 und sagt, dass die untere Grenze nicht feststeht. Das Ergebnis ist ein Cache-Mitgliedschaftssignal über cached_tokens_per_turn, keine direkte Offenlegung beliebigen Prompt-Texts. CWE-200 wird ebenfalls als Auswirkung genannt; hier ist CWE-524 die einzige primäre Schwachstelle. Upstream excerpts, not a literal line-by-line diff.[1], [3], [4], [7]
Quelltextauszug: vLLM Responses Harmony-Renderer (Auszüge verschiedener Revisionen)
# Der ursprüngliche Anfragepfad verwendete ein Salt, die Fortsetzung nach dem Tool-Aufruf jedoch nicht.
engine_input = tokens_input(token_ids, cache_salt=request.cache_salt)
# Nach einem Tool-Ergebnis baute die Fortsetzung die Eingabe so neu auf:
engine_input = tokens_input(token_ids)# Das Anfrage-Salt im Harmony-Rendering-Kontext beibehalten.
cache_salt = cast(str | None, engine_input.get("cache_salt"))
engine_input = self.online_renderer.render_responses_harmony_messages(
context.messages,
cache_salt=cache_salt,
tok_params=tok_params,
)
# Der Renderer übergibt das Salt, sobald er eine Eingabe für die Engine erstellt.
engine_input = tokens_input(prompt["prompt_token_ids"], cache_salt=cache_salt)Checkliste für Engineering & Systemsicherheit
- ✓Aktualisieren Sie auf vLLM 0.30.0 oder neuer und prüfen Sie die laufenden Versionen.[1], [5]
- ✓Erzeugen Sie am vertrauenswürdigen Gateway ein unvorhersehbares cache_salt und senden Sie es bei jeder Anfrage und Fortsetzung.[6], [1]
- ✓Testen Sie, dass jede Harmony-Fortsetzung nach Werkzeugaufrufen das Salt erhält und Mandanten trennt.[7]
- ✓Trennen Sie Mandanten bei strikter Isolation nach Prozess oder Bereitstellung.[6]
- ✓Prüfen Sie gemeinsame Funktionen und begrenzen Sie den Zugriff auf cached_tokens_per_turn.[1]
- ✓Beschreiben Sie das Risiko als Präfix-Inferenz, nicht als beliebige Prompt-Offenlegung.[1]