ClawHub, der Community-Skill-Marktplatz von OpenClaw, wuchs im Februar 2026 von 2.857 auf über 10.700 indexierte Skills. Im selben Zeitraum stieg die Zahl bestätigter schädlicher Skills laut Antiy CERT von 341 auf 1.184. Etwa jedes neunte Paket war kompromittiert. Neue Verifizierungsmechanismen, Code-Signierung, automatisierte Scans oder Publisher-Identitätsprüfungen führte der Marktplatz in dieser Zeit nicht ein. ClawHub hatte keinen Governance-Ausfall. ClawHub hatte nie Governance.
Das Muster ist nicht einzigartig. Antigravitys awesome-skills-Sammlung erreichte innerhalb weniger Wochen 1.304 gelistete Skills, mit einem README-Hinweis, dass Skills “curated, not audited” seien. SkillsMP indexiert über 160.000 von GitHub gescrapte Skills ohne jegliche Sicherheitsprüfung. Jeder neue KI-Agent-Skill-Marktplatz folgt demselben Muster: Katalog maximieren, Vertrauen an die Nutzer delegieren und hoffen, dass nichts schiefgeht. Diese Hoffnung endete im Januar 2026.
Das Wachstum-ohne-Governance-Problem
ClawHubs Veröffentlichungsanforderungen zum Zeitpunkt der ClawHavoc-Kampagne: ein GitHub-Konto, das mindestens eine Woche alt ist, und eine SKILL.md-Datei. Keine statische Analyse. Kein Code-Review. Keine Signatur. Kein Verified-Publisher-Programm. Kein Rate-Limiting für Einreichungen. Das Ergebnis war vorhersehbar.
Eine einzige Autoren-ID, hightower6eu, lud laut Antiy CERTs Analyse 677 schädliche Pakete hoch. Zwölf Autoren-IDs produzierten zusammen 1.184 schädliche Skills. Die Angreifer nutzten automatisiertes Publishing, um die Registry schneller zu fluten, als jeder menschliche Prüfer reagieren konnte. Von manchen Konten kamen Einreichungen “alle paar Minuten.”
Die Angriffskategorien zeigen eine professionelle Supply-Chain-Operation. Über 100 Skills gaben sich als Kryptowährungs-Tools aus (Solana-Wallet-Tracker, Phantom-Wallet-Utilities). 57 tarnten sich als YouTube-Tools. 51 behaupteten, Finanz- oder Social-Media-Integrationen zu sein. Die primäre Schadsoftware war Atomic Stealer, ein macOS-Informationsdieb, der als Malware-as-a-Service für 500 bis 1.000 Dollar pro Monat verkauft wird. Er stiehlt Schlüsselbund-Zugangsdaten, Browser-Daten, Kryptowährungs-Wallets, Telegram-Sitzungen, SSH-Schlüssel und Dateien aus Desktop- und Dokumente-Ordnern.
Der entscheidende Unterschied zu klassischen Supply-Chain-Angriffen liegt im Wirkungsradius. Ein schädliches npm-Paket läuft in Node.js mit begrenztem Systemzugriff. Ein schädlicher Agent-Skill läuft innerhalb eines KI-Agenten, der bereits Shell-Ausführung, vollen Dateisystem-Zugriff, Zugang zu Umgebungsvariablen (einschließlich API-Schlüsseln) und die Fähigkeit hat, Nachrichten über angebundene Dienste zu senden. Snyks ToxicSkills-Audit stellte fest, dass 36% aller ClawHub-Skills erkennbare Prompt-Injection enthalten. Die Angriffsfläche reicht also über ausführbare Payloads hinaus bis zu natürlichsprachlichen Anweisungen, die nur ein LLM befolgen würde.
Warum das Einreichungsvolumen das Modell sprengte
ClawHub stieg von unter 50 neuen Skill-Einreichungen pro Tag Mitte Januar auf über 500 pro Tag Anfang Februar. Eine Verzehnfachung in zwei Wochen. Selbst wenn ClawHub menschliche Prüfer beschäftigt hätte (was nicht der Fall war), hätte das Volumen jeden manuellen Prozess überfordert. Das Marktplatz-Design ging davon aus, dass Wachstum immer gut ist und Community-Kuratierung Qualität nach oben spülen würde. Beide Annahmen erwiesen sich im Maßstab als falsch.
Die Analyse von Repello AI schätzte, dass ClawHavoc über 300.000 KI-Agent-Nutzer betraf. Diese Zahl leitet sich aus OpenClaws Installationsbasis ab. Der Wirkungsradius einer einzigen koordinierten Publishing-Kampagne übertraf damit viele traditionelle Supply-Chain-Angriffe.
Warum “kuratiert” nicht “verifiziert” bedeutet: Die Antigravity-Lektion
GitHub-Awesome-Lists funktionieren als Entdeckungsmechanismus für Entwickler seit 2014. Sie basieren auf Social Proof: Ein Maintainer wählt Projekte aus, für die er bürgt, die Liste bekommt Stars, und die Stars signalisieren Qualität. Als Awesome-Lists für KI-Agent-Skills auftauchten, brachten Nutzer dieselben Vertrauensannahmen mit. Diese Annahmen übertragen sich nicht.
Antigravitys awesome-skills-Repository listet über 1.304 Skills für Claude Code, Cursor, Codex CLI, Gemini CLI und andere Agents. Es enthält eine Installer-CLI, Bundles und Workflows. Die README enthält einen klaren Haftungsausschluss: Skills seien “curated, not audited” und könnten “jederzeit nach der Aufnahme von ihren ursprünglichen Maintainern aktualisiert, geändert oder ersetzt werden.” Doch GitHub-Stars erzeugen ein Vertrauenssignal, das diesem Haftungsausschluss widerspricht. Wenn ein Repository innerhalb von Wochen Tausende Stars sammelt, behandeln Nutzer das als Gütesiegel.
Die Lücke zwischen wahrgenommenem Vertrauen und tatsächlicher Verifizierung ist die zentrale Schwachstelle. Drei unterschiedliche Vertrauensstufen existieren im aktuellen Ökosystem, und Nutzer verwechseln sie regelmäßig:
Ungeprüfte Registries (ClawHub, SkillsMP): Jeder kann publizieren. Kein Review. Die einzige Hürde ist ein GitHub-Konto. Rund 13% der Skills auf ClawHub enthielten zum Zeitpunkt des ToxicSkills-Audits kritische Sicherheitsprobleme.
Kuratierte Sammlungen (Antigravity awesome-skills, VoltAgent awesome-agent-skills): Ein Maintainer wählt aus, welche Skills gelistet werden. Das filtert die schlimmsten Fälle, garantiert aber keine Sicherheit. Ein Skill, der heute die Kuratierung besteht, kann morgen mit schädlichem Code aktualisiert werden. Das Projekt tech-leads-club/agent-skills entstand gezielt, um diese Lücke zu schließen, und positioniert sich als “managed, hardened library” mit Validierung für jeden Skill.
Verifizierte Registries (JFrog AI Catalog): Publisher-Identität wird geprüft. Skills werden beim Upload gescannt. Provenance wird nachverfolgt. Das ist das Modell, zu dem sich npm nach event-stream entwickelt hat, aber fast kein KI-Skill-Marktplatz hat diese Stufe erreicht.
Wer Skills aus einer Awesome-List installiert, glaubt, geprüfte Software zu bekommen. Was man bekommt, ist eine Liste, die jemand gepflegt hat, der den Skill nützlich fand. Der Abstand zwischen diesen beiden Dingen wird in kompromittierten Zugangsdaten gemessen.
Was npm nach den Vorfällen aufgebaut hat
Das JavaScript-Ökosystem hat sieben Jahre damit verbracht, die Sicherheitsinfrastruktur aufzubauen, die KI-Skill-Registries aktuell fehlt. Diese Geschichte ist ein Fahrplan.
2018: event-stream. Ein weit verbreitetes npm-Paket wurde gekapert, um Kryptowährung zu stehlen. Der Angreifer erlangte Commit-Zugriff durch Social Engineering und fügte dann eine gezielte Payload hinzu. Das Paket hatte 2 Millionen wöchentliche Downloads. npms Reaktion war zunächst reaktiv: kompromittierte Version zurückziehen, Nutzer warnen, Dependencies auditieren.
2019-2021: Pflicht-2FA und Token-Management. npm verlangte Zwei-Faktor-Authentifizierung für Pakete mit hoher Reichweite. Granulare Zugriffstoken, Automations-Token für CI/CD und IP-beschränkte Token folgten. Diese Maßnahmen erschwerten Account-Übernahmen, adressierten aber nicht die Publishing-Pipeline selbst.
2022: Verified Publishers. npm führte das Verified-Publisher-Badge ein, das bestätigt, dass die publizierende Entität mit der angegebenen Identität übereinstimmt. Das garantiert keine Code-Qualität, schafft aber Zurechenbarkeit. Wenn ein verifizierter Publisher Malware ausliefert, gibt es eine reale Identität zum Nachverfolgen.
2023: Sigstore-Provenance. npm integrierte Sigstore, um Provenance-Attestierungen zu erzeugen. Wenn ein Paket mit --provenance veröffentlicht wird, erstellt die npm-CLI zusammen mit dem CI/CD-Provider eine kryptografische Attestierung, die das Paket mit einem konkreten Source-Commit und der Build-Umgebung verknüpft. Die Attestierung wird in einem öffentlichen Transparenz-Ledger protokolliert.
2024-2025: Trusted Publishing. npm übernahm Trusted Publishing, das langlebige Secrets vollständig eliminiert. CI/CD-Pipelines authentifizieren sich über OpenID Connect statt über gespeicherte Token. PyPI folgte einem parallelen Pfad.
KI-Skill-Registries haben keine dieser Schichten. Keine 2FA-Pflicht für Publisher. Keine verifizierte Identität. Keine Provenance-Attestierung. Keine Build-Transparenz. Keine Trusted-Publishing-Pipeline. Wie Snyks Forscher feststellten: Dieses Modell “versagt offensichtlich im Maßstab.”
Die Vertrauenspyramide, die KI-Skills brauchen
Die Bausteine für eine kontrollierte KI-Skill-Registry existieren bereits. Sie wurden nur noch nicht für Agent-Skills zusammengesetzt.
Identität und Provenance
JFrogs AI Catalog startete im März 2026 als zentrale Steuerungsebene, die alle KI-Skills beim Upload automatisch scannt, verifiziert und signiert. Es erkennt Schwachstellen, schädliche Payloads und Compliance-Risiken, bevor Skills die Produktion erreichen.
Der Agent Name Service, aktuell in Diskussion bei der Internet Engineering Task Force, bildet Agent-Identitäten auf verifizierte Fähigkeiten, kryptografische Schlüssel und Endpunkte ab. DNS für Agents: eine Auflösungsschicht, die die behauptete Identität eines Skills an einen verifizierbaren Publisher bindet.
Automatisiertes Scannen bei Veröffentlichung
Cisco veröffentlichte einen Open-Source Skill Scanner, der statische Analyse, Verhaltensanalyse, LLM-gestützte semantische Inspektion und VirusTotal-Integration kombiniert. Snyks mcp-scan nutzt Multi-Modell-Analyse, um Prompt-Injection-Payloads zu erkennen, die regex-basierte Scanner übersehen. Beide Tools existieren heute. Keines wird von einer großen Skill-Registry vor der Veröffentlichung verlangt.
Diese Scanner vor der Listung auszuführen, nicht erst nach der Entdeckung, hätte die ClawHavoc-Kampagne gestoppt, bevor der erste Nutzer einen vergifteten Skill installiert hätte. Die 677 Pakete von hightower6eu folgten identischen programmatischen Mustern, die jeder statische Analyzer erkennen würde.
Was Sie jetzt tun sollten
Bis Registries ihre Governance reparieren, liegt die Last bei den Nutzern. Führen Sie Snyks mcp-scan vor dem Aktivieren jedes Skills aus: uvx mcp-scan@latest --skills. Installieren Sie Skills auf Projektebene (.claude/skills/) statt global, um den Wirkungsradius zu begrenzen. Pinnen Sie Skill-Versionen, indem Sie Repositories forken, statt auf Upstream zu verweisen. Führen Sie ein Inventar aller verwendeten Skills in Ihrem Team.
Für Unternehmen: Behandeln Sie Skill-Governance wie Dependency-Governance. Bauen Sie eine KI-Stückliste (AI Bill of Materials), die den vollständigen Abhängigkeitsgraph jedes eingesetzten Agent-Skills abbildet. Integrieren Sie Skills in Ihre bestehende Software Composition Analysis-Pipeline. Die DSGVO verlangt bei der Verarbeitung personenbezogener Daten durch KI-Agenten ohnehin eine Risikobewertung der eingesetzten Komponenten. Der EU AI Act verschärft diese Anforderungen ab August 2026 zusätzlich für Hochrisiko-KI-Systeme.
Häufig gestellte Fragen
Warum sind KI-Agent-Skill-Marktplätze ein Sicherheitsrisiko?
KI-Agent-Skill-Marktplätze wie ClawHub haben keine grundlegenden Governance-Kontrollen: keine verifizierten Publisher, keine Code-Signierung, kein automatisiertes Sicherheitsscanning vor der Veröffentlichung und kein Provenance-Tracking. Jeder mit einem eine Woche alten GitHub-Konto kann einen Skill veröffentlichen. Antiy CERT fand 1.184 schädliche Skills auf ClawHub im Februar 2026, und Snyks Audit zeigte, dass 36% aller Skills Sicherheitsmängel enthalten. Anders als bei traditionellen Paketmanagern erben Agent-Skills volle Systemrechte inklusive Shell-Zugriff und Credential-Store-Sichtbarkeit.
Was ist der Unterschied zwischen kuratierten und verifizierten KI-Skill-Registries?
Kuratierte Registries wie Antigravity awesome-skills haben einen Maintainer, der auswählt, welche Skills gelistet werden, aber keinen Code prüft oder Änderungen nach der Listung überwacht. Verifizierte Registries wie JFrog AI Catalog prüfen die Publisher-Identität, scannen Skills beim Upload auf Malware und Schwachstellen und verfolgen die Provenance. Kuratiert bedeutet, jemand fand den Skill nützlich. Verifiziert bedeutet, die Identität des Publishers ist bestätigt und der Code wurde gescannt.
Welche Sicherheitskontrollen hat npm, die KI-Skill-Registries fehlen?
npm baute nach dem event-stream-Vorfall 2018 mehrere Sicherheitsschichten auf: Pflicht-Zwei-Faktor-Authentifizierung für reichweitenstarke Pakete, Verified-Publisher-Badges, Sigstore-basierte Provenance-Attestierungen, die Pakete mit Source-Commits verknüpfen, und Trusted Publishing über OpenID Connect. KI-Skill-Registries haben aktuell keine dieser Kontrollen.
Wie kann ich mich beim Installieren von KI-Agent-Skills schützen?
Führen Sie Snyks mcp-scan vor dem Aktivieren jedes Skills aus (uvx mcp-scan@latest --skills). Installieren Sie Skills auf Projektebene (.claude/skills/) statt global, um den Wirkungsradius zu begrenzen. Pinnen Sie Versionen, indem Sie Skill-Repositories forken, statt auf Upstream zu verweisen. Führen Sie ein Inventar aller installierten Skills. Rotieren Sie Zugangsdaten, auf die installierte Skills Zugriff haben. Für Unternehmen: Erstellen Sie eine KI-Stückliste und integrieren Sie Skills in bestehende Software Composition Analysis-Pipelines.
Was war die ClawHavoc-Angriffskampagne?
ClawHavoc war eine koordinierte Malware-Kampagne, die 1.184 schädliche Skills auf OpenClaws ClawHub-Marktplatz im Februar 2026 platzierte. Zwölf Autoren-IDs veröffentlichten Skills, die als Kryptowährungs-Tools, YouTube-Utilities und Finanz-Integrationen getarnt waren. Die primäre Schadsoftware war Atomic Stealer, ein macOS-Informationsdieb. Eine einzige Autoren-ID (hightower6eu) lud 677 schädliche Pakete hoch. Die Kampagne betraf geschätzt 300.000 KI-Agent-Nutzer.