Ein ganz normaler Dienstagmorgen – bis die Alerts kamen

Stellen Sie sich folgendes Szenario vor: Stefan Krämer, IT-Leiter eines mittelständischen Maschinenbauers mit 450 Mitarbeitenden in der Nähe von Stuttgart, startet seinen Dienstag wie jeden Morgen mit einem Blick auf das Monitoring-Dashboard. Das Entwicklerteam hat in den letzten Monaten einen KI-gestützten Assistenten aufgebaut, der die technische Dokumentation durchsuchbar macht und Servicetechniker im Außendienst unterstützt. Im Kern der Architektur: LiteLLM – eine Open-Source-Bibliothek, die als universelle Schnittstelle zwischen der Anwendung und verschiedenen KI-Modellen fungiert.

Als Stefan gegen 9:15 Uhr eine Warnung des Netzwerk-Monitoring-Systems bemerkt, die ungewöhnlichen ausgehenden Datenverkehr auf Port 443 zu einer unbekannten IP-Adresse in Osteuropa meldet, beginnt ein Tag, den er so schnell nicht vergessen wird. Die Quelle: der Kubernetes-Pod, in dem der KI-Assistent läuft. Genau das Szenario, das sich am 24. März 2026 für zahlreiche Unternehmen weltweit abspielte – und das die Frage aufwirft, wie sicher die Software-Lieferketten hinter der KI-Revolution wirklich sind.

Was am 24. März 2026 geschah: Die Anatomie des LiteLLM-Angriffs

Am Morgen des 24. März veröffentlichte eine Bedrohungsgruppe namens TeamPCP zwei manipulierte Versionen des Python-Pakets LiteLLM auf PyPI, dem zentralen Paketregister für Python-Software. Die Versionen 1.82.7 und 1.82.8 enthielten einen ausgeklügelten Dreistufen-Payload, der weit über einen simplen Datendiebstahl hinausging.

LiteLLM ist kein Nischenprodukt. Die Bibliothek wird täglich rund 3,4 Millionen Mal heruntergeladen und ist laut Analysen in 36 Prozent aller Cloud-Umgebungen präsent. Sie dient als universeller Proxy für KI-Modell-APIs – eine Art Middleware, die es Entwicklern ermöglicht, zwischen verschiedenen LLM-Anbietern wie OpenAI, Anthropic, Azure und Dutzenden weiteren zu wechseln, ohne ihren Anwendungscode ändern zu müssen. Genau diese zentrale Position in der KI-Architektur machte LiteLLM zum idealen Ziel.

Der Angriffsweg: Vom Sicherheitsscanner zur Hintertür

Die Geschichte des Angriffs beginnt nicht bei LiteLLM selbst, sondern bei Trivy – einem weit verbreiteten Open-Source-Sicherheitsscanner von Aqua Security, der in CI/CD-Pipelines zur Schwachstellenerkennung eingesetzt wird. TeamPCP hatte zuvor die Trivy GitHub Action kompromittiert und darüber Zugriff auf CI/CD-Secrets erlangt, die in den Build-Pipelines verschiedener Projekte hinterlegt waren.

Über die kompromittierte Trivy-Action gelangten die Angreifer an die PyPI-Zugangsdaten des LiteLLM-Maintainers. Mit diesen Credentials veröffentlichten sie die manipulierten Paketversionen direkt über den offiziellen Kanal – für jeden Nutzer, der pip install litellm oder pip install --upgrade litellm ausführte, sah alles völlig normal aus.

Die Ironie ist bitter: Ein Sicherheitstool wurde zum Einfallstor für einen Angriff auf ein KI-Tool, das selbst in sicherheitsrelevanten Umgebungen eingesetzt wird.

Der Dreistufen-Payload im Detail

Die von TeamPCP eingeschleuste Schadsoftware war technisch anspruchsvoll und in drei Stufen aufgebaut:

Stufe 1 – Credential Harvesting: Unmittelbar nach der Installation begann der Payload mit dem systematischen Einsammeln sensibler Zugangsdaten. Ziel waren SSH-Schlüssel, Cloud-Provider-Tokens (AWS, GCP, Azure), Kubernetes-Secrets, Kryptowährungs-Wallets und .env-Dateien – also genau jene Konfigurationsdateien, in denen Entwickler typischerweise API-Schlüssel, Datenbankpasswörter und weitere Credentials speichern.

Stufe 2 – Laterale Bewegung in Kubernetes: Hatte der Payload Zugriff auf Kubernetes-Cluster-Credentials erlangt, versuchte er sich lateral auszubreiten. Er deployierte privilegierte Pods auf jedem verfügbaren Node im Cluster – eine Technik, die potenziell den gesamten Cluster und alle darauf laufenden Workloads kompromittiert.

Stufe 3 – Persistenz: Abschließend installierte die Malware einen persistenten systemd-Backdoor, der regelmäßig einen Command-and-Control-Server nach weiteren Binärdateien abfragte. Selbst wenn das kompromittierte LiteLLM-Paket ersetzt oder deinstalliert wurde, blieb der Backdoor aktiv – ein klassisches Persistenzmuster, das eine vollständige Systemwiederherstellung erforderlich macht.

Die Tarnungstechnik: Pythons .pth-Mechanismus

Besonders bemerkenswert ist die Technik, mit der TeamPCP die Persistenz der Schadsoftware sicherstellte: Sie missbrauchten Pythons .pth-Dateimechanismus. Dateien mit der Endung .pth werden vom Python-Interpreter automatisch bei der Initialisierung ausgeführt – noch bevor der eigentliche Anwendungscode startet. Das bedeutet: Jedes Python-Programm, das in der kompromittierten Umgebung gestartet wurde, aktivierte automatisch die Schadsoftware. Diese Technik ist unter Sicherheitsforschern bekannt, wird aber von den meisten Überwachungstools nicht erkannt.

Zurück zu Stefan: Vom Alert zur Krisensitzung

Kehren wir zu unserem Szenario zurück. Stefan Krämer informiert umgehend den externen IT-Sicherheitsdienstleister und zieht seinen Entwicklungsleiter hinzu. Die Analyse ergibt: Das automatisierte Dependency-Update am frühen Morgen hatte LiteLLM auf Version 1.82.7 aktualisiert. Der KI-Assistent lief in einem Kubernetes-Cluster zusammen mit anderen Microservices – darunter ein Service, der auf die interne ERP-Datenbank zugreift.

Die Credential-Harvesting-Komponente hatte bereits SSH-Schlüssel und die Kubernetes-Secrets des Clusters exfiltriert. Ob die laterale Bewegungskomponente erfolgreich weitere Pods kompromittiert hatte, ließ sich zunächst nicht eindeutig feststellen. Stefan trifft die richtige Entscheidung: Er isoliert den gesamten Cluster vom Netzwerk und eskaliert den Vorfall als Sicherheitsincident.

Die nächsten 48 Stunden verbringt das Team mit forensischer Analyse, dem Rotieren sämtlicher Credentials und der Neuaufsetzung des Clusters. Der KI-Assistent ist offline. Die Servicetechniker im Außendienst arbeiten vorübergehend wieder mit der manuellen Dokumentationssuche. Der Geschäftsführer fragt in der Krisensitzung die Frage, die jetzt viele Unternehmensleiter beschäftigt: Wie konnte eine Python-Bibliothek unsere gesamte Infrastruktur gefährden?

Die systemische Dimension: Warum KI-Stacks besonders verwundbar sind

Der LiteLLM-Vorfall ist kein isoliertes Ereignis. Er offenbart strukturelle Schwachstellen, die in der Art und Weise angelegt sind, wie moderne KI-Infrastrukturen aufgebaut und betrieben werden.

Das Dependency-Problem der KI-Welt

KI-Anwendungen sind besonders abhängigkeitsintensiv. Eine typische LLM-basierte Anwendung zieht über ihre direkten und transitiven Dependencies hunderte von Python-Paketen nach sich. LiteLLM allein listet über 70 direkte Dependencies auf. Jedes dieser Pakete, und jedes Paket, von dem diese wiederum abhängen, ist ein potenzieller Angriffsvektor.

Erschwerend kommt hinzu: Viele KI-Projekte nutzen Pakete, die von einzelnen Maintainern betreut werden – engagierten Einzelpersonen, die ihre Arbeit oft in ihrer Freizeit und ohne Budget für Sicherheitsmaßnahmen leisten. Ein kompromittiertes Konto eines einzigen Maintainers kann, wie im Fall von LiteLLM, Millionen von Installationen betreffen.

Die Geschwindigkeit schlägt die Sicherheit

KI-Frameworks entwickeln sich in einem Tempo weiter, das selbst erfahrene Entwicklerteams an ihre Grenzen bringt. Neue Versionen erscheinen wöchentlich, manchmal täglich. Viele Teams haben automatisierte Dependency-Updates konfiguriert – aus dem nachvollziehbaren Wunsch heraus, Sicherheitspatches schnell einzuspielen und von neuen Features zu profitieren. Genau diese Automatisierung wurde im LiteLLM-Fall zum Einfallstor.

Die Spannung zwischen schnell updaten, um sicher zu bleiben und vorsichtig updaten, um nicht kompromittiert zu werden ist eines der fundamentalen Dilemmata moderner Softwareentwicklung – und in der KI-Welt ist es besonders ausgeprägt.

Privilegierte Positionen in der Architektur

LiteLLM nimmt in vielen KI-Architekturen eine besonders kritische Position ein. Als Proxy zwischen der Anwendung und den KI-Modell-APIs hat die Bibliothek Zugriff auf API-Schlüssel sämtlicher angebundener KI-Dienste. In vielen Setups sieht LiteLLM auch die Nutzerdaten, die an die Modelle gesendet werden – Geschäftsdokumente, Kundendaten, interne Informationen. Eine Kompromittierung an dieser Stelle gibt Angreifern Zugriff auf den gesamten Datenstrom zwischen Unternehmen und KI-Modellen.

TeamPCP und LAPSUS: Ein beunruhigendes Bündnis

Sicherheitsforscher von Wiz haben Hinweise darauf gefunden, dass TeamPCP mit der berüchtigten Erpressergruppe LAPSUS zusammenarbeitet. LAPSUS machte 2022 durch spektakuläre Angriffe auf Microsoft, Nvidia, Samsung und Uber Schlagzeilen und ist bekannt für Social-Engineering-Angriffe auf Mitarbeiter großer Technologieunternehmen.

Die Kombination aus TeamPCPs Expertise in Supply-Chain-Angriffen und der Erfahrung von LAPSUS in der Monetarisierung gestohlener Zugangsdaten deutet auf eine professionalisierte Bedrohung hin, die gezielt die wachsende KI-Infrastruktur ins Visier nimmt. Der LiteLLM-Angriff war bereits der dritte bekannte Supply-Chain-Angriff von TeamPCP in kurzer Folge – nach der Kompromittierung der Trivy GitHub Action und der KICS GitHub Action.

Für Unternehmen bedeutet das: Es handelt sich nicht um einen einmaligen Vorfall, sondern um eine laufende Kampagne, die systematisch die Werkzeuge angreift, auf die der moderne Cloud-Native- und KI-Stack aufbaut.

Drei Stunden – und dann war es vorbei (fast)

Es gibt in dieser Geschichte auch gute Nachrichten: Die manipulierten LiteLLM-Versionen waren nur rund drei Stunden auf PyPI verfügbar, bevor das Paketregister sie unter Quarantäne stellte. Das LiteLLM-Team veröffentlichte noch am selben Tag ein Security-Update mit Details zum Vorfall.

Doch drei Stunden genügen. Bei 3,4 Millionen Downloads pro Tag und automatisierten CI/CD-Pipelines, die rund um die Uhr laufen, können selbst wenige Stunden ausreichen, um tausende Installationen zu kompromittieren. Und die persistente Backdoor-Komponente bedeutet: Wer die betroffene Version installiert hat, ist nicht allein durch ein Update auf eine saubere Version geschützt. Die Schadsoftware muss aktiv entfernt, Credentials müssen rotiert und Systeme forensisch geprüft werden.

Handlungsempfehlungen für Unternehmen

Der LiteLLM-Vorfall liefert konkrete Lehren für jedes Unternehmen, das KI-Tools in seiner Infrastruktur einsetzt – und das betrifft mittlerweile die Mehrheit:

1. Software Bill of Materials (SBOM) für KI-Komponenten erstellen

Wissen Sie, welche Python-Pakete in Ihrer KI-Infrastruktur laufen? Können Sie innerhalb von Minuten feststellen, ob eine bestimmte Paketversion in Ihrem Unternehmen im Einsatz ist? Wenn nicht, erstellen Sie umgehend ein Inventar. Tools wie pip freeze, pip-audit und SBOM-Generatoren wie syft oder cdxgen helfen dabei. Integrieren Sie die Ergebnisse in Ihr bestehendes Asset-Management.

2. Automatische Updates kontrollieren

Automatisierte Dependency-Updates sind grundsätzlich sinnvoll – aber nicht ohne Absicherung. Implementieren Sie einen gestaffelten Rollout: Neue Versionen sollten zunächst in einer isolierten Staging-Umgebung getestet werden, bevor sie in die Produktion gelangen. Konfigurieren Sie Ihre Paketmanager so, dass nur explizit freigegebene Versionen installiert werden (Dependency Pinning mit Hash-Verifikation).

3. Netzwerksegmentierung für KI-Workloads

KI-Anwendungen sollten in einem eigenen Netzwerksegment laufen, getrennt von kritischen Geschäftssystemen wie ERP, CRM oder Finanzsystemen. Beschränken Sie den ausgehenden Netzwerkverkehr auf die tatsächlich benötigten Ziele (KI-API-Endpunkte, Modell-Registries) und überwachen Sie Anomalien. Im Szenario von Stefan hätte eine strikte Netzwerksegmentierung die laterale Bewegung erheblich erschwert.

4. Secret Management professionalisieren

API-Schlüssel, Cloud-Credentials und Datenbankpasswörter gehören nicht in .env-Dateien oder Kubernetes-Secrets ohne zusätzliche Schutzmaßnahmen. Nutzen Sie dedizierte Secret-Management-Lösungen wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault. Implementieren Sie automatisierte Secret-Rotation und überwachen Sie den Zugriff auf Credentials.

5. Runtime-Monitoring für KI-Workloads implementieren

Klassisches Endpoint-Monitoring erkennt Supply-Chain-Angriffe wie den LiteLLM-Vorfall oft nicht. Setzen Sie auf Runtime-Security-Tools, die verdächtiges Verhalten in Containern und Python-Prozessen erkennen können: ungewöhnliche Netzwerkverbindungen, Dateizugriffe auf Credential-Speicher, Ausführung unbekannter Binärdateien. Tools wie Falco, Sysdig Secure oder Aqua können hier einen entscheidenden Unterschied machen.

6. Incident-Response-Plan um KI-Szenarien erweitern

Ihr Incident-Response-Plan sollte explizit Szenarien für kompromittierte Software-Dependencies abdecken. Definieren Sie vorab: Wer wird informiert? Welche Systeme werden isoliert? Wie schnell können alle betroffenen Credentials rotiert werden? Wie wird die forensische Analyse durchgeführt? Im Ernstfall zählt jede Minute – Planung im Voraus spart wertvolle Zeit.

7. Vendor-Risikobewertung für Open-Source-KI-Tools

Behandeln Sie Open-Source-KI-Bibliotheken mit derselben Sorgfalt wie kommerzielle Softwareanbieter. Bewerten Sie vor dem Einsatz: Wie ist die Sicherheitskultur des Projekts? Gibt es eine verantwortungsvolle Offenlegungspolitik? Wie viele Maintainer gibt es? Gibt es eine Sicherheitsauditierung? Die Compliance-Anforderungen unter NIS2 und dem EU AI Act machen diese Bewertung ohnehin zunehmend zur Pflicht.

Der Blick nach vorn: Supply-Chain-Sicherheit wird zum Wettbewerbsfaktor

Der LiteLLM-Vorfall ist ein Weckruf – aber kein überraschender. Die Sicherheitscommunity warnt seit Jahren vor Supply-Chain-Angriffen auf Software-Paketregistries. Der SolarWinds-Angriff 2020, die Log4Shell-Krise 2021 und die XZ-Utils-Backdoor 2024 haben das Bewusstsein geschärft. Doch die KI-Welle hat eine neue Klasse von Dependencies geschaffen, die in vielen Unternehmen noch nicht den gleichen Sicherheitsstandards unterliegen wie traditionelle Softwarekomponenten.

Regulatorisch zeichnet sich ab, dass die Supply-Chain-Sicherheit in den kommenden Monaten massiv an Bedeutung gewinnt. Der Cyber Resilience Act (CRA) der EU wird Open-Source-Maintainer und -Distributoren in die Pflicht nehmen, Mindeststandards für die Sicherheit ihrer Softwareprodukte einzuhalten. NIS2 fordert bereits heute eine Bewertung und Absicherung der gesamten IKT-Lieferkette. Und der EU AI Act stellt zusätzliche Anforderungen an die Sicherheit und Transparenz von KI-Systemen.

Für den deutschen Mittelstand bedeutet das: Wer seine KI-Strategie ernsthaft vorantreibt – und das sollte er –, muss die Supply-Chain-Sicherheit von Anfang an mitdenken. Das ist keine zusätzliche Bürde, sondern eine Investition in Resilienz und Vertrauen. Unternehmen, die nachweisen können, dass sie ihre KI-Lieferketten sorgfältig absichern und überwachen, verschaffen sich einen Vertrauensvorsprung bei Kunden, Partnern und Aufsichtsbehörden.

Epilog: Stefans neuer Morgen

Drei Wochen nach dem Vorfall hat Stefan Krämer seine KI-Infrastruktur neu aufgebaut. Der Kubernetes-Cluster wurde komplett neu aufgesetzt, sämtliche Credentials rotiert, die Netzwerksegmentierung verschärft. LiteLLM läuft weiterhin – aber jetzt in einer gehärteten Umgebung mit Dependency Pinning, Hash-Verifikation und Runtime-Monitoring. Das automatische Update am frühen Morgen? Durch einen gestaffelten Freigabeprozess ersetzt.

Und der KI-Assistent für die Servicetechniker? Läuft wieder. Die Geschäftsleitung hat sogar zusätzliches Budget für die Absicherung der KI-Infrastruktur freigegeben. Manchmal braucht es einen Vorfall, um die Prioritäten richtig zu setzen.

Sie möchten Ihre KI-Infrastruktur auf Supply-Chain-Risiken prüfen lassen oder einen ganzheitlichen Sicherheitsansatz für Ihren KI-Stack entwickeln? Unsere Experten bei pleXtec unterstützen Sie – von der Risikoanalyse über die KI-Strategie bis zur operativen Absicherung. Nehmen Sie Kontakt auf.