open source Vllm: Code-Injection (CVE-2026-114053)

Zusammenfassung

Eine nicht vertrauenswürdige multimodale Anfrage kann mm_processor_kwargs.code_revision setzen. Wenn vLLM ein Modell bedient, dessen Hugging Face-Verarbeiter dynamischen auto_map-Code verwendet und der Betreiber --trust-remote-code aktiviert hat, erreicht dieser Anfrage-Wert AutoProcessor.from_pretrained und wählt die Python-Revisionsversion aus, die von Transformers importiert wird.

Dies ermöglicht es einem Client, den vom Betreiber überprüften Verarbeitungsmodul durch Code aus einer anderen Revision desselben Modellrepositorys zu ersetzen. Die vom Betreiber ausgewählte Modell/Daten revision bleibt gesperrt; nur der ausgeführte Verarbeitungscode ändert sich.

Das Importieren eines Python-Moduls ist eine beliebige Code-Ausführung im vLLM-API/Renderer-Prozess. Das PoC unten demonstriert dies mit einer Dateisystem-Schreiboperation zur Importzeit. Es ist vollständig offline und erfordert kein GPU, keine Modellgewichte oder Änderungen an einem realen Hub-Repository.

Betroffene Momentaufnahme

• Repository: vllm-project/vllm
• Überprüfter Commit: 570735520942b6428ae98f1eb442c6d88adae55e
• Überprüft mit Transformers 5.15.0 und 5.16.1
• Der betroffene Versionsbereich wurde nicht bis zu einem bestimmten Punkt eingegrenzt

Betroffene Konfiguration

Der anfällige Pfad existiert, wenn alle folgenden Bedingungen erfüllt sind:

1. Das bediente Modell verwendet dynamischen auto_map.AutoProcessor-Code.
2. Der Betreiber hat trust_remote_code aktiviert.
3. Der Server kann die vom Anfragen ausgewählte Revision abrufen, oder sie ist bereits zwischengespeichert.
4. Der Angreifer kann eine Revision im bedienten Modellrepository erstellen oder anderweitig kontrollieren. Ein Beispiel ist ein Hugging Face Community Pull-Request-Ref, wenn dieses Repository sie zulässt.
5. Eine multimodale Anfrage erreicht den Verarbeitungspfad.

Die Standardkonfiguration trust_remote_code=False ist nicht betroffen.

Angriffsfläche

mm_processor_kwargs wird direkt von öffentlichen Anfragemodellen akzeptiert:

• TokenizeChatRequest.mm_processor_kwargs
• ChatCompletionRequest.mm_processor_kwargs

/tokenize ist besonders relevant, da die Authentifizierungsmiddleware von vLLM nur die Präfixe /v1, /v2, /inference, und /cohere schützt:

• AuthenticationMiddleware

Folglich bleibt /tokenize auch dann unauthentifiziert, wenn --api-key konfiguriert ist, es sei denn, ein externer Proxy schützt es. Die vLLM Security Guide dokumentiert /tokenize als einen ungeschützten Endpunkt.

Ursache

Der Anfrage-Wert folgt diesem Pfad:

1. OnlineRenderer.preprocess_chat platziert die Anfrage mm_processor_kwargs in den Prompt-Extras.
2. Die multimodale Darstellung leitet diese kwargs in die Verarbeitungskonstruktion durch MMProcessorInputs und _process_multimodal_async weiter.
3. MultiModalConfig.merge_mm_processor_kwargs legt die Anfrage-Werte auf die Startwerte, so dass die Anfrage gewinnt.
4. cached_get_processor_without_dynamic_kwargs filtert nur anerkannte Verarbeitungsaufzuruf-Schlüssel. code_revision wird als Verarbeitungskonstruktions-Argument beibehalten.
5. cached_processor_from_config sperrt revision und trust_remote_code, leitet jedoch die verbleibenden kwargs weiter, ohne code_revision zu reservieren.
6. get_processor ruft AutoProcessor.from_pretrained(..., revision=revision, trust_remote_code=trust_remote_code, **kwargs) auf.
7. Transformers AutoProcessor.from_pretrained verwendet code_revision, um das dynamische Modul über get_class_from_dynamic_module abzurufen und zu importieren, bevor es vor dem Laden der Verarbeitungsdaten entfernt wird. Dies ist der Grund, warum der Code aus der Angreifer-Revision stammt, während die Konfiguration/Daten vom Betreiber gesperrt bleiben.

Die Verarbeitungsargumente zur Anfragedauer werden nicht von den Verarbeitungskonstruktionsargumenten getrennt, und code_revision wird nicht reserviert.

Vorgeschlagene Gegenmaßnahme

1. Trennen Sie die Verarbeitungskonstruktionsargumente von den nicht vertrauenswürdigen Verarbeitungsaufzuruf-Argumenten. Eine Erlaubnisliste unterstützter Anfragedauer-Vorverarbeitungskontrollen ist am sichersten.
2. Ablehnen Sie code_revision und andere Lader/Quellensteuerungen in der Anfrage mm_processor_kwargs und übergeben Sie model_config.code_revision explizit als die einzige zulässige Verarbeitungscode-Revisionsversion.
3. Fügen Sie einen Regressions-Test hinzu, der beweist, dass eine Anfrage die geladene Modulrevision nicht ändern kann, während die vom Betreiber gesperrten Pinnungen wirksam bleiben.
4. Schützen Sie /tokenize mit der konfigurierten Authentifizierungspolitik als Verteidigung in der Tiefe.

Das erwartete sichere Verhalten ist entweder eine 4xx-Antwort für reservierte Anfrageschlüssel oder das stille Ignorieren von ihnen vor der Verarbeitungskonstruktion. Die Ablehnung ist vorzuziehen, da sie versuchte Fehlverwendung sichtbar macht.

Ein Patch für dieses Problem wurde hier zusammengeführt: https://github.com/vllm-project/vllm/pull/58830