OWASP Top 10 für LLM-Anwendungen 2026: Was sich geändert hat
13. August 2026, 10 Min. Lesezeit
Agent-Skills, Plugins und von LLMs erfundene Paketnamen sind neue Lieferanten. Was ClawHub, react-codeshift und PromptMink zeigen und was Sie jetzt regeln.
22 Megabyte Füllzeichen. Mehr brauchte es nicht, um einen bösartigen Skill an den Scannern des Marktplatzes ClawHub vorbeizubringen. Der Schadcode stand ganz am Anfang der Datei, danach kam nur noch Polsterung. Die Datei wurde damit so groß, dass viele Analyse-Pipelines sie gar nicht erst verarbeiten. So beschreibt es Unit 42 von Palo Alto Networks in einer Analyse vom 23. Juni 2026. VirusTotal meldete ein sauberes Ergebnis, der Skill blieb zum Download verfügbar.
Insgesamt fanden die Forscher zwischen Februar und Mai 2026 fünf bösartige Skills, die trotz der eingebauten Prüfungen auf ClawHub standen. ClawHub ist der Marktplatz für OpenClaw, einen AI-Agenten, der Skills von Dritten ausführt. Zwei der fünf lieferten macOS-Infostealer aus, getarnt als TradingView-Assistenten. Der dritte war der Skill mit der Polsterung, er lud den Atomic macOS Stealer nach. Die letzten beiden finde ich am interessantesten, und zu ihnen komme ich gleich.
Fünf Skills klingt nach wenig. Mich beschäftigt an dem Fall etwas anderes: Ein Entwickler, der einen Skill installiert, holt sich einen neuen Lieferanten ins Haus. Nur taucht dieser Lieferant in keiner Lieferantenliste auf, in keiner SBOM und in keinem Freigabeprozess.
Beim Thema Software-Lieferkette denken die meisten an Open-Source-Bibliotheken. Dafür gibt es inzwischen Werkzeuge und Routinen, vom Abhängigkeits-Scan bis zur SBOM, die ich im Artikel zur CRA-konformen Softwareentwicklung beschrieben habe. Mit AI-Agenten kommen Lieferanten dazu, für die diese Routinen nicht gebaut wurden.
| Lieferant | Was geliefert wird | Wer prüft es heute meist |
|---|---|---|
| Paket-Registry (npm, PyPI) | Code und Installationsskripte | Scanner, Lockfile, manchmal ein Mensch |
| Skill-Marktplatz | Anweisungen in Markdown, dazu Skripte | der Marktplatz, sonst niemand |
| Plugins und MCP-Server | Werkzeuge, die der Agent aufrufen darf | der Entwickler, der sie einrichtet |
| Modell-Hub | Modellgewichte und Konfiguration | selten jemand |
| Das Sprachmodell selbst | Vorschläge, welches Paket zu installieren ist | niemand |
Die letzte Zeile meine ich ernst. Wenn ein Coding-Agent vorschlägt, ein bestimmtes Paket zu installieren, und der Entwickler mit Enter bestätigt, dann hat das Modell eine Einkaufsentscheidung getroffen. Und das Modell kann sich irren.
Sprachmodelle erfinden gelegentlich Paketnamen, die plausibel klingen und nicht existieren. Eine Studie, die 2025 auf dem USENIX Security Symposium vorgestellt wurde, hat das vermessen: 16 Modelle, 576.000 Code-Beispiele, zwei Programmiersprachen. Bei kommerziellen Modellen waren im Schnitt mindestens 5,2 Prozent der empfohlenen Pakete halluziniert, bei Open-Source-Modellen 21,7 Prozent. Zusammen kamen mehr als 205.000 verschiedene erfundene Paketnamen heraus.
Ein Angreifer muss also nur herausfinden, welche Namen ein Modell gern erfindet, und genau diese Namen in der Registry registrieren. Beim nächsten Entwickler, dem das Modell denselben Namen vorschlägt, läuft dann fremder Code. Das nennt sich Slopsquatting, in Anlehnung an Typosquatting. Beim Typosquatting vertippt sich der Mensch. Beim Slopsquatting vertut sich die Maschine, und zwar reproduzierbar.
Dass das keine Laborübung ist, zeigt ein Fall, den Charlie Eriksen von Aikido Security am 21. Januar 2026 dokumentiert hat. Er fand 237 GitHub-Repositories, deren Agent-Skills den Befehl npx react-codeshift enthielten. Ein Paket dieses Namens hat es nie gegeben. Der Name ist eine Vermischung aus zwei echten Werkzeugen, jscodeshift und react-codemod. Eriksen verfolgte ihn zurück zu einem einzigen Commit vom Oktober 2025, der 47 maschinell erzeugte Skill-Dateien enthielt, offenbar ohne dass ein Mensch sie geprüft hatte. Von dort wanderte der Fehler per Fork und Kopie weiter.
Eriksen hat den Paketnamen dann selbst registriert, bevor es ein Angreifer tun konnte. Laut CSO Online vom 5. Mai 2026 sah er sofort Downloads. Die Skills wurden also tatsächlich benutzt. Ein Paket, das ein Sprachmodell geträumt hat, hatte echte Abnehmer. Man muss das kurz sacken lassen: Niemand hat hier angegriffen. Die Lücke ist von allein entstanden, und sie stand monatelang offen.
Die zweite Entwicklung ist gezielter. ReversingLabs beschreibt unter dem Namen PromptMink eine Kampagne, die das Unternehmen der nordkoreanischen Gruppe Famous Chollima zuordnet. Beobachtet wurde sie von September 2025 bis März 2026, mit mehr als 300 veröffentlichten Versionen von 60 Paketen. Der Aufbau ist zweistufig. Die erste Schicht sind Pakete, die sauber aussehen und keinen Schadcode enthalten. Sie ziehen als Abhängigkeit die zweite Schicht nach, und dort sitzt die Schadfunktion: Abfluss von .env-Dateien, Wallet-Zugangsdaten, in späteren Varianten ganze Quellcode-Verzeichnisse und SSH-Hintertüren.
Auffällig ist die Dokumentation dieser Pakete. Sie ist laut ReversingLabs darauf angelegt, für ein Sprachmodell möglichst glaubwürdig und passend zu wirken, damit es das Paket empfiehlt. In einem Fall hat das funktioniert: Am 28. Februar 2026 wurde in einem Open-Source-Projekt für einen Krypto-Handelsagenten ein solches Paket als Abhängigkeit hinzugefügt, in einem Commit, der Claude Opus als Co-Autor ausweist.
Hier gehört eine Einschränkung hin. Dass die Kampagne primär auf Coding-Agenten zielt, ist eine Schlussfolgerung von ReversingLabs aus der Menge und Machart der Pakete. Belegt ist der eine Commit. Ich halte die Schlussfolgerung trotzdem für plausibel, weil sie wirtschaftlich Sinn ergibt. Wer einen Menschen täuschen will, braucht eine gute Geschichte. Wer einen Agenten täuschen will, braucht eine gute README.
Zurück zu den beiden ClawHub-Skills, die ich oben aufgeschoben habe. Der Skill money-radar gab Finanzempfehlungen. In seiner SKILL.md stand die ausdrückliche Anweisung, immer die Referral-Links des Angreifers zu verwenden. Der Skill letssendit brachte installierte Agenten dazu, Kryptowährung auf der Solana-Blockchain zu bündeln, für ein Pump-and-Dump-Schema. Beides geschah laut Unit 42 über Anweisungen in natürlicher Sprache. Die Forscher nennen das "semantic instruction hijacking".
Ein klassischer Scanner sucht nach Signaturen, verdächtigen Binärdateien, bekannten Domains, verschleiertem Code. In einem Satz wie "Verwende immer die folgenden Links" findet er nichts davon, denn der Satz ist harmloses Englisch. Schädlich wird er erst dadurch, dass ein Agent ihn liest, für eine legitime Anweisung hält und mit seinen Rechten ausführt. Unit 42 formuliert es so: Bösartige Skills können den Arbeitskontext des Agenten ausnutzen, also Dateisystem, Shell und Zugangsdaten, ohne dass es einen herkömmlichen Exploit braucht. Mit der Installation bekommt der Skill die Autorität des Agenten.
Das ist im Kern dasselbe Problem wie bei Prompt Injection, nur mit Vertriebskanal. Ich erwarte deshalb nicht, dass bessere Scanner es lösen. Ein Scanner, der natürliche Sprache auf böse Absichten prüft, ist selbst ein Sprachmodell und lässt sich mit denselben Mitteln täuschen. Die Polsterung mit 22 Megabyte zeigt außerdem, dass schon die klassischen Prüfungen an banalen Dingen wie Dateigrößen scheitern. Eriksen hat für die Konsequenz eine brauchbare Formel gefunden: Skills sind der neue Code. Sie sehen aus wie freundliche Dokumentation und wirken wie ein Programm. Also gehören sie in denselben Review wie Code.
ClawHub hat die fünf gemeldeten Skills übrigens gelöscht und die Konten gesperrt. Der Marktplatz hat reagiert, wie man es erwarten darf. Verlassen würde ich mich darauf nicht.
Falls der Eindruck entsteht, das Problem liege allein bei neuen AI-Werkzeugen: Am 31. März 2026 wurden zwei manipulierte Versionen von Axios veröffentlicht, einer der meistgenutzten JavaScript-Bibliotheken mit über 70 Millionen Downloads pro Woche. Microsoft beschreibt den Ablauf: Über ein kompromittiertes Maintainer-Konto kam eine gefälschte Abhängigkeit namens plain-crypto-js in die Versionen 1.14.1 und 0.30.4. Deren Installationsskript lud ohne jede Nutzerinteraktion einen Fernzugriffstrojaner nach, für macOS, Windows und Linux. Microsoft ordnet den Angriff Sapphire Sleet zu, ebenfalls ein nordkoreanischer Akteur.
Ich erwähne den Fall, weil er die Verbindung zu den Agenten herstellt. Ein Agent, der selbstständig npm install ausführt, holt im Zweifel die neueste Version, inklusive Installationsskript, in Sekunden und ohne dass jemand hinschaut. Die Gegenmaßnahmen für beide Welten sind deshalb weitgehend dieselben.
Die folgenden Maßnahmen sind alle unspektakulär. Keine davon erfordert ein neues Produkt.
Interne Registry für Pakete und Skills. Entwickler und Agenten beziehen Pakete nur über einen internen Proxy, der freigegebene Quellen spiegelt. Für Skills reicht am Anfang ein internes Git-Repository mit Pull-Request-Pflicht. Ein Skill von einem öffentlichen Marktplatz wird dorthin kopiert, gelesen und erst dann benutzt. Die gemeinsame Leitlinie von CISA, NSA und den Partnerbehörden aus Australien, Kanada, Neuseeland und Großbritannien vom 1. Mai 2026 empfiehlt genau das: ein Register vertrauenswürdiger Drittkomponenten führen und die Werkzeugnutzung von Agenten auf eine Freigabeliste von Werkzeugen und Versionen beschränken (Wortlaut beim Canadian Centre for Cyber Security).
Kein Agent installiert Abhängigkeiten ohne Review. Der Agent darf vorschlagen. Eine neue Zeile in der package.json oder requirements.txt ist aber eine Änderung, die ein Mensch im Pull Request sieht und prüft: Existiert das Paket seit Längerem, wer pflegt es, was zieht es nach? Bei PromptMink lag die Schadfunktion in der zweiten Schicht. Ein Blick auf die direkte Abhängigkeit allein hätte nicht gereicht.
Wartefrist für neue Versionen. Die manipulierten Axios-Versionen waren am Tag nach der Veröffentlichung öffentlich analysiert. Wer neue Versionen erst nach einigen Tagen zulässt, sitzt solche Vorfälle einfach aus. pnpm kennt dafür seit Version 10.16 die Einstellung minimumReleaseAge in Minuten, npm die Option min-release-age in Tagen. Welche Frist die richtige ist, kann ich Ihnen nicht belegen. Ich würde mit sieben Tagen anfangen und eine dokumentierte Ausnahme für dringende Sicherheitsupdates vorsehen.
Lockfiles und exakte Versionen. Microsoft empfiehlt nach dem Axios-Vorfall, auf ^ und ~ in Versionsangaben zu verzichten und exakt zu pinnen. In CI wird mit npm ci aus dem Lockfile installiert, nie frei aufgelöst.
Installationsskripte in CI abschalten. Der Axios-Trojaner kam über ein postinstall-Skript. Mit npm ci --ignore-scripts läuft dieses Skript nicht. Einige Pakete mit nativen Bestandteilen brauchen ihre Build-Skripte wirklich, die gibt man dann einzeln frei.
# .npmrc im Projekt
ignore-scripts=true
min-release-age=7
Und die AI-BOM? Ich bin zurückhaltend. Die Leitlinie der Behörden verweist für die Beschaffung von Agentensystemen auf die bestehenden SBOM-Vorgaben der CISA. Ein etabliertes Format, das Skills, Prompts und Agentenkonfiguration sauber abbildet, kenne ich nicht. Bevor Sie dafür ein Werkzeug anschaffen, führen Sie eine schlichte Liste: welcher Skill, welche Quelle, welche Version, wer hat ihn gelesen. Das ist keine Stückliste nach Norm, aber sie beantwortet im Ernstfall die Frage, die zählt.
Technisch ist das alles machbar. Es scheitert in der Praxis daran, dass niemand zuständig ist. Skills und Agentenkonfiguration liegen zwischen Entwicklung, IT-Betrieb und Security, und in Projekten sehe ich oft, dass jede der drei Seiten annimmt, eine der anderen kümmere sich. Vier Entscheidungen würde ich deshalb nach oben ziehen, in dieser Reihenfolge.
| Entscheidung | Wer | Aufwand |
|---|---|---|
| Skills, Plugins und MCP-Server gelten als Software von Dritten und fallen unter den bestehenden Freigabeprozess | CISO, mit Leitung Entwicklung | ein Beschluss, eine Seite Richtlinie |
| Agenten dürfen Abhängigkeiten vorschlagen, aber nur per Pull Request mit menschlichem Review einführen | Leitung Entwicklung | Einstellung in Repository und Agentenkonfiguration, Tage |
| Wartefrist, Lockfile-Pflicht und abgeschaltete Installationsskripte werden Standard in allen Pipelines | Plattform- oder DevOps-Team | pro Pipeline Stunden, dazu Nacharbeit für Pakete mit Build-Skripten |
| Interne Registry für Pakete, internes Repository für Skills | IT-Betrieb, Budget von der Geschäftsführung | Wochen, wenn noch kein Artefakt-Proxy existiert, sonst deutlich weniger |
Die Aufwände sind grobe Einschätzungen aus meiner Erfahrung, keine Messwerte. Sie hängen stark davon ab, wie viele Pipelines und Sprachen Sie betreiben.
Falls Ihr Unternehmen unter NIS2 fällt oder Produkte mit digitalen Elementen nach dem CRA herstellt, ist Sicherheit der Lieferkette ohnehin Teil Ihrer Pflichten. Ob ein Skill-Marktplatz dabei juristisch als Zulieferer zählt, kann ich nicht beurteilen, das ist eine Frage für Ihre Rechtsabteilung. Praktisch würde ich ihn so behandeln. Den regulatorischen Rahmen habe ich im Artikel zu NIS2 und KI zusammengefasst.
Bitten Sie einen Entwickler aus jedem Team, in den Repositories nach Skill- und Agentendateien zu suchen (SKILL.md, AGENTS.md, Ordner wie .claude oder skills) und alle darin enthaltenen Befehle mit npx, pip install, curl oder uvx in eine Liste zu schreiben. Dann prüfen Sie für jeden Paketnamen zwei Dinge: Existiert das Paket, und gehört es dem, von dem Sie es erwarten? Das dauert pro Team einen Nachmittag. Danach wissen Sie, ob bei Ihnen schon ein react-codeshift schlummert, und Sie haben nebenbei die erste Fassung Ihrer Skill-Liste.
13. August 2026, 10 Min. Lesezeit
9. Juli 2026, 10 Min. Lesezeit
14. Mai 2026, 11 Min. Lesezeit
Für Vorträge, Interviews und fachlichen Austausch erreichen Sie mich direkt. Projekte und Beratung laufen über meinen Arbeitgeber ADVISORI, den Kontakt stelle ich gern her.