Wenn KI die KI angreift LiteLLM-Lieferkettenangriff über einen autonomen KI-Agenten

Anbieter zum Thema

SentinelOne GmbH

Fujitsu Technology Solutions GmbH

FAST LTA GmbH

FTAPI Software GmbH

Ein autonomer Coding-Assistent installierte im März 2026 unwissentlich ein präpariertes Softwarepaket. Kein Mensch drückte auf Installieren, die KI tat es selbst. Angreifer nutzen für neuartige Supply-Chain-Angriffe gezielt aus, dass KI-Agenten heute längst automatisiert handeln.

Am 24. März 2026 erkannte SentinelOnes KI-gesteuertes Endpoint-Detection-and-Response-System (EDR) in mehreren Kundenumgebungen gleichzeitig eine ungewöhnliche Verhaltens­kette. Der Auslöser war kein Mitarbeiter, der auf einen falschen Link geklickt hatte, und keine Phishing-Mail, die jemand geöffnet hatte. Es war ein KI-Assistent, der im Rahmen seines normalen Arbeitsablaufs eine Software-Bibliothek aktualisierte, ohne zu wissen, dass diese wenige Stunden zuvor von Angreifern präpariert wurde.

Der betroffene Assistent ist Claude Code von Anthropic, ein Werkzeug, das Entwicklern bei Programmieraufgaben hilft. Es lief in einer Konfiguration mit vollständigen Systemrechten, was im Entwicklungsalltag häufig vorkommt, um Reibungsverluste zu vermeiden. Das aktualisierte Paket hieß LiteLLM, eine weitverbreitete Software-Komponente, die als Verbindungsschicht zwischen Anwendungen und großen Sprachmodellen dient. Wer LiteLLM einsetzt, vertraut ihr implizit, gehört es doch zur Standardausstattung moderner KI-Entwicklungsumgebungen.

TeamPCP griff EU und Cisco an

Massive Supply-Chain-Angriffe über Trivy-Tool und Telnyx-PyPI

Wie Angreifer das Vertrauen in Open Source aushebelten

Hinter dem Angriff steckte die Gruppe TeamPCP, die methodisch und geduldig vorging. Ihr erster Schritt war nicht der Angriff auf LiteLLM selbst, sondern auf ein anderes, weit ver­brei­te­tes Sicherheitswerkzeug namens Trivy. Über diesen Umweg gelangten die Angreifer an die Zugangsdaten des LiteLLM-Betreuers bei PyPI, dem zentralen Paketverzeichnis für Python-Software, und konnten so zwei präparierte Versionen von LiteLLM veröffentlichen, die äußerlich wie offizielle Updates aussahen.

Das eigentlich Gefährliche an diesem Vorgehen: Die Angreifer mussten niemanden täuschen. Sie haben lediglich dafür gesorgt, dass das kompromittierte Paket in den normalen Update-Prozess einfloss. Der Rest erledigte die Automatisierung. Genau das ist der Kern sogenannter Lieferkettenangriffe: Nicht das Ziel selbst wird angegriffen, sondern der Weg dorthin, über Software-Bestandteile, denen alle vertrauen.

Was im Erfolgsfall passiert wäre

Das präparierte Paket war darauf ausgelegt, in mehreren Phasen vorzugehen. Zunächst hätte es im Verborgenen Informationen gesammelt: Zugangsdaten für Cloud-Dienste, Konfigurations­dateien, Schlüsseldaten von Entwicklerarbeitsplätzen. Für Unternehmen, die KI-Assistenten in ihrer Entwicklungsumgebung einsetzen, bedeutet das im schlimmsten Fall, dass ein Angreifer von einem einzigen kompromittierten Laptop aus Zugang zur gesamten Produktivinfrastruktur erhalten hätte.

In einem zweiten Schritt hätte sich die Schadsoftware im System verankert und dabei bewusst Namen und Strukturen legitimer Systemdienste imitiert, um bei einer oberflächlichen Prüfung nicht aufzufallen. Im dritten Schritt wäre sie in Richtung weiterer Server im Netzwerk vorgestoßen. Die Kommunikation nach außen war so gestaltet, dass sie im normalen Netzwerkverkehr verschwand, indem eine Domain verwendet wurde, die regulären LiteLLM-Diensten zum Verwechseln ähnlich sah.

EUVD-2026-28503 / CVE-2026-42208

Datenbankinhalte und Zugangsdaten von LiteLLM gefährdet

44 Sekunden bis zur Eindämmung

SentinelOnes EDR-System unterband den Angriff, bevor eine dieser Phasen abgeschlossen werden konnte. Der Mechanismus dahinter ist verhaltensbasiert: Das System beobachtet nicht, welche Software ausgeführt wird, sondern was sie dabei tut. Als das präparierte Paket begann, sich in einer für Schadsoftware typischen Weise zu verhalten, klassifizierte die KI-Engine den Vorgang als schädlich und stoppte den gesamten Prozess automatisch, innerhalb von 44 Sekunden, ohne dass ein Analyst eingreifen musste.

Entscheidend dabei: Das System brauchte keine Signatur für dieses spezifische Paket und keine vorherige Kenntnis des Angriffs. Es erkannte das Muster des Verhaltens. Das ist der wesentliche Unterschied zu klassischen, signaturbasierten Erkennungslösungen: Wer nur bekannte Bedrohungen erkennt, ist gegenüber neuen Angriffen blind. Die Erkennung erfolgte in mehreren Kundenumgebungen gleichzeitig, noch am selben Tag, an dem der Angriff gestartet wurde.

KI-Agenten als neue Angriffsoberfläche

Was diesen Vorfall über den konkreten Fall hinaus bedeutsam macht, ist die strukturelle Verschiebung, die er sichtbar macht. KI-Assistenten, die autonom Code ausführen, Abhängigkeiten aktualisieren und dabei mit weitreichenden Systemrechten arbeiten, erweitern die Angriffsoberfläche von Unternehmen auf eine Weise, die in vielen Sicherheitsstrategien noch nicht abgebildet ist. Die Eigenschaften, die solche Werkzeuge nützlich machen, Speed und Automatisierung, sind dieselben, die sie in diesem Kontext risikoreich machen.

Hinzu kommt eine Tendenz, die sich in den zurückliegenden Monaten abzeichnet. Anthropic berichtete im September 2025 davon, dass eine staatlich gesponserte Gruppe einen KI-Coding-Assistenten für eine vollständige Spionagekampagne gegen rund 30 Organisationen miss­braucht hatte. Die KI übernahm dabei den Großteil der Operationen autonom. Der LiteLLM-Vorfall ist kein Ausreißer, sondern ein frühes Beispiel dafür, wohin sich Angriffsmethoden entwickeln, wenn KI-Agenten zu selbstverständlichen Bestandteilen von IT-Umgebungen werden.

Organisationen, die KI-Assistenten im Einsatz haben, ohne entsprechende Governance-Richtlinien für deren Berechtigungen und Verhaltensrahmen etabliert zu haben, tragen Risiken, die in herkömmlichen Sicherheitsprüfungen nicht sichtbar werden. Der Angriff lief nicht durch eine bekannte Schwachstelle, sondern durch das normale, erwartete Verhalten eines vertrauenswürdigen Werkzeugs.

npm-Lieferkettenangriff auf KI-Framework Mastra

Gekapertes npm-Konto schleust Schadcode in 140 Mastra-Pakete

Was das für Sicherheitsverantwortliche bedeutet

Der Vorfall stellt Sicherheitsverantwortliche vor eine grundlegende Frage: Mit welcher Geschwindigkeit muss eine Sicherheitsplattform reagieren können, wenn der Angreifer kein Mensch, sondern ein automatisierter Prozess ist? Der Abstand zwischen dem Moment, in dem ein präpariertes Paket veröffentlicht wird, und dem Moment, in dem es in einer Unternehmens­um­ge­bung auftaucht, kann Stunden betragen. Wer auf Signaturen und manuelle Analyse angewiesen ist, verliert diesen Wettlauf strukturell.

Autonome, verhaltensbasierte Erkennung schließt diese Lücke, weil sie unabhängig von Vorwissen über den konkreten Angriff arbeitet. Das ist keine Frage von Produktmerkmalen, sondern eine Architekturfrage, die sich mit zunehmender Verbreitung von KI-Agenten in Entwicklungs- und Betriebsumgebungen immer stärker stellen wird.

Die relevante Frage für jeden, der seine eigene Sicherheitsstrategie bewertet: Hätte meine Lösung diesen Angriff am Tag seines Erscheinens, ohne Vorkenntnis des vorbereiteten Pakets, automatisch gestoppt? Wenn die Antwort von einer Signaturaktualisierung oder einem manuellen Untersuchungsschritt abhängt, dann ist die Antwort gefunden.

Über den Autor: Erhan Oezmen ist Area Vice President Central and Eastern Europe bei SentinelOne.

(ID:50891795)