Ein Supply-Chain-Angriff auf ein KI-Tool trifft AWS, Siemens, Airbus und John Deere. Was das mit Zero-Trust in der Fertigung zu tun hat.
Der Vorfall
Am 19. März 2026 kompromittiert die Gruppe „TeamPCP“ mit gestohlenen Zugangsdaten Trivy, einen weit verbreiteten Open-Source-Vulnerability-Scanner. Trivy selbst ist nicht das eigentliche Ziel – es ist das Werkzeug, mit dem die Angreifer weiterkommen.
LiteLLM, ein populäres Open-Source-Gateway zum Routen von Anfragen an verschiedene KI-Modelle, installiert Trivy automatisch in seiner Build-Pipeline. Der vergiftete Scanner bekommt dadurch Lesezugriff auf die CI-Runner-Umgebung von LiteLLM – und damit auf die PyPI-Publishing-Tokens des Projekts.
Am 24. März veröffentlichen die Angreifer zwei manipulierte LiteLLM-Versionen (1.82.7 und 1.82.8) auf PyPI, dem zentralen Python-Package-Index. In einem Zeitfenster von rund 40 Minuten, in dem die Dependency kompromittiert war, laden über 430.000 Systeme weltweit die manipulierte Version herunter und werden dabei selbst zu Datenquellen für die Angreifer.
Das Ausmaß
Die Threat-Intelligence-Firma Hudson Rock hat das daraus entstandene Datenpaket analysiert: 153 GB, 433.909 Dateien, zurückgeführt auf 118.829 CI-Runner-Dumps aus 2.488 unterschiedlichen Firmendomains. Unter den betroffenen Organisationen finden sich Namen wie AWS, Samsung Electronics, Salesforce, Cisco, Siemens, Airbus, John Deere, S&P Global und Deloitte.
Erbeutet wurden unter anderem AWS Secret Access Keys, Salesforce-Tokens, Microsoft-Azure-Credentials und API-Keys diverser KI-Anbieter. Ein Teil dieser Zugangsdaten war laut den Sicherheitsforschern auch Monate nach dem eigentlichen Angriff im März noch gültig.
Warum mich das als Fertigungs-IT-Praktiker nicht überrascht
Der eigentliche Fehler in dieser Kette ist nicht „schlechter Code“. Es ist implizites Vertrauen zwischen Systemen, die eigentlich nichts miteinander zu tun haben sollten. Ein Vulnerability-Scanner bekommt automatisch Zugriff auf eine Build-Pipeline. Die Build-Pipeline bekommt automatisch Zugriff auf Publishing-Tokens. Die Tokens erlauben automatisch das Ausrollen an Hunderttausende Systeme. Niemand hat an einer einzigen Stelle bewusst „ja, dieser Zugriff ist in Ordnung“ entschieden – es war einfach die Standardkonfiguration.
Genau dieses Muster sehe ich in der Fertigungs-IT ständig, nur mit anderen Beteiligten: eine Maschinensteuerung, die „der Einfachheit halber“ auch vom Büronetz erreichbar ist. Ein Fernwartungszugang, der dauerhaft offen bleibt, weil ihn niemand mehr abschaltet. Eine Automatisierungssoftware, die am Ende an dieselben Cloud-Dienste hängt wie die IT – ohne dass jemand die Grenze klar gezogen hätte.
Was ich in der Praxis anders mache
Bei Edge-Gateways für Maschinenanbindung setze ich grundsätzlich auf Outbound-only-Verbindungen. Das Gerät oder Gateway baut die Verbindung selbst nach außen auf – niemand kann von außen initiativ eingehend zugreifen. Das reduziert die Angriffsfläche deutlich, gerade weil Maschinen im industriellen Umfeld oft nicht direkt exponiert werden dürfen und auch nicht müssen.
Konkret sieht das in einer Umgebung nach IEC 62443 Zones & Conduits so aus:
- Jede Netzwerk-Zone hat genau einen definierten Übergang (Conduit) zur nächsten Zone – keine impliziten Nebenwege
- Maschinennetz und IT-Netz sind physisch getrennt, nicht nur per VLAN
- Kommunikation läuft verschlüsselt (z. B. TLS-gesicherter MQTT-Broker), nicht über offene, unauthentifizierte Ports
- Kein Dienst und kein System vertraut einem anderen automatisch nur deshalb, weil es „zur gleichen Infrastruktur gehört“
Das ist mehr Aufwand beim Aufbau. Aber es bedeutet auch: Wenn irgendwo in der Kette – bei einem Zulieferer, in einer Software-Dependency, bei einem Dienstleister – etwas kompromittiert wird, bleibt der Schaden lokal begrenzt, statt sich automatisch über 430.000 Systeme zu verteilen.
Die eigentliche Lehre
Der LiteLLM-Fall ist ein Software-Supply-Chain-Vorfall, kein OT-Vorfall im engeren Sinn. Aber die Mechanik ist identisch mit dem, was in vielen Produktionsnetzwerken als Risiko unterschätzt wird: Vertrauen, das nie explizit vergeben, sondern nur nie hinterfragt wurde. Wer heute Maschinen, Gateways oder Automatisierungssoftware anbindet, sollte sich genau diese Frage stellen – nicht erst, wenn eine Meldung wie diese in den News auftaucht.
Quelle: Hudson Rock, „Largest AI Supply Chain Breach of 2026: LiteLLM Hack Impacts Thousands of Global Enterprises“, hudsonrock.com/litellm; Help Net Security, „153GB of stolen credentials surface after LiteLLM supply chain attack“.