ShadowMQ: Kritische KI-Schwachstellen betreffen Meta, NVIDIA und weitere Unternehmen

Im Wettlauf um eine schnellere Einführung von KI verlassen sich Unternehmen zunehmend auf leistungsstarke Inferenzserver, um Modelle in großem Maßstab bereitzustellen. 

Doch das hohe Entwicklungstempo hat einen kritischen blinden Fleck offengelegt: Die grundlegende KI-Infrastruktur basiert häufig auf wiederverwendetem, übernommenem und unzureichend geprüftem Code. 

Sicherheitsforscher von Oligo Security haben aufgedeckt, dass sich Schwachstellen zur Remote-Code-Ausführung (RCE) über wichtige KI-Frameworks hinweg ausgebreitet haben – durch ein Muster, das das Team ShadowMQ nennt: eine verborgene Schwachstelle in der Kommunikationsschicht, die auf unsicheren Verfahren zur Deserialisierung mit ZeroMQ (ZMQ) und Python pickle beruht. 

Dieses Problem betrifft eine breite Palette branchenführender Projekte, darunter Metas Llama Stack, NVIDIA TensorRT-LLM, Microsofts Sarathi-Serve, vLLM, SGLang und Modular Max, und schafft gemeinsame, weit verbreitete Sicherheitsrisiken im gesamten KI-Ökosystem.

Die Entdeckung von ShadowMQ

Die Untersuchung begann 2024, als Oligo-Forscher ein unsicheres Muster in Metas Llama Stack identifizierten: Das Framework verwendete die recv_pyobj()-Methode von ZMQ, die Daten automatisch mithilfe von Pythons pickle-Modul deserialisiert. 

Da pickle während der Deserialisierung beliebigen Code ausführen kann, schafft sein Einsatz über nicht authentifizierte Netzwerk-Sockets einen direkten Weg zur RCE. 

Meta reagierte schnell, veröffentlichte CVE-2024-50050 und ersetzte pickle durch eine JSON-basierte Serialisierungsmethode.

Das Forschungsteam fand bald ähnliche Probleme an anderer Stelle. NVIDIA TensorRT-LLM, vLLM, SGLang und Modular Max verwendeten denselben – oder nahezu identischen – unsicheren Code erneut. 

In einigen Fällen wurden Dateien Zeile für Zeile von einem Projekt in ein anderes kopiert, einschließlich Kopfkommentaren, die auf ihren Ursprung hinwiesen. 

SGLang weist beispielsweise ausdrücklich darauf hin, dass eine anfällige Datei „Adapted from vLLM“ wurde – und damit nicht nur architektonische Optimierungen, sondern auch die fehlerhafte Deserialisierungslogik übernahm.

Die verborgenen Risiken der Code-Wiederverwendung in der KI

ShadowMQ veranschaulicht, wie sich Schwachstellen durch moderne KI-Entwicklungspraktiken unbemerkt verbreiten.

Framework-Maintainer übernehmen häufig Komponenten aus Projekten anderer Anbieter, um die Leistung zu optimieren und Releases zu beschleunigen. 

Diese Wiederverwendung ist nicht grundsätzlich schädlich. Werden jedoch unsichere Kommunikationsmethoden wie die auf pickle basierende Deserialisierung ohne Sicherheitsprüfung kopiert, übernimmt das gesamte Ökosystem dieselbe Schwachstelle.

Aufgrund der kaskadenartigen Ausbreitung von ShadowMQ kann eine einzige übersehene Schwachstelle zahlreiche Anbieter, Forschungseinrichtungen und Cloud-Provider erfassen.

Warum Inferenzserver bevorzugte Ziele sind

KI-Inferenzserver verarbeiten sensible Modell-Prompts, proprietäre Datensätze und Kundeneingaben über GPU-Cluster hinweg. 

Die Ausnutzung von ShadowMQ könnte Angreifern ermöglichen, beliebigen Code auszuführen, ihre Rechte auszuweiten, Modelle oder Geheimnisse abzuschöpfen und GPU-basierte Kryptominer wie jene aus der ShadowRay-Kampagne zu installieren.

Scans von Oligo enthüllten Tausende offener ZMQ-Sockets, die das einzigartige TCP-Banner des Protokolls über das öffentliche Internet verbreiteten – einige davon gehörten eindeutig zu produktiven Inferenzumgebungen. Ein einziger anfälliger Deserialisierungsaufruf könnte den gesamten KI-Betrieb kompromittieren.

Wie Anbieter auf ShadowMQ reagierten

Nach der koordinierten Offenlegung veröffentlichten mehrere große Anbieter zeitnah Patches:

• Meta Llama Stack (CVE-2024-50050) ersetzte pickle durch JSON.
• vLLM (CVE-2025-30165) beseitigte die unsichere Logik, indem die sichere V1-Engine zum Standard gemacht wurde.
• NVIDIA TensorRT-LLM (CVE-2025-23254) fügte eine HMAC-Validierung hinzu und erhielt die kritische Bewertung 9,3.
• Modular Max Server (CVE-2025-60455) führte msgpack für eine sichere Serialisierung ein.

Den Forschern zufolge wurden nicht alle Frameworks erfolgreich gepatcht. Microsofts Sarathi-Serve ist weiterhin anfällig, und die Korrekturen von SGLang sind nur teilweise wirksam. Diese fortbestehenden Schwachstellen stellen verborgene Schwachstellen dar – Probleme, die den Verteidigern bekannt sind, aber nicht behoben wurden und darauf warten, von Angreifern wiederentdeckt zu werden.

Warum sich unsicherer Code in KI-Projekten wiederholt

Das verbreitete Auftreten von ShadowMQ ist nicht auf Nachlässigkeit von Entwicklern zurückzuführen. Vielmehr spiegelt es die strukturellen Gegebenheiten des KI-Ökosystems wider:

• Leistungsdruck fördert die Übernahme von Code.
• Unsichere Methoden wie recv_pyobj() sind nicht mit deutlichen Warnungen versehen.
• Tools zur Code-Generierung reproduzieren häufig gängige, aber unsichere Muster.
• Sicherheitsprüfungen halten mit dem Tempo der rasanten KI-Innovation nicht Schritt.

Infolgedessen kann sich eine einzige anfällige Implementierung unbemerkt über Dutzende von Repositories verbreiten.

Wichtige Schritte zur Absicherung der KI-Infrastruktur

Da die Schwachstellen von ShadowMQ sowohl auf unsicheren Standardeinstellungen als auch auf übernommenem Code beruhen, müssen Unternehmen proaktive Maßnahmen ergreifen, um ihre KI-Infrastruktur abzusichern.

• Alle KI-Inferenzframeworks auf die neuesten sicheren Versionen aktualisieren und wiederverwendeten oder übernommenen Code kontinuierlich auf unsichere Muster prüfen.
• Unsichere Serialisierung beseitigen durch den Verzicht auf pickle oder /recv_pyobj() bei nicht vertrauenswürdigen Daten sowie durch die Durchsetzung sicherer Formate wie JSON, msgpack oder protobuf.
• Die gesamte ZMQ- und Interservice-Kommunikation absichern – durch vorgeschriebene Authentifizierung (HMAC/TLS), verschlüsselte Kanäle und die Verhinderung einer öffentlichen Erreichbarkeit durch strikte Netzwerksegmentierung und Firewall-Regeln.
• Zugriffe beschränken und die Infrastruktur härten durch den Verzicht auf tcp://*, die Beschränkung von ZMQ-Endpunkten auf vertrauenswürdige Netzwerke, die Isolierung von Inferenzservern durch Container-Härtung und die Anwendung von Zero-Trust-Prinzipien.
• Überwachung und Erkennung verbessern durch Protokollierung, Anomalieerkennung, EDR/XDR-Abdeckung, die Suche nach offenen Endpunkten und Warnmeldungen bei ungewöhnlichem Deserialisierungs- oder Protokollverhalten.
• Entwicklungs- und Engineering-Teams schulen in Bezug auf Risiken der Serialisierung, sichere Kommunikationspraktiken und die Gefahren der Code-Wiederverwendung, unterstützt durch CI-Prüfungen oder Richtlinien, die unsichere Muster blockieren.

Durch die Umsetzung dieser Gegenmaßnahmen und die Stärkung sicherer Entwicklungs-, Kommunikations- und Infrastrukturpraktiken können Unternehmen ihre Cyberresilienz gegen Schwachstellen im Stil von ShadowMQ erhöhen.

Übernommene Schwachstellen im KI-Stack

ShadowMQ zeigt, dass moderne KI-Infrastrukturen Sicherheitslücken häufig übernehmen, statt sie von Grund auf neu zu schaffen. 

Da Unternehmen Open-Source-Komponenten in beispiellosem Tempo integrieren, können sich Schwachstellen unbemerkt über Frameworks, Clouds und Unternehmensumgebungen hinweg verbreiten. 

Um diese Risiken zu mindern, muss der KI-Stack mit derselben Sorgfalt behandelt werden wie jedes andere kritische System – durch die Prüfung wiederverwendeten Codes, die Durchsetzung sichererer Kommunikationsmuster und die Priorisierung sicherer Serialisierung.

Diese zunehmende Abhängigkeit von gemeinsam genutztem, übernommenem Code macht deutlich, dass die Absicherung des KI-Ökosystems mit der Stärkung der Software-Lieferkette beginnt, von der Entwickler abhängen.