Von Shai‑Hulud zu LiteLLM: Supply‑Chain‑Angreifer haben es auf Ihre Agents abgesehen

Der Supply-Chain-Angriff auf LiteLLM vom 24. März 2026 war ein Einzelfall. Er ist das bislang gefährlichste Kapitel in einem sich ständig weiterentwickelnden Angreifer‑Playbook, das das JFrog Security Research Team seit Jahren verfolgt. Das Ziel hat sich verschoben: von Entwicklern hin zu den KI-Agenten, auf die sich Entwickler heute beim Bau von Software immer mehr verlassen.

Der Entwickler war schon immer das Ziel

Supply-Chain-Angriffe folgen einer einfachen Formel: Ein vertrauenswürdiges Open-Source-Paket wird gefunden, vergiftet und das Ökosystem übernimmt die Distribution. Shai-Hulud, erstmals im September 2025 gemeldet und vom JFrog Security Research Team eingehend analysiert, ist ein gutes Beispiel dafür. Der Angriff basierte auf einem selbst-replizierenden Wurm, der in npm-Pakete eingebettet war und darauf ausgelegt war, Entwickler-Tokens zu stehlen und automatisch andere Pakete zu re-infizieren, die diese Entwickler verwalteten. Da er sich exponentiell ohne direkte Beteiligung des Angreifers verbreitete, gilt er als einer der schwerwiegendsten JavaScript-Supply-Chain-Angriffe, die je dokumentiert wurden.

Um Unternehmen vor dieser Art von Bedrohung zu schützen, bietet JFrog Curation eine automatisierte Gatekeeping-Schicht, die bösartige und verwundbare Open-Source-Pakete blockiert, bevor sie in Entwicklerumgebungen gelangen.

Der SDLC verändert sich – und damit auch die Angriffsfläche

Neben den Entwicklern selbst entdecken böswillige Akteure zunehmend Schwachstellen in KI-generiertem Code. Software-Developer verlassen sich nicht mehr ausschließlich auf ihre eigenen Programmierkenntnisse, sondern orchestrieren gleichzeitig mehrere KI-Agenten für Code-Generierung, Testing, Recherche und Deployment. Der Entwicklungslebenszyklus hat sich von einem linearen, menschlich gesteuerten Ablauf zu einer verteilten Multi-Agenten-Pipeline entwickelt.

Vor KI-generiertem Code:

Nach KI-generiertem Code:

Jeder Entwickler kann nun mehrere Agenten parallel betreiben, die jeweils mit KI-Paketen, MCP-Servern, Modellen und Skills interagieren – was zu einer rapide wachsenden Angriffsfläche führt.

Um diese neue Angriffsfläche zu verstehen, ist es entscheidend zu verstehen, wie ein Agent funktioniert. Ein KI-Agent ist kein Modell, sondern eine Komposition aus KI-Assets:

• Das LLM als Kern
• Die Regeln und der Speicher, die sein Verhalten bestimmen
• Die Agent Skills, die er ausführen kann
• Die MCP-Server, die ihn mit externen Systemen und Daten verbinden

Jede dieser Komponenten stellt einen potenziellen Angriffsvektor bzw. Risikobereich dar.

Anatomie eines KI‑Agenten

Agenten sind das neue Ziel

Als Supply-Chain-Kontrollen das Vergiften von Entwicklerumgebungen erschwerten, änderten Angreifer ihre Taktik. Wenn der direkte Weg über den Entwickler versperrt ist – warum dann nicht dessen Tools ins Visier nehmen?

September 2025 – postmark-mcp: Der erste bösartige MCP-Server in freier Wildbahn.

Ein Bedrohungsakteur klonte das legitime Postmark-MCP-Repository und veröffentlichte ein nahezu identisches npm-Paket. Über fünfzehn Versionen hinweg funktionierte es einwandfrei und genoss das Vertrauen von Entwicklern in Hunderten von Workflows. Dann fügte Version 1.0.16 eine einzige Codezeile ein – ein verstecktes BCC –, das jede über den MCP-Server gesendete E-Mail still und heimlich an eine vom Angreifer kontrollierte Domain weiterleitete. Passwort-Resets, Rechnungen und interne Memos wurden alle unbemerkt aus KI-Agenten-Workflows exfiltriert, denen der Connector volles Vertrauen eingeräumt worden war.

Besonders gefährlich war dabei, dass MCP-Server innerhalb von Agenten-Toolchains mit hohen Privilegien und weitreichenden Berechtigungen laufen. Ein kompromittierter MCP-Server vergiftet nicht nur eine einzelne Codebase – er wird zu einer persistenten Upstream-Steuerungsebene, die in der Lage ist, einen gesamten KI-gesteuerten Workflow und alle verbundenen Systeme zu manipulieren.

Der Angriff auf postmark‑mcp war ein Warnschuss. Die Kompromittierung von LiteLLM war die Eskalation.

Der LiteLLM‑Angriff: Eine neue Stufe der Raffinesse

LiteLLM ist eines der kritischsten Pakete im KI-Ökosystem und fungiert als universelles Gateway zu über 100 LLM-APIs, darunter OpenAI, Anthropic, AWS Bedrock und Google VertexAI. Das Paket verzeichnet täglich rund 3,4 Millionen Downloads und ist in 36 % aller Cloud-Umgebungen präsent. Es ist zudem eine weit verbreitete transitive Abhängigkeit in MCP-Plugins und KI-Agenten-Frameworks – genau deshalb wurde es zum Ziel. Die vollständige technische Analyse des Angriffs durch JFrog Security Research liefert alle Details.

Der Angriff wurde von TeamPCP durchgeführt – derselben Gruppe, die zuletzt den Trivy-Scanner von Aqua Security und die KICS GitHub Action von Checkmarx kompromittiert hatte. Dies war kein opportunistischer Angriff, sondern eine koordinierte, kaskadierende Kampagne.

So lief der Angriff ab

Die CI/CD-Pipeline von LiteLLM führte Trivy als Teil ihres Build-Prozesses ohne gepinnte Version aus. Am 19. März hatte TeamPCP die GitHub Action von Trivy bereits kompromittiert. Als der LiteLLMs Build ausgeführt wurde, exfiltrierte die kompromittierte Trivy-Action den PyPI-Publish-Token des Projekts vom GitHub Actions Runner. Mit diesem Credential veröffentlichten die Angreifer am Morgen des 24. März die LiteLLM-Versionen 1.82.7 und 1.82.8 – beide enthielten bösartige Payloads, die den normalen Release-Workflow von LiteLLM vollständig umgingen.

Was die Malware tat

Nach der Aktivierung führte der Payload einen dreistufigen Angriff durch:

• Credentials Harvesting: SSH-Keys, AWS-, GCP- und Azure-Cloud-Tokens, Kubernetes Secrets, Crypto-Wallets und .env-Dateien wurden gestohlen.
• Lateral Movement: Über Kubernetes-Cluster hinweg wurden privilegierte Pods auf jeden Node deployed.
• Persistente Backdoor: Ein systemd-Backdoor wurde installiert, der regelmäßig zusätzliche Binaries von einer Angreifer-kontrollierten Infrastruktur abfragt. Alle gesammelten Daten wurden verschlüsselt und an models.litellm.cloud exfiltriert – eine Domain, die die legitime LiteLLM-Infrastruktur imitiert und am selben Tag wie der Angriff registriert wurde.

Version 1.82.8 war besonders aggressiv: Sie missbrauchte den .pth-Datei-Mechanismus von Python, der bei jedem Python-Interpreter-Start ausgelöst wird – unabhängig davon, ob LiteLLM explizit importiert wurde. Der Payload war doppelt Base64-kodiert, um statische Analysen zu umgehen.

Wie es entdeckt wurde – innerhalb eines Agents

Der Angriff wurde erstmals entdeckt, als das Paket als transitive Dependency von einem in Cursor laufenden MCP‑Plugin eingezogen wurde. Der Rechner eines Researchers wurde durch Überlastung unbenutzbar – ein Nebeneffekt eines eigenen Fork‑Bomb‑Bugs der Malware. Das bösartige Paket hatte die Runtime eines AI‑Agents erreicht, bevor es ein Mensch wissentlich installiert hatte.

Die Auswirkungen auf die Organisation

Da LiteLLM typischerweise direkt zwischen Anwendungen und mehreren KI-Service-Providern sitzt, hält es API-Keys, Umgebungsvariablen und sensible Konfigurationsdaten für den gesamten KI-Stack einer Organisation. Eine einzige kompromittierte Installation legt die Credentials für jeden KI-Service offen, den eine Organisation nutzt – über alle Umgebungen hinweg, in denen LiteLLM betrieben wird:  Developer‑Maschinen, CI/CD-Pipelines, Staging und Production. Die bösartigen Versionen waren rund drei Stunden auf PyPI verfügbar. Angesichts des Download‑Volumens des Pakets war die potenzielle Exposure in diesem Zeitfenster ernorm.

Das Muster ist eindeutig

Attacke	Vektor	Ziel
Shai-Hulud (npm)	Sich selbst replizierender Wurm in Open‑Source‑Paketen	Developer environments
postmark-mcp (npm)	Bösartiger MCP‑Server	AI agent workflows
LiteLLM (PyPI)	Vergiftetes AI‑Infrastruktur‑Package über kompromittiertes CI‑Tool	Agent runtimes + CI/CD

Die Angriffsfläche ist nicht nur größer geworden – sie wurde mit der Anzahl der Agenten, die jeder Entwickler betreibt, multipliziert. Eine einzige kompromittierte KI-Abhängigkeit kann sich über jede Umgebung ausbreiten, in der Agenten gleichzeitig operieren.

Das Problem mit Open-Source-KI-Gateways

Die Rolle von LiteLLM im Ökosystem verdient eine genauere Betrachtung. Im Kern ist es ein Open-Source-KI-Gateway – eine einzelne Routing-Schicht zwischen Ihren Anwendungen und allen LLM-APIs, die Sie nutzen. Diese Position innerhalb der Architektur ist mächtig. Sie ist auch genau das, was es zu einem so attraktiven und verheerenden Angriffsvektor macht.

Wenn Sie den gesamten KI-Traffic über ein einziges Open-Source-Paket routen, setzen Sie außerordentliches Vertrauen in die Integrität dieses Pakets, in die Sicherheitspraktiken seiner Maintainer und in die Pipeline, die es veröffentlicht. Die LiteLLM-Kompromittierung hat gezeigt, wie fragil dieses Vertrauen sein kann. Eine einzige ungepinnte Abhängigkeit in einem CI-Workflow reichte aus, um Angreifern die Schlüssel zur gesamten KI-Infrastruktur eines Unternehmens zu überlassen – inklusive aller Model-API-Keys, aller Cloud-Credentials und aller Secrets in der Umgebung.

Wir empfehlen ausdrücklich nicht, auf die Nutzung von KI-Gateways zu verzichten. Wir plädieren jedoch nachdrücklich dafür, diese auf einem soliden, sicheren Fundament  aufzubauen. Ein KI-Gateway, das im Zentrum Ihrer Agentic Supply Chain steht, muss mit enterprise-grade Controls verwaltet werden – und darf nicht einfach aus einer öffentlichen Registry bezogen werden, in der Hoffnung, dass schon nichts passiert.

Eine vertrauenswürdige Agentic Supply Chain aufbauen

Die Antwort lautet also nicht, die KI-Adoption zu verlangsamen oder zu unterbinden. Es geht darum, der KI-Schicht nicht länger blind zu vertrauen und sie stattdessen mit derselben Sorgfalt zu steuern, die auch auf den Rest der Software Supply Chain angewendet wird.

Genau aus diesem Grund haben wir den JFrog AI Catalog und dessen AI Gateway eingeführt – von Grund auf nach dem Prinzip aufgebaut, dass Ihre Agenten nur so vertrauenswürdig sind wie das, was sie konsumieren, bauen und ausliefern.

Das AI Gateway: Trust by Design

Anders als ein Open-Source-Gateway, das Traffic routet und das Beste hofft, ist das JFrog AI Gateway als sichere, Policy-gesteuerte Verbindungsschicht konzipiert. Es routet den gesamten KI-Konsum – Modelle, MCP-Server, Agent Skills – über einen einzigen, zentralisierten Control Point und bringt Ihren gesamten KI-Footprint unter einheitliche Governance. Darüber hinaus stellt es sicher, dass jede Anfrage authentifiziert und jedes nachgelagerte Asset gründlich geprüft wird, bevor Zugriff gewährt wird.

Dies ist der architektonische Unterschied, der zählt: Das JFrog AI Gateway proxyt nicht nur Traffic – es erzwingt Vertrauen am Verbindungspunkt, bevor ein Agent jemals ein ungeprüftes Modell oder einen MCP-Server berührt.

JFrog MCP Registry: Schluss mit blindem Vertrauen

Die JFrog MCP Registry  ist eine direkte Antwort auf genau die Klasse von Angriffen, die postmark-mcp und LiteLLM repräsentieren. Sie behandelt MCP-Server als vollständig verwaltete Artefakte – so wie JFrog Software-Pakete stets verwaltet und abgesichert hat: mit integriertem Scanning, Policy Enforcement und Versionierung.

Im Kern bietet die MCP Registry:

• Native Security by Design
  Bösartige oder nicht-konforme MCP-Server werden proaktiv blockiert, bevor sie von Agenten heruntergeladen oder ausgeführt werden – nicht erst nach einer Kompromittierung erkannt.
• Zentralisierte Governance
  Entwickler greifen direkt aus ihren IDEs (Cursor, Claude Code, VS Code) auf ein Registry von vorab genehmigten MCP-Servern zu, ohne auf öffentliche Registries zurückgreifen zu müssen.
• Enterprise‑Grade Policy Enforcement
  Blindes Vertrauen wird durch granulare, projektspezifische Berechtigungen ersetzt, die präzise steuern, mit welchen MCP-Servern Agenten verbunden werden dürfen.
• Ein lokales MCP Gateway
  Ein leichtgewichtiger Proxy, der Authentifizierung und Berechtigungsprüfungen transparent auf der Entwicklermaschine übernimmt und sicherstellt, dass Coding-Agenten nur mit vorab geprüften Servern kommunizieren.

Der postmark-mcp-Angriff war erfolgreich, weil ein Entwickler einen MCP-Server aus einer öffentlichen Registry bezog und ihm volles Vertrauen einräumte. Der LiteLLM-Angriff war erfolgreich, weil eine Build-Pipeline einem ungepinnten Open-Source-Paket implizit vertraute. Die JFrog MCP Registry ist so konzipiert, dass keiner dieser Fälle eintreten kann, ohne den Entwickler zu alarmieren – denn jeder MCP-Server ist ein verwaltetes Artefakt, und nicht genehmigte Server werden am Gate blockiert.

Die JFrog MCP Registry ist so konzipiert, dass Angriffe ähnlich wie postmark-mcp oder LiteLLM nicht unbemerkt bleiben – jeder MCP-Server ist ein verwaltetes Artefakt, und nicht genehmigte Server werden am Gate blockiert, bevor Entwicklungs- und Operations-Teams in Mitleidenschaft gezogen werden.

Ein einheitliches System of Record für die gesamte Agentic Supply Chain

Die übergeordnete Vision ist ein einheitliches System of Record, das jede Schicht dessen verwaltet, was Agenten konsumieren und produzieren: Modelle, MCP-Server, Agent Skills, KI-generierten Code und assemblierte Artefakte – alles an einem Ort, unter denselben Sicherheits- und Compliance-Controls wie die gesamte Software Supply Chain.

Dies bezeichnet JFrog als Trusted Agentic Supply Chain. Sie überträgt dieselben Prinzipien, die Software Supply Chains seit Jahrzehnten regieren – Unveränderlichkeit, Provenance, Policy Enforcement und kontinuierliches Scanning – auf jede neue KI-Asset-Klasse, von der Agenten abhängen. Bestätigt wird dies durch Integrationen mit Partnern wie NVIDIA, dessen OpenShell-Runtime die JFrog Plattform als verwalteten Endpoint für die Distribution verifizierter KI-Skills im Enterprise-Maßstab nutzt.

So schützt JFrog Ihre Agentic Supply Chain

Durch eine Partnerschaft mit JFrog können Sie Ihre Organisation mit den folgenden Maßnahmen vor den neuesten Supply-Chain-Angriffen schützen:

• Audit Ihrer AI‑Dependency‑Chains inklusive transitiver Dependencies, die von Agenten und MCP-Plugins geladen werden
• Pinnen Sie Versionen – der LiteLLM-Angriff hat ausgenutzt, dass an mehreren Stellen in der Chain ungepinnte Abhängigkeiten verwendet wurden
• Hören Sie auf, Open-Source-KI-Gateways als inhärent vertrauenswürdige Infrastruktur zu behandeln – routen Sie KI-Traffic über verwaltete, Enterprise-grade Gateways mit Policy Enforcement
• Governance Ihrer MCP‑Server – nutzen Sie die JFrog MCP Registry, um sicherzustellen, dass Agenten nur mit geprüften, genehmigten Servern kommunizieren
• Rotieren Sie Credentials nach jedem Verdacht auf Kompromittierung konsequent – gehen Sie von einer vollständigen Systemkompromittierung aus, nicht nur von der Entfernung eines Pakets
• Einen Trusted AI Catalog aufbauen – nutzen Sie JFrog AI Catalog als Ihr einziges System of Record für Modelle, MCPs, Skills und KI-Pakete

Fazit

Der SDLC hat sich verändert. Entwickler sind nicht mehr die einzigen Akteure in der Pipeline – sie sind Orchestratoren von Agenten-Flotten, die KI-Assets mit Maschinengeschwindigkeit konsumieren. Angreifer folgen ihnen in jede neue Umgebung, die sie besiedeln – einschließlich ihrer Agentic Workflows.

LiteLLM war ein Weckruf. Es hat gezeigt, dass das Open-Source-KI-Gateway im Zentrum Ihrer KI-Infrastruktur keine neutrale Infrastruktur ist, sondern ein High-Value-Target. Die Frage ist, ob Ihr Vertrauensmodell für diese Realität gerüstet ist.

Bei JFrog sind wir überzeugt, dass Vertrauen in die Plattform eingebaut sein muss – und nicht im Nachhinein angenommen oder ergänzt werden darf. Das bedeutet: Open-Source-Pakete kurieren, KI-Modelle verwalten, MCP-Server über eine Registry absichern, die Policy vor der Ausführung erzwingt, und den gesamten KI-Traffic über ein Gateway routen, das Vertrauen an erste Stelle setzt.

Denn in einer KI-beschleunigten Welt ist Geschwindigkeit nur dann ein Vorteil, wenn das Fundament, auf dem Sie bauen, vertrauenswürdig ist.

Buchen Sie eine Demo mit einem unserer Experten, um JFrog‑Lösungen live zu erleben. Erfahren Sie außerdem mehr über  den JFrog AI Catalog, die JFrog MCP Registry und JFrog Curation.