Angriffe auf die Lieferkette in der KI: Was jüngste Vorfälle über die Sicherheit der KI-Infrastruktur verraten

Am 24. März 2026 war ein Forscher von FutureResearch mit einer Routineaufgabe beschäftigt. Die Aufgabe bestand darin, ein Python-Paket für ein Projekt zu installieren. Innerhalb weniger Minuten begann sich die Workstation unregelmäßig zu verhalten.

Der Speicherverbrauch stieg erheblich. Unbekannte Prozesse sind aufgetreten. Das System ist abgestürzt. Der Forscher hatte unwissentlich einen der raffiniertesten Angriffe auf die Software-Lieferkette ausgelöst, die jemals gegen das KI-Ökosystem verübt wurden. Dieser Angriff war monatelang aktiv und infizierte Tausende von Entwicklerumgebungen, bevor irgendjemand seine Präsenz öffentlich erkannte.

In diesem Artikel werden die Ereignisse untersucht und erklärt, warum KI-Tools für diese Art von Angriffen besonders anfällig sind. Es wird auch erörtert, wie sich Entwicklungsteams schützen können.

Was ist passiert: Ein Supply-Chain-Angriff in drei Schritten Tiefe

Die als „TeamPCP“ identifizierte Gruppe von Bedrohungsakteuren, die seit mindestens Dezember 2025 aktiv ist und von Forschern von Wiz in neun Phasen dieses laufenden Angriffs verfolgt wurde, hatte ihr eigentliches Ziel nicht direkt ins Visier genommen. Stattdessen führte diese Gruppe der Bedrohungsakteure eine vorsichtige, mehrstufiger Supply-Chain-Angriff.

Schritt 1: Am 19. März kompromittierte TeamPCP Trivy, einen weit verbreiteten Open-Source-Sicherheitsscanner, der in die CI/CD-Pipelines vieler Projekte integriert ist.

Schritt 2: Auf dieser Grundlage erhielten sie die PyPI-Veröffentlichungsdaten eines Betreuers einer beliebten LLM-Proxybibliothek, die ungefähr 3,4 Millionen Mal pro Tag heruntergeladen wurde.

Schritt 3: Am 24. März luden sie zwei bösartige Versionen des Pakets auf PyPI hoch. Die kompromittierten Versionen waren ungefähr drei Stunden lang live, bevor PyPI sie unter Quarantäne stellte.

Dies ist das entscheidende Merkmal moderner Supply-Chain-Angriffe: Der Angreifer muss Sie niemals direkt angreifen. Sie verletzen jemanden, dem Ihre Tools vertrauen, und lassen sich von diesem Vertrauen den Rest des Weges leiten.

Hinter der Nutzlast: Drei Stufen des Kompromisses

Das bösartige Paket führte eine ausgeklügelte dreistufige Nutzlast aus, die Sicherheitsforscher von Snyk ausführlich dokumentiert haben.

Stufe 1 — Informationssammlung. Die Nutzlast sammelte im Hintergrund alles, was sie finden konnte: private SSH-Schlüssel, AWS- und GCP-Zugangsdaten, Azure-Dienstprinzipale, Kubernetes-Konfigurationen, .env-Dateien, Git-Anmeldeinformationen, Datenbankkennwörter, Shell-Verlauf, CI/CD-Geheimnisse und Wallet-Seedphrasen für Kryptowährungen.

Stufe 2 — Verschlüsselung und Exfiltration. Die gesammelten Daten wurden verschlüsselt und an einen vom Angreifer kontrollierten Server übertragen. Während dieses Vorgangs wurden temporäre Dateien (session.key, payload.enc, tpcp.tar.gz) im temporären Systemverzeichnis erstellt.

Stufe 3 — Beharrlichkeit und laterale Bewegung. Die Payload installierte ein Backdoor-Python-Skript, das als Systemd-Dienst namens „System Telemetry Service“ getarnt war. Dieses Persistenz-Skript fragte alle fünf Minuten eine vom Angreifer kontrollierte URL nach neuen Befehlen ab — und konnte sich über Ihren gesamten Kubernetes-Cluster verteilen, indem es privilegierte Pods auf jedem Knoten im Kube-System bereitstellte.

Was das Ganze besonders gefährlich machte, war der Übertragungsmechanismus: eine PTH-Datei. Python-Pfadkonfigurationsdateien werden automatisch ausgeführt, wenn ein Python-Prozess gestartet wird — einschließlich Pip selbst, einschließlich CI/CD-Build-Schritten, einschließlich Testläufern. Sie mussten Ihre Anwendung nicht ausführen. Du musstest nur das Paket installiert haben, und die Payload lief.

Warum KI-Infrastruktur ein besonderes Ziel ist

Das betroffene Paket wurde nicht zufällig ausgewählt. Eine der privilegiertesten Positionen im modernen Software-Stack ist die der Large Language Model (LLM) -Proxys und KI-Gateways. Wenn Sie ein LLM-Gateway installieren und einrichten, versetzen Sie es in die Lage, sich direkt zwischen Anwendungen und den verwendeten KI-Dienstanbietern zu befinden. Es hat Zugriff auf OpenAI-API-Schlüssel, Anthropic-Anmeldeinformationen, Azure- und Google Cloud Platform-Dienstkonten. Es hat Zugriff auf Umgebungsvariablen und in vielen Fällen auf den Secrets Manager. Dies ist beabsichtigt und notwendig, um die Anfragen weiterzuleiten, Ratenbeschränkungen durchzusetzen und die Nutzung zu protokollieren. Dies ist das beabsichtigte Verhalten.

Dies bedeutet auch, dass der Angreifer vollen Einblick in die KI-Infrastruktur hat, wenn das LLM-Gateway und/oder eine seiner Abhängigkeiten gefährdet sind. Forscher von Sonatype schrieben in ihrem Bericht über diesen Vorfall: „Da LiteLLM in der Regel direkt zwischen Anwendungen und mehreren KI-Dienstanbietern sitzt, hat es oft Zugriff auf API-Schlüssel, Umgebungsvariablen und andere sensible Konfigurationsdaten. Die Kompromittierung eines Pakets in dieser Position ermöglicht es Angreifern, wertvolle Geheimnisse abzufangen und zu exfiltrieren, ohne direkt in vorgelagerte Systeme eindringen zu müssen.“

Warum Compliance-Frameworks es nicht verstanden haben

Das Paket umfasste die Zertifizierungen SOC 2 Typ 1 und ISO 27001. Es lohnt sich, dies zu untersuchen, um diese Frameworks nicht zu kritisieren — sie sind wichtig, und die Teams, die sie verfolgen, tun das Richtige —, sondern weil sie eine strukturelle Lücke verdeutlichen.

Compliance-Frameworks überprüfen, was Sie tun, anhand einer Checkliste. Sie decken Zugriffskontrollen, Datenverarbeitung und Reaktion auf Vorfälle ab. Sie untersuchen in der Regel nicht, ob der Sicherheitsscanner in Ihrer CI/CD-Pipeline von einem Bedrohungsakteur kompromittiert wurde, der dann Ihre PyPI-Veröffentlichungsdaten stiehlt.

Selbst eine standardmäßige Pip-Hash-Überprüfung hätte diesen Angriff nicht erkannt. Die bösartige .pth-Datei in der kompromittierten Version wurde in der RECORD-Datei des Pakets korrekt mit einem passenden Hash deklariert. Das Paket hat jede Integritätsprüfung bestanden, die PyPI anbietet. Es war ein gültiges Paket, das zufällig bewaffnet war.

Das ist der Sicherheit der Lieferkette Lücke, die das KI-Ökosystem speziell schließen muss: Die Frage lautet nicht nur: „Sind unsere Systeme sicher?“ Es lautet: „Sind die Tools, die wir verwenden, um unsere Systeme aufzubauen und zu sichern, sicher?“

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Wie TrueFoundry über dieses Problem denkt

Bei TrueFoundry Sicherheit der Lieferkette ist ein erstklassiges Anliegen bei der Gestaltung unserer MLOps-Plattform — kein nachträglicher Gedanke.

Wenn Unternehmen Modelle einsetzen und LLM-Gateways Durch TrueFoundry stellen wir eine andere Art von Frage: nicht nur „Ist dieser Endpunkt sicher?“ aber „was ist der Explosionsradius, wenn eine Komponente in diesem Stack kompromittiert ist?“

Ein paar Prinzipien bestimmen, wie wir bauen:

Die Infrastruktur läuft in Ihrer VPC. Wenn Ihre KI-Infrastruktur innerhalb Ihrer eigenen Cloud-Grenze läuft, werden Geheimnisse niemals an externe Systeme weitergegeben. Selbst wenn eine Abhängigkeit irgendwo im Ökosystem gefährdet wäre, wäre der Exfiltrationsendpunkt innerhalb Ihres Netzwerkperimeters nicht erreichbar.

Abhängigkeiten werden gepinnt und geprüft. TrueFoundry ruft bei jedem Build nicht im Hintergrund die neuesten Versionen ab, sondern verwaltet festgeheftete, überprüfte Abhängigkeiten im gesamten Plattform-Stack. Dadurch entfällt eine ganze Klasse von Supply-Chain-Vektoren.

Die Isolierung der Komponenten begrenzt den Explosionsradius. Eine Kompromittierung in einer Ebene des Stacks gewährt nicht automatisch Zugriff auf eine andere. Prinzip der geringsten Rechte, das auf Infrastrukturebene durchgesetzt wird.

Nichts davon ist exotische Technik. Es ist Disziplin, die auf ein Bedrohungsmodell angewendet wird, das KI-Tools als Branche nicht ernst genug genommen haben: Die Bedrohung kommt nicht durch Ihre Firewall. Sie kommt durch deine requirements.txt.

Was Ihr Team jetzt tun sollte

Wenn Sie Python-basierte KI-Tools verwenden, und fast jedes Teambuilding auf LLMs tut, lohnt es sich, die folgenden Aktionen sofort zu priorisieren.

1. Überprüfen Sie Ihre installierten Paketversionen. Führen Sie pip show litellm | grep Version aus. Wenn Ihre Ausgabe 1.82.7 oder 1.82.8 anzeigt, behandeln Sie das System als gefährdet und führen Sie das Upgrade nicht einfach an Ort und Stelle durch. Die Payload wurde möglicherweise bereits ausgeführt. Führen Sie den Neuaufbau aus einem sauberen Zustand auf einer bekanntermaßen sauberen Maschine durch.

2. Überprüfe .pth-Dateien auf allen Computern und CI-Runnern.

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

3. Suchen Sie nach Persistenzartefakten.

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
systemctl --user status sysmon.service 2>/dev/null
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc 2>/dev/null

4. Rotieren Sie die Anmeldeinformationen aggressiv. Wenn ein betroffener Computer Zugriff auf Cloud-Anmeldeinformationen, SSH-Schlüssel, API-Schlüssel, Kubernetes-Dienstkonto-Tokens oder Datenbankkennwörter hatte, rotieren Sie sie jetzt alle. Nicht bewerten — rotieren. Die Nutzlast zielte speziell auf AWS Secrets Manager, SSM Parameter Store und Kubernetes-Cluster-Secrets in allen Namespaces ab.

5. Überprüfe Kubernetes auf bösartige Pods.

kubectl get pods -A | grep "node-setup-"

Pods mit dem Namen node-setup- {node_name} im Kube-System-Namespace sind ein bekannter Indikator für Kompromisse aus dieser Kampagne.

6. Gehen Sie zu einer privaten Paketregistrierung über. PyPI ist nicht die einzige Option für die Auflösung von Abhängigkeiten. Ein privater Paketspiegel mit angehefteten Hashes und einem Genehmigungsworkflow eliminiert diese gesamte Klasse von Angriffsvektoren. Tools wie Artifactory, AWS CodeArtifact oder Google Artifact Registry können als Vermittler dienen.

7. Behandeln Sie Ihre CI/CD-Lieferkette als Angriffsfläche. Der erste Kompromiss in der TeamPCP-Kampagne betraf nicht die Zielbibliothek, sondern den Sicherheitsscanner, der in der CI-Pipeline dieser Bibliothek verwendet wurde. Ihre Build-Infrastruktur, Ihre GitHub-Aktionen und Ihre Drittanbieter-Integrationen sind alle Teil Ihrer Angriffsfläche. Überprüfe sie entsprechend.

Das breitere Muster: Dies ist nicht isoliert

Was diesen Fall besonders interessant macht, ist, dass es sich nicht um einen opportunistischen Angriff handelte. Vielmehr führt TeamPCP diese aufwändige Kampagne mindestens seit Dezember 2025 durch. Vor dem Angriff auf LitelM kompromittierte TeamPCP den Trivy-Sicherheitsscanner von Aqua (19. März), die VS Code-Erweiterungen und GitHub-Aktionen (23. März) von CheckMarx sowie mehrere NPM-Pakete, die einen sich selbst verbreitenden Wurm enthielten.

Beachten Sie, dass das verwendete RSA-Schlüsselpaar mit dem bei allen anderen Angriffen verwendeten identisch ist, ebenso wie der Name des tpcp.tar.gz Bundles und der GitHub-Repos mit dem Präfix tpcp-docs. Dies deutet darauf hin, dass TeamPCP ein professioneller Bedrohungsakteur ist, der seine Kampagne methodisch durchführt.

Dies bedeutet, dass die Teams, die durch diese Kampagne gefährdet wurden, nicht fahrlässig gehandelt haben. Vielmehr nutzten sie bewährte Verfahren: Sie nutzten sehr beliebte und gut überprüfte Open-Source-Software.

Was das Ganze also interessant macht, ist, dass TeamPCP keine Schwachstelle in der Verteidigung eines Unternehmens festgestellt hat. Vielmehr hat TeamPCP eine Schwäche in der Art und Weise identifiziert, wie das gesamte KI-Ökosystem innerhalb seiner Abhängigkeitskette mit Vertrauen umgegangen ist.

Das Vertrauensproblem, das die KI-Infrastruktur lösen muss

Das KI-Ökosystem hat in kürzester Zeit etwas Außergewöhnliches geschaffen. Die Geschwindigkeit und Offenheit, die das möglich gemacht haben — die Kultur von Pip Install and Share, bei der man auf der Arbeit des jeweils anderen aufbaut, ist wirklich wertvoll und es wert, bewahrt zu werden.

Aber Geschwindigkeit ohne Sicherheit der Lieferkette schafft Schulden. Die Angriffsfläche eines modernen KI-Stacks besteht nicht mehr nur aus den Endpunkten, die Sie offenlegen. Es ist jedes Paket in Ihrem Abhängigkeitsbaum, jedes Tool in Ihrer CI/CD-Pipeline, jede Open-Source-Komponente, die während des Builds oder zur Laufzeit Zugriff auf Ihre Geheimnisse hat.

Um diese Lücke zu schließen, ist eine mehr als bessere Reaktion der betroffenen Teams auf Vorfälle erforderlich. Das gesamte KI-Infrastruktur-Ökosystem — Betreuer, Plattformanbieter, Unternehmen und Sicherheitsteams — muss die Herkunft der Lieferkette als erstklassiges technisches Anliegen behandeln.

Der Forscher, dessen Maschine abgestürzt ist, dachte wahrscheinlich nicht, dass er im Begriff war, eine monatelange Kampagne zu veröffentlichen, die auf die KI-Infrastruktur abzielte. Das tat auch keiner der Entwickler, die eine routinemäßige Pip-Installation durchführten. Das liegt in der Natur von Angriffe auf die Softwarelieferkette. Wenn man sie sieht, ist der Schaden oft schon angerichtet.

Die KI-Branche kann besser bauen. Das muss sie.

Häufig gestellte Fragen

Was ist ein Software-Supply-Chain-Angriff?

Ein Angriff auf die Softwarelieferkette liegt vor, wenn ein Bedrohungsakteur eine vertrauenswürdige Komponente kompromittiert, die dem Endziel vorgelagert ist — z. B. ein Entwicklertool, eine Open-Source-Bibliothek oder eine CI/CD-Pipeline — und sie verwendet, um bösartigen Code an alle nachgeschalteten Benutzer dieser Komponente zu verteilen. Anstatt ein Unternehmen direkt anzugreifen, nutzen Angreifer das implizite Vertrauen aus, das Entwickler in weit verbreitete Pakete und Tools setzen.

Wie können KI- und ML-Teams ihre Infrastruktur vor Angriffen auf die Lieferkette schützen?

Der Schutz der KI- und ML-Infrastruktur vor Angriffen auf die Lieferkette erfordert mehrere ergänzende Maßnahmen. Teams sollten eine private Paketregistrierung (wie AWS CodeArtifact, Google Artifact Registry oder Artifactory) mit angehefteten Abhängigkeits-Hashes verwenden, anstatt sie direkt aus dem öffentlichen PyPI abzurufen. Durch die regelmäßige Überprüfung von.pth-Dateien in Python-Site-Packages-Verzeichnissen können bösartige Ergänzungen frühzeitig entdeckt werden. Der Betrieb einer KI-Infrastruktur — einschließlich LLM-Gateways und Model Serving-Komponenten — in einer privaten VPC schränkt die Fähigkeit eines Angreifers ein, Anmeldeinformationen an externe Server zu übertragen, selbst wenn eine Abhängigkeit gefährdet ist. Die Verwaltung einer Software-Stückliste (SBOM) für Ihren ML-Stack ermöglicht eine schnellere Identifizierung von Risiken, wenn ein neuer Vorfall bekannt wird. Schließlich sollten CI/CD-Pipelines selbst als Angriffsfläche betrachtet werden: Die Tools, die zur Entwicklung und Sicherung von Software verwendet werden — einschließlich Sicherheitsscanner und GitHub-Aktionen — können und wurden im Rahmen umfassenderer Supply-Chain-Kampagnen kompromittiert.

Welche Faktoren sollten von den Teams bei der Bewertung des sicheren LLM-Gateways berücksichtigt werden, um die Risiken von Angriffen auf die Lieferkette zu mindern?

Das LLM-Gateway sollte in der VPC der Organisation funktionieren. Auf diese Weise gibt es keine Exfiltrationswege, wenn die Abhängigkeiten gefährdet sind. Die Abhängigkeiten sollten gepinnt und überprüft werden, anstatt sie bei der Installation mithilfe von öffentlichen Registern zu lösen. Anmeldeinformationen sollten nicht über Umgebungsvariablen verwaltet werden, sondern sollten stattdessen über den nativen Secrets Manager des Cloud-Anbieters verwaltet werden. Eine Auditprotokollierung aller Modellaufrufe, der Schlüsselnutzung und der Konfigurationsänderungen sollte ebenfalls durchgeführt werden. Auf diese Weise kann jedes abnormale Verhalten leicht identifiziert werden. TrueFoundry hat all diese Konfigurationen standardmäßig eingerichtet, wodurch die Angriffsfläche im Vergleich zu selbstverwalteten Open-Source-Tools reduziert wird.