LMDeploy SSRF-Lücke in 13 Stunden ausgenutzt – KI-Stacks betroffen

Stellen Sie sich einen Hotelconcierge vor, der jedes Paket von jeder beliebigen Adresse abholt, die Sie auf eine Serviette kritzeln – ohne Nachfragen, ohne Adressprüfung. Genau das hat LMDeploys load_image()-Funktion in produktiven KI-Stacks getan. Und dreizehn Stunden nachdem die Schwachstelle öffentlich benannt wurde, spazierte jemand herein und durchwühlte das Hinterbüro.

Dreizehn Stunden. Das ist das Zeitfenster zwischen der öffentlichen Offenlegung von CVE-2026-33626 und den ersten in freier Wildbahn entdeckten Ausnutzungsversuchen. Die Concierge-Metapher wird uns weiter begleiten, denn der Kern dieser Geschichte dreht sich darum, wem man vertraut, etwas in seinem Namen zu holen – und was man ihn auf dem Rückweg berühren lässt.

Die Zahlen

Die Schwachstelle steckt in LMDeploy, einem Open-Source-Toolkit zur Verwaltung großer Sprachmodelle. Wie SC Media berichtete, handelt es sich um eine Server-Side Request Forgery-Lücke im Vision-Language-Modul. Der verwundbare Code-Pfad ist load_image(), der URLs abruft, ohne zu prüfen, ob diese auf interne oder private IP-Adressen zeigen. Wer schon einmal eine SSRF in einem Webhook-Handler debuggt hat, kennt die Form des Problems, bevor er einen weiteren Satz liest.

Die Zahl dreizehn Stunden ist die, bei der Plattformverantwortliche aufhorchen sollten. Forscher bei Sysdig registrierten Ausnutzungsversuche innerhalb dieses Zeitfensters nach der öffentlichen Offenlegung. Zum Vergleich: Der grobe Branchenrichtwert für opportunistisches Scanning neu veröffentlichter CVEs lag historisch gesehen im Bereich von Tagen, bei Nischensoftware manchmal Wochen. Dreizehn Stunden bedeutet, dass die Angreifer entweder den Offenlegungsfeed in Echtzeit beobachteten oder bereits Fuzzer gegen KI-Infrastrukturen liefen, über die sie schon Bescheid wussten.

Was die Angreifer damit anstellten, ist das langweilige Detail – im Sinne von: Es ist klassisches SSRF-Handwerk. Port-Scanning interner Netzwerke, Zugriffe auf den AWS Instance Metadata Service zum Abgreifen von Cloud-Credentials, das Sondieren von Redis-Instanzen und Out-of-Band-DNS-Exfiltration, um Daten über die Namensauflösung zu schleusen, wenn direkte Verbindungen blockiert sind. Nichts davon ist neu. Neu ist der Einstiegspunkt: ein Vision-Language-Model-Endpunkt.

Ein Detail ist es wert, kurz innezuhalten: Die Ausnutzung umfasste mehrere Anfragen, die über verschiedene Vision-Language-Modelle verteilt wurden, um einer Erkennung zu entgehen. Das zeigt, dass die Angreifer die Deployment-Topologie von LMDeploy-Nutzern gut genug kannten, um zwischen Modellen innerhalb desselben Toolkits zu pivotieren – was entweder auf vorherige Aufklärung oder ein bereits in einschlägigen Kreisen des Internets geteiltes Playbook hindeutet.

Was wirklich neu ist

SSRF ist älter als die meisten Ingenieure, die dies lesen. Die Technik findet sich in OWASP-Materialien, die über ein Jahrzehnt zurückreichen, und jeder Backend-Entwickler, der jemals ein Feature zum "URL abrufen und Vorschau anzeigen" entwickelt hat, hat irgendwann auf einen privaten IP-Filter gestarrt und sich gefragt, ob er die CIDR-Bereiche richtig gesetzt hat. Was ist hier also wirklich anders?

Neu ist die Angriffsfläche selbst. KI-Inferenz-Toolkits wie LMDeploy entstammen der Forschung: Modell laden, Token erzeugen, etwas zum Laufen bringen. Vision-Language-Module akzeptieren URLs als Eingaben, weil das der Weg ist, einem Modell ein Bild zu übergeben, ohne die gesamte Nutzlast base64-kodiert durch eine JSON-Anfrage zu schicken. Die Bequemlichkeit ist die Schwachstelle. Das Toolkit tut genau das, was es verspricht.

Das zweite Neue ist das operative Tempo. Wer schon einmal erlebt hat, wie ein CVE an einem Freitagabend veröffentlicht wird, kennt die schmerzhafte Lücke zwischen öffentlicher Offenlegung und gepatschter Produktion. Dreizehn Stunden sind kurz genug, dass der klassische Patch-Management-Zyklus (prüfen, testen, planen, deployen) noch nicht einmal sein erstes Meeting abgehalten hat, bevor die Ausnutzung einsetzt. Für Teams, die LMDeploy hinter einem internen API Gateway betreiben und Cloud-Metadaten vom Inferenz-Pod aus erreichbar haben, bedeutet das ein verlorenes Wochenende.

Das dritte Neue, und jenes, das meiner Meinung nach am meisten zählt, ist das Zielprofil. AWS IMDS und Redis sind keine zufälligen Ziele. Es sind die Infrastrukturkomponenten, die Credentials und Session-State speichern. Ein Angreifer, der von einem modellausliefernden Endpunkt zu IMDS pivotieren kann, hat Ihren Inferenz-Cluster faktisch in einen Credential-Automaten verwandelt. Hugging Faces Deployment-Anleitungen haben jahrelang dafür geworben, Ingenieure in Richtung containerisierter Inferenz zu lenken – doch Container teilen Metadata-Services mit allem anderen im VPC, es sei denn, man sperrt IMDSv2 gezielt ab.

Der Concierge holt nicht mehr nur Pakete ab. Er wurde darauf hingewiesen, dass der Generalschlüsselschrank genau hinter seinem Tresen steht.

Was in der KI-Entwicklung bereits eingepreist ist

Die meisten erfahrenen Ingenieure, die dies lesen, haben bereits angenommen, dass KI-Tools – insbesondere die Open-Source-Schicht – ein Sicherheitsschuldenproblem haben. Das ist eingepreist. Das Modell-Hosting-Ökosystem wuchs schnell, priorisierte Forscher-Ergonomie und übernahm die Sicherheitshaltung akademischer Codebases. Niemand ist überrascht, dass eine SSRF in einem Vision-Language-URL-Fetcher aufgetaucht ist. Wenn überhaupt, ist die Überraschung, dass wir diesen exakten CVE nicht schon sechs Monate früher gesehen haben.

Was nicht eingepreist ist: die Geschwindigkeit der Waffenfähigmachung gegen KI-spezifische Infrastruktur. Das Dreizehn-Stunden-Fenster legt nahe, dass Angreifer KI-Toolkits nun als erstklassige Ziele behandeln, nicht als Nachgedanke. Das ist eine Verschiebung. Vor einem Jahr lautete die Annahme, dass opportunistische Scanner früher oder später KI-Stack-CVEs einholen würden. „Früher oder später" ist jetzt „vor dem Mittagessen am nächsten Tag".

Ebenfalls nicht eingepreist: die Tatsache, dass defensive Tools rund um KI-Inferenz noch unreif sind. Standard-WAF-Regeln wissen nicht, wie eine legitime Vision-Language-Anfrage aussieht. Netzwerkrichtlinien in den meisten Kubernetes-Deployments erlauben standardmäßig Pod-zu-IMDS-Traffic. Die in Anthropics Dokumentation und ähnlichen Quellen beschriebenen agentischen Muster setzen voraus, dass die Netzwerk-Egress-Frage bereits gelöst ist – auf der Modellauslieferungsschicht ist sie das jedoch oft nicht.

Die Gegenmeinung

Hier die unpopuläre These: Die Dreizehn-Stunden-Zahl bedeutet zwar Alarm, könnte aber auch bedeuten, dass das Erkennungs-Ökosystem endlich funktioniert. Sysdig hat die Ausnutzungsversuche entdeckt. Vor fünf Jahren hätte dieselbe Schwachstelle womöglich monatelang still ausgenutzt werden können, bevor jemand es bemerkte – weil niemand KI-Inferenz-Traffic mit denselben Instrumenten beobachtete, die auf traditionelle Web-Stacks gerichtet sind.

Der zweite Gegenpunkt: SSRF in load_image() ist ein behebbares Problem mit bekannter Form. IPs validieren, private Bereiche blockieren, IMDSv2 mit Hop-Limit eins erzwingen, Egress auf Netzwerkebene einschränken. Nichts davon erfordert die Erfindung neuer defensiver Ansätze. Das eigentliche Risiko ist nicht dieser CVE. Es ist der nächste – im nächsten KI-Toolkit, in einem Code-Pfad, den niemand geprüft hat, weil das Toolkit sechs Monate alt ist und jeden Dienstag ein neues Feature liefert.

Wer CVE-2026-33626 als Einzelfall behandelt, wird ihn patchen und weitermachen. Wer ihn als repräsentativen Querschnitt dessen behandelt, wie KI-Infrastruktur-Sicherheit im Jahr 2026 aussieht, wird anfangen, härtere Fragen zu jedem URL-Fetcher, jedem Tool-Use-Hook und jedem Modell zu stellen, das einen String entgegennimmt und daraus einen Netzwerkaufruf macht.

Wichtigste Erkenntnisse

• LMDeploy sofort patchen, wenn Sie das Vision-Language-Modul betreiben. Das Dreizehn-Stunden-Ausnutzungsfenster bedeutet, dass bei ungepatchten Deployments von einem Breach ausgegangen werden sollte.
• AWS IMDS auf Version 2 mit Hop-Limit eins für alle Inferenz-Pods sperren, nicht nur für die, von denen Sie denken, dass sie exponiert sind. Cloud-Metadaten sind das eigentliche Ziel der Angreifer.
• KI-Toolkit-URL-Fetcher als nicht vertrauenswürdige Egress-Punkte behandeln. Netzwerkrichtlinien sollten Pod-zu-privaten-Bereich-Traffic blockieren, sofern er nicht ausdrücklich erforderlich ist.
• Erkennung für Multi-Modell-Ausnutzungsmuster aufbauen. Die Angreifer in diesem Fall verteilten Anfragen über verschiedene Vision-Language-Modelle, um die Überwachung einzelner Endpunkte zu umgehen.
• Das Concierge-Vertrauensmodell – bei dem KI-Tools alles abrufen, worum sie gebeten werden – ist der Design-Fehler. Solange Validierung nicht standardmäßig auf Toolkit-Ebene verankert ist, sollte bei jeder neuen KI-Infrastrukturkomponente angenommen werden, dass sie mit einer ähnlichen Lücke ausgeliefert wird.