Nach der Ausführung von 1.672 Claude-Skills ist das wahre Sicherheitsrisiko nicht Malware

Bei Entwickler-Tools wie Claude-Skills führt die Sorge um Sicherheit oft zur Suche nach klassischer Malware: versteckte Credential-Stealer, obfuskierte Shell-Befehle und andere verdeckte Payloads. Diese Sorge ist begründet. Der ToxicSkills-Audit von Snyk scannte bis zum 5. Februar 2026 3.984 Skills von ClawHub und skills.sh und fand Prompt-Injection-Muster in 36 % des Ökosystems, 534 Skills mit kritischen Sicherheitsproblemen und 76 durch menschliche Überprüfung bestätigte bösartige Payloads, von denen 8 bei Veröffentlichung noch auf clawhub.ai aktiv waren. Beim parallel stattfindenden ClawHavoc-Vorfall wurden 341 bösartige Skills aus der Registry von ClawHub entfernt. Bösartige Agent-Skills sind nicht nur hypothetisch.

Daher ist es wichtig, präzise zu sein, was unsere Ergebnisse bedeuten – und was nicht. Bei SkillProof installieren und führen wir jeden gelisteten Skill aus und veröffentlichen das Ergebnis, ob erfolgreich oder nicht. Zum Zeitpunkt dieses Artikels haben wir 1.672 Skills getestet: 1045 bestehen den Test (eine Erfolgsquote von 63 %), 560 erfordern manuelle Einrichtung und 67 schnitten schlechter ab als Claude ohne installierten Skill. Uns ist kein anderes Verzeichnis bekannt, das fehlgeschlagene Tests neben den erfolgreichen veröffentlicht.

In diesen 1.672 ausgeführten Tests fanden wir null Instanzen von verdeckter Malware. Dieses Ergebnis ist jedoch mit einem großen Vorbehalt verbunden: Unser Katalog ist keine zufällige Stichprobe einer öffentlichen Registry. Kandidaten werden vorab auf Qualität geprüft, bevor sie überhaupt einen Testplatz erreichen, minderwertige und Spam-Repositories werden auf einer Sperrliste geführt, und die Skills, die es bis zu einem veröffentlichten Ergebnis schaffen, sind bereits mit hoher Wahrscheinlichkeit legitim. Snyk hat die Registry als Stichprobe genommen; wir nehmen eine Stichprobe des Teils, dessen Installation sich lohnt. Beide Zahlen sind wahr und beantworten unterschiedliche Fragen.

Wofür unsere Stichprobe gut ist, ist die Beantwortung einer Frage, die sonst niemand stellt: Wenn man die offensichtliche Malware herausgefiltert hat, worüber muss man sich dann noch Sorgen machen? Die Antwort lautet reproduzierbar: der Berechtigungs- und Fähigkeits-„Blast-Radius“ von legitimen, nützlichen Skills. Dieses Risiko ist schwerer zu scannen, da es sich größtenteils darin verbirgt, welche Genehmigungen ein Skill bei der Installation und zur Laufzeit anfordert.

Was wir nicht fanden: Das Fehlen verdeckter Payloads

Um es klar zu sagen. In über sechzehnhundert einzigartigen Skill-Ausführungen fanden wir:

• Null Instanzen von verdeckter Exfiltration von Anmeldedaten an einen unbekannten Server.
• Null Instanzen eines curl | sh-Payloads, der in den eigenen Dateien eines Skills versteckt war. Mehrere Skills liefern einen curl | bash-Installer in ihrer Repository-README mit, und in einem Fall wird die Drittanbieter-CLI-Installation in der SKILL.md überhaupt nicht erwähnt. Dies sind offengelegte Installationsschritte, die man vor der Ausführung lesen kann, keine versteckten Payloads, aber sie sind dennoch bemerkenswert.
• Null Instanzen von base64-obfuskierten Payloads oder anderen klassischen Verschleierungstechniken, die dazu dienen, die Absicht zu verbergen.
• Null versteckte Anweisungen in einer SKILL.md-Datei, die vom öffentlichen Zweck des Skills abwichen.

Die Suche nach konkreten Malware-Beispielen in unserem getesteten Set bleibt ergebnislos. Das bedeutet nicht, dass Scannen nutzlos ist. Es bedeutet, dass die Scanner, die die meisten Leute verwenden, auf die falschen Signaturen abgestimmt sind. Ein Tool, das nach bösartigen Code-Mustern sucht, findet in unserer Stichprobe nichts; ein Tool, das auf Berechtigungs- und Fähigkeitsmuster abgestimmt ist, würde das meiste, was wir protokolliert haben, erkennen, da diese Muster direkt im Text der Dateien stehen. Der Unterschied liegt darin, wonach man sucht, nicht ob das Suchen an sich funktioniert. Die Ausführung deckt immer noch auf, was beide nicht finden: welche Berechtigungen ein Skill tatsächlich anfordert, wenn man ihn ausführt, und was er in die Konfiguration schreibt, sobald man zustimmt. Für einen tieferen Einblick in unseren Prozess, siehe Wie wir Claude-Skills testen.

Die wahre Bedrohung: Berechtigungs-„Blast-Radius“ bei legitimen Skills

Die bedeutendsten Sicherheitsprobleme fanden wir bei Skills, die ansonsten funktional und wertvoll sind. Zwei der fünf unten genannten Skills bestehen unsere Funktionstests auf Anhieb; die anderen drei erfordern eine manuelle Einrichtung. Keiner von ihnen ist bösartig. Die Gefahr, die von ihnen ausgeht, ist nicht Bösartigkeit, sondern übermäßige Fähigkeit. Ihr „Blast Radius“ – der Umfang dessen, was sie mit den erteilten Berechtigungen tun können – ist unnötig groß. Dies sind nicht zwangsläufig gefährliche Claude-Skills, die man gänzlich meiden sollte, aber sie erfordern einen sorgfältigen Umgang und ein Verständnis der Berechtigungen, die man erteilt.

Übermäßig weitreichender Dateisystemzugriff

Ein häufiges Muster ist die Anforderung von Dateisystemberechtigungen, die weit über das hinausgehen, was der Skill für seinen Betrieb benötigt. Ein Paradebeispiel ist UCTM Init, ein Projekt-Initializer für die uc-taskmanager Plugin-Pipeline. Während der Einrichtung wird eine generische Aufforderung angezeigt, „empfohlene Einstellungen“ anzuwenden, was das Schreiben weitreichender Read/Edit/Write(/**)-Berechtigungen in die lokale Konfigurationsdatei .claude/settings.local.json beinhaltet. In unserem Testlauf mit einem Scratch-Projekt bewirkte diese eine Genehmigung zwei separate Dinge: Sie schrieb die Wildcard-Einträge für Lesen/Bearbeiten/Schreiben, die den eigentlichen Dateisystem-„Blast-Radius“ darstellen, und sie fügte 34 benannte Bash-Berechtigungen in die Projektkonfiguration ein. Die benannten Bash-Einträge sind eine aufgezählte Befehls-Allowlist und stellen die vertretbarere Hälfte dar; der Wildcard-Eintrag ist der Teil, den man lesen sollte, bevor man auf „Ja“ klickt. Der Skill funktioniert und besteht unsere Tests, aber der Umfang, den man genehmigt, ist viel größer als die eigentliche Aufgabe.

API-Token ohne Gültigkeits- und Geltungsbereichsbeschränkung

Ein weiteres wiederkehrendes Problem ist der Umgang mit API-Schlüsseln. Der Skill Add Vercel, der Vercel-Deployment-Credentials in NanoClaw-Agent-Container einbindet, weist den Benutzer an, einen Vercel-API-Token mit dem Geltungsbereich „Full Account“ und ohne Ablaufdatum zu erstellen. Anschließend wird dieser mächtige Token jedem Agenten zugewiesen. Ein kompromittierter oder fehlerhafter Agent könnte theoretisch diesen Token verwenden, um jedes Projekt, Team oder jede Konfiguration innerhalb des gesamten Vercel-Kontos zu lesen, zu ändern oder zu löschen. Die Lösung ist einfach – einen eng gefassten Token erstellen und rotieren –, aber der Standardweg schafft ein erhebliches Risiko.

Die --dangerously-skip-permissions-Fußangel

Claude Code enthält ein Flag, --dangerously-skip-permissions, das die interaktiven Bestätigungsaufforderungen für einen Durchlauf überspringt; die eigene Dokumentation von Anthropic rät, dessen Verwendung auf einen Container oder eine VM zu beschränken. Es ist eine bekannte Power-User-Funktion, aber wir haben mehrere Skills gefunden, die ihre Verwendung normalisieren, indem sie sie in Standardbefehle oder persistente Konfigurationen integrieren. Eine interaktive Sitzung zeigt beim ersten Eintritt in diesen Modus einen einmaligen Akzeptanzdialog an, was genau das ist, was eine persistente Konfigurationseinstellung umgeht. Das Ergebnis verwandelt eine bewusste, pro Durchlauf getroffene Entscheidung in einen unsichtbaren, dauerhaften Zustand verringerter Sicherheit.

Skill	Kontext der Flag-Nutzung	Risiko
OMA Image	Standardbefehl der Sub-Agent-CLI	Ein Kindprozess läuft ohne Berechtigungsprüfungen.
Agentic OS Obsidian	Persistente Dashboard-/Terminal-Konfigurationen	Unbeaufsichtigte Trigger werden ohne Bestätigung pro Durchlauf ausgelöst.
Agy CLI	Empfohlenes Muster für delegierte Durchläufe	Normalisiert die Deaktivierung einer zentralen Sicherheitsfunktion für den Routinegebrauch.

Im Fall von OMA Image enthält der kanonische Befehl für seinen Sub-Agenten das Flag standardmäßig. Bei Agentic OS Obsidian ist das Flag in persistente Konfigurationen für Dashboard-Schaltflächen und Terminal-Profile integriert, was bedeutet, dass Aktionen ohne weitere Sicherheitsabfragen ausgelöst werden können. Agy CLI empfiehlt es als Standardmuster für delegierte Durchläufe. Obwohl die Dokumentation des Skills auf das Risiko hinweist, deaktiviert sein gängiges Nutzungsmuster praktisch einen kritischen Sicherheitsmechanismus. Auch hier handelt es sich um nützliche Tools, aber ihre Standardkonfigurationen tauschen Sicherheit gegen Bequemlichkeit auf eine Weise, die zur Vorsicht mahnt.

Sekundäre Risiken: Datenhandhabung und undichte Abstraktionen

Über explizite Berechtigungserteilungen hinaus beobachteten wir auch schlechte Sicherheitspraktiken, die die Angriffsfläche eines Systems vergrößern oder sensible Informationen preisgeben, auch wenn sie keine aktive Malware darstellen.

Ein Beispiel ist AI Search Hub. Sein Wrapper-Skript kopiert das gesamte Benutzerdatenverzeichnis des Browsers – einschließlich Cookies und aktiver Sitzungen – in einen lokalen, von Git ignorierten Profilordner (chrome_debug_profile_skill). Es legt außerdem das Chrome DevTools Protocol auf Port 9222 auf dem lokalen Rechner frei. Dies ist keine Exfiltration; die Daten verlassen den lokalen Rechner nicht. Es erstellt jedoch eine lokale Kopie sensibler Sitzungsdaten und öffnet einen mächtigen Debugging-Port, was den „Blast Radius“ für jeden anderen lokalen Prozess erweitert, der kompromittiert sein könnte.

Ein weiteres Beispiel ist Google Ad Scraper. Dieser Skill übergibt seinen API-Token als URL-Query-Parameter (?token=...) anstatt in einem Authorization-Header. Query-Strings sind der schlechteste Ort für ein Geheimnis: Sie landen in der Shell-Historie, in Server-Zugriffsprotokollen und bei jedem Proxy auf dem Weg. Derselbe Skill sendet diesen Token auch an einen Drittanbieter-Endpunkt, api.gooseworks.ai, wenn ein entsprechender Schlüssel gesetzt ist. Dies sind keine bösartigen Handlungen, sondern ein Versäumnis, Standardpraktiken zu befolgen, und sie schaffen eine Exposition, die man nicht gewollt hat. Mehr zu diesem Thema finden Sie in unserer Übersicht zur Sicherheit von Claude-Skills.

Die konstruktive Seite: Skills, die die Sicherheit verbessern

Das Skill-Ökosystem ist nicht nur eine Quelle potenzieller Risiken, sondern auch eine Quelle leistungsfähiger Werkzeuge zu deren Minderung. Dasselbe Framework, das einem Skill die Interaktion mit dem Dateisystem ermöglicht, erlaubt es einem Skill auch, dieses auf Schwachstellen zu überprüfen. Wir haben mehrere Skills getestet, die speziell für Sicherheitsüberprüfungen entwickelt wurden.

Skill Security Auditor ist hier ein herausragendes Beispiel. Wir haben ihn gegen eine 13-zeilige Datei getestet, die eine offensichtliche SQL-Injection, eine Command-Injection und einen hartcodierten API-Schlüssel enthielt. Seine Analyse-Skripte haben alle drei Schwachstellen erfolgreich identifiziert. Als Bonus meldete es auch eine fehlende .gitignore-Datei, ein Problem, das ein menschlicher Prüfer übersehen hatte.

Ähnlich haben wir Code Health Check gegen die absichtlich fehlerhafte Express-API laufen lassen, die der Skill in seinem eigenen Repository mitliefert. Es fand alle acht platzierten Probleme, darunter SQL-Injection, einen eval()-basierten Konfigurationsparser, zwei hartcodierte Geheimnisse, einen unterdrückten Fehler und eine tote Funktion. Es lieferte für jedes Problem korrekte Schweregrade sowie genaue Datei- und Zeilennummernangaben.

Diese Tools demonstrieren die Kehrseite der Skill-Fähigkeiten. Indem man einem vertrauenswürdigen Audit-Skill kontrollierten Zugriff auf den eigenen Code gewährt, kann man Teile des Sicherheitsüberprüfungsprozesses automatisieren. Weitere Tools dieser Art finden Sie in unserem Leitfaden zu Claude-Skills für die Sicherheitsüberprüfung.

Wie man sich schützt: Ein praktisches Bedrohungsmodell

Angesichts der Tatsache, dass die Hauptbedrohung in übermäßigen Berechtigungen und nicht in Malware liegt, ändert sich die Verteidigungsstrategie. Es geht weniger um Antivirenprogramme und mehr um operative Disziplin.

1. Von guten Absichten ausgehen, den Geltungsbereich überprüfen: Es ist unwahrscheinlich, dass der Entwickler eines Skills, den man installiert, einen Hack versucht. Es ist aber möglich, dass Unachtsamkeit im Spiel war oder Bequemlichkeit über Sicherheit gestellt wurde. Wenn ein Skill nach Berechtigungen fragt, sollte die Aufforderung gelesen werden. Wenn Schreibzugriff auf das gesamte Home-Verzeichnis angefordert wird, um eine Zeile an eine einzige Konfigurationsdatei anzuhängen, sollte dies verweigert werden.

2. Skills mit kleinem „Blast Radius“ bevorzugen: Suchen Sie nach Skills, die in sich geschlossen sind und dem Prinzip der geringsten Rechte (Principle of Least Privilege) folgen. Ein gutes Beispiel hierfür ist Workthreads. Es ist ein in sich geschlossener Skill ohne Abhängigkeiten. Es ruft git nur über execFileSync mit festen Array-Argumenten auf, um Command-Injection zu verhindern, und es wird mit einer integrierten, deterministischen Schwärzung von Geheimnissen für AWS, GitHub, Slack, OpenAI, Anthropic, JWTs und Bearer-Token vor jeder Ausgabe geliefert. Es wurde eindeutig mit dem Ziel eines kleinen, kontrollierten „Blast Radius“ entwickelt.

3. Ausführungen in einer Sandbox durchführen: Ein neuer, unbekannter Skill sollte nicht auf der primären Produktionscodebasis oder aus dem Home-Verzeichnis ausgeführt werden. Erstellen Sie ein dediziertes Wegwerf-Verzeichnis zum Testen. Verwenden Sie Docker oder andere Container-Technologien für eine noch stärkere Abgrenzung.

4. Der Ausführung vertrauen, nicht nur dem Code: Der einzige Weg, um sicher zu sein, was ein Skill tut, ist, ihn auszuführen und sein Verhalten zu beobachten. Dies ist das Grundprinzip der SkillProof-Methodik. Wir veröffentlichen unsere Testnotizen, einschließlich Sicherheitswarnungen wie die fünf in diesem Artikel, für jeden von uns ausgeführten Skill.

Weiterführende Lektüre: Der praktische Folgeartikel zu diesem Beitrag ist wie die allowed-tools-Deklaration eines Skills tatsächlich den Zugriffsbereich einschränkt, was der Hebel ist, auf den die meisten der oben genannten Probleme zurückzuführen sind. Wie sich das weitere Ökosystem der Verzeichnisse selbst beschreibt im Vergleich zu dem, was es überprüft, finden Sie in unserem Realitätscheck für Verzeichnisse.

Jede hier zitierte Sicherheitswarnung ist öffentlich auf der Katalogseite des jeweiligen Skills einsehbar, zusammen mit dem Testergebnis und der Bewertung, sodass man die Beweise einsehen kann, bevor man etwas installiert. Wer lieber mit einem bereits geprüften Set starten möchte, findet in unserem Security & Code Review Pack zehn getestete Skills für Code-Reviews, Debugging und Contract-Tests.