Der KI-Skill-Marktplatz ist das neue npm. Er wurde vergiftet.

Der KI-Agenten-Skill-Marktplatz ist das neue npm-Register, und er wurde gerade vergiftet. ClawHavoc platzierte über tausend bösartige Skills in OpenClaws ClawHub, bevor es jemand bemerkte, und alles, was es dafür brauchte, war ein eine Woche altes GitHub-Konto. Wir wiederholen eine Ebene höher jeden Lieferketten-Fehler, den wir längst gemacht haben.

Diesen Film habe ich genau so schon gesehen. npm hat uns beigebracht, dass jeder veröffentlichen kann, dass Namen besetzt werden und dass ein beliebtes Paket über Nacht still bösartig wird. PyPI hat uns dasselbe mit Typosquats und Post-Install-Skripten gelehrt. Browser-Erweiterungs-Stores haben gezeigt, dass ein fünf Sterne starkes Tool mit glänzender Beschreibung seine Nutzerbasis verkaufen kann, sobald es übernommen wird. Jetzt geben wir autonomen Agenten einen Marktplatz voller Community-„Skills“ mit Lesezugriff auf Dateien, Netzwerkaufrufen und Shell, und wundern uns, wenn es blutet.

Was war der ClawHavoc-Angriff?

ClawHavoc war eine koordinierte Lieferketten-Kampagne, die 1.184 bösartige Skills in ClawHub platzierte, dem offenen Skill-Marktplatz der viralen Agentenplattform OpenClaw. Der erste bösartige Skill landete am 27. Januar 2026, die Kampagne eskalierte am 31. Januar, und Koi Security gab ihr am 1. Februar den Namen. Repello AI schätzt, dass die Kampagne rund 300.000 Agenten-Nutzer erreichte.

Die Skills waren nicht plump. Sie tarnten sich als beliebte, stark nachgefragte Tools und schleusten ihre Payloads auf drei Wegen ein: gestaffelte Downloads, die nach der Installation weitere Schadsoftware nachzogen, Reverse-Shells über Python-Systemaufrufe und direkte Datenraub-Payloads beim ersten Aufruf. Ein Nachscan am 16. Februar, über den eSecurity Planet berichtete, fand immer noch 824 bestätigte bösartige Skills in einem Register, das auf über 10.700 Einträge angewachsen war. Auf macOS war die Payload eine Variante des Atomic macOS Stealer, der Browser-Zugangsdaten, Schlüsselbunde, Telegram-Daten, SSH-Schlüssel und Krypto-Wallets abgriff, komprimierte und exfiltrierte.

Warum ist das Vertrauensmodell des Marktplatzes kaputt?

Das Vertrauensmodell ist kaputt, weil es den Nutzer bittet, Code anhand seiner Beschreibung zu beurteilen. Um zur Zeit von ClawHavoc auf ClawHub zu veröffentlichen, brauchte man nur ein mindestens eine Woche altes GitHub-Konto. Keine automatische statische Analyse, kein Code-Review, keine Signaturpflicht. Nichts verband die freundliche Skill-Beschreibung mit dem, was der Code tatsächlich tat, sobald ein Agent ihn ausführte.

Diese Lücke ist der ganze Angriff. Ein Mensch, der ein npm-Paket installiert, kann zumindest den Quelltext und die Install-Skripte lesen. Ein autonomer Agent, der einen Skill aus einem Marktplatz wählt, liest die natürlichsprachliche Beschreibung, entscheidet, dass sie zur Aufgabe passt, und führt ihn aus. Die Beschreibung ist vom Angreifer kontrollierte Werbung. Das Verhalten ist, was immer der Autor geschrieben hat. Wenn beide auseinanderlaufen, kann der Agent es nicht erkennen, und der Nutzer, der die Aufgabe delegiert hat, ebenso wenig.

Das haben wir schon einmal gelöst. Hier ist die Landkarte.

Jede Verteidigung, die die Welt der Paket-Register nach ihren eigenen Vorfällen nachrüstete, lässt sich direkt auf den Skill-Marktplatz übertragen. Die Agentenebene steht keinen neuartigen Angriffen gegenüber. Sie steht npm-Angriffen aus dem Jahr 2018 gegenüber, gerichtet gegen Software, die das Immunsystem, das npm über Jahre aufbaute, noch nicht entwickelt hat. Das ist der Vergleich, der am meisten zählt.

Was schützt tatsächlich dagegen?

Vier Kontrollen schützen einen Agenten wirklich vor einem vergifteten Marktplatz: kryptografische Provenienz, damit Sie Builds statt Beschreibungen vertrauen, Least-Privilege-Berechtigungen, damit ein Skill nicht erreicht, was ihn nichts angeht, Laufzeit-Egress-Kontrolle, damit gestohlene Daten nirgendwo hingehen, und Verhaltensprüfung statt Lesen der Werbung. Die Reihenfolge zählt, denn die letzten beiden wirken auch dann, wenn die ersten beiden versagen.

Provenienz und Signierung statt Beschreibungen

Vertrauen Sie dem Build, nicht dem Werbetext. Ein Skill sollte mit einer prüfbaren Signatur und einer Provenienz-Attestierung kommen, die das gelieferte Artefakt auf einen bestimmten Quell-Commit und Build zurückführt. Sigstore-keyless-Signierung und SLSA-Provenienz tun das bereits für Container-Images und Pakete. Solange ein Marktplatz sie nicht verlangt, fixieren Sie Skills auf einen geprüften Commit-Hash und behandeln Sie einen unsignierten Skill so, wie Sie eine unsignierte Binärdatei eines Fremden behandeln würden.

Least-Privilege-Berechtigungen für Agenten

Ein Skill, der Dokumente zusammenfasst, hat keinen Grund, Ihre SSH-Schlüssel zu lesen oder einen ausgehenden Socket zu einem unbekannten Host zu öffnen. Geben Sie jedem Skill den engsten Berechtigungssatz, den die Aufgabe braucht, vorab deklariert, von der Laufzeit erzwungen. Das ist dieselbe Lektion, die Container-Härtung lehrt. Über die Laufzeit-Variante davon habe ich in selbst-gehostete KI absichern geschrieben, und das Prinzip ist identisch: standardmäßig alles entziehen, nur das Gerechtfertigte zurückgeben.

Laufzeit-Egress-Kontrolle

Die AMOS-Payload musste nach Hause telefonieren, um etwas wert zu sein. Gestohlene Schlüsselbunde und Wallets sind nutzlos, solange sie die Maschine nicht verlassen. Eine Default-Deny-Egress-Richtlinie auf der Netzwerkebene bedeutet, dass ein kompromittierter Skill laufen und trotzdem nichts exfiltrieren kann, weil die Verbindung zum Server des Angreifers verweigert wird. Das ist die Kontrolle, die Sie rettet, wenn Provenienz und Berechtigungen beide versagen, und sie ist günstig einzurichten.

Vertrauen Sie der Skill-Beschreibung nicht

Die Beschreibung wird vom Angreifer kontrolliert. Behandeln Sie sie als Werbeaussage, nicht als Spezifikation. Fixieren Sie auf bestimmte geprüfte Versionen, lesen Sie den tatsächlichen Code oder ein vertrauenswürdiges Review davon, bevorzugen Sie Skills mit prüfbarer Provenienz, und lassen Sie einen Agenten niemals automatisch einen Skill installieren, den er mitten in einer Aufgabe gefunden hat. Der Komfort von „der Agent fand ein Tool und nutzte es“ ist genau der Komfort, den ClawHavoc als Waffe nutzte.

Das ist systemisch, kein Einzelfall

ClawHavoc ist der lauteste Fall, nicht der einzige. Ein Cluster verwandter Angriffe im selben Zeitfenster zeigt, dass die Schwachstelle des Agenten-Ökosystems strukturell ist. MemoryTrap vergiftete den persistenten Speicher eines Coding-Agenten, sodass sich die Kompromittierung über Sitzungen hinweg ausbreitete. SymJack nutzte Symlink-Hijacking für Remote Code Execution und brach sechs KI-Coding-Agenten auf einmal. TrustFall erreichte Claude Code, Cursor, Gemini CLI und GitHub Copilot über einen zurückgefallenen Vertrauensdialog mit einem einzigen Klick.

Unter all dem liegt Prompt-Injection, die OWASP als LLM01 einstuft, das Risiko Nummer eins für LLM-Anwendungen 2025 und 2026. Ein Review von 78 Studien aus dem Januar 2026 fand, dass jeder größere Coding-Agent Prompt-Injection erlag, wobei adaptive Angriffe in mehr als 85% der Fälle trafen. Ein Marktplatz ist nur ein Liefermechanismus für diese darunterliegende Schwäche. Wenn Sie einen Agenten entwerfen, der seine eigenen Tools wählt, lesen Sie, wie das mit dem zusammenhängt, was bei der Agenten-Orchestrierung in Produktion bricht.

Die Kompromisse, die niemand gern ausspricht

Jede Verteidigung hier kostet das, was diese Marktplätze viral machte: reibungslosen Selbstbedienungs-Komfort. Es gibt eine echte Spannung, und so zu tun, als gäbe es sie nicht, ist der Weg, auf dem man bei Sicherheitstheater statt Sicherheit landet.

Was ich diese Woche tun würde

Wenn Sie Agenten betreiben, die Skills aus einem Marktplatz ziehen, ist das die Reihenfolge, die ich durcharbeiten würde, jeder Schritt für sich nützlich:

1. Inventarisieren Sie jeden Skill, den Ihre Agenten installieren können, und fixieren Sie jeden auf einen geprüften Commit, nicht auf ein fließendes „latest“-Tag.
2. Schalten Sie Auto-Discovery und Auto-Install ab. Ein Agent sollte niemals einen Skill ausführen, den kein Mensch freigegeben hat.
3. Setzen Sie eine Default-Deny-Egress-Richtlinie vor die Agenten-Laufzeit, mit einer expliziten Allow-List der Endpunkte, die er wirklich braucht.
4. Beschränken Sie die Agenten-Berechtigungen auf die Aufgabe. Ein Dokumenten-Agent braucht keine Shell und keinen SSH-Schlüssel-Zugriff.
5. Bevorzugen Sie Skills mit prüfbarer Provenienz und behandeln Sie unsignierte Skills standardmäßig als nicht vertrauenswürdig.
6. Protokollieren Sie, welche Skills laufen und was sie erreichen, damit das nächste ClawHavoc in Ihrer Telemetrie auftaucht statt in einem Breach-Report.

Fazit

Das Schmerzhafte ist, dass nichts davon neu ist. Wir lernten es auf die harte Tour mit npm und PyPI, schrieben das Playbook und bauten das Tooling. Das Agenten-Ökosystem sprang direkt zu einem Marktplatz ohne Immunsystem, weil schnell ausliefern wichtiger war als sicher ausliefern. ClawHavoc ist die Rechnung für diese Wahl. Die Lösung ist kein klügeres Modell. Es sind Provenienz, Least Privilege und Egress-Kontrolle, mit demselben Ernst angewandt, den wir den Paket-Registern irgendwann gaben, die wir schon einmal vergifteten.

Weiterführende Lektüre: siehe RAG-Pipelines gegen Prompt-Injection absichern, warum KI-Projekte vor der Produktion scheitern, EU AI Act Compliance für Entwickler und den Private-KI-Ansatz hinter Vaultic. Wenn Sie ein LLM in echte Systeme einbinden, beginnen Sie mit warum selten das Modell das Problem ist.