Slopsquatting

Was ist Slopsquatting?

Slopsquatting ist ein Supply-Chain-Angriff, bei dem jemand Pakete unter Namen registriert, die KI-Coding-Tools halluzinieren, sodass Entwickelnde, die eine erfundene Abhängigkeit eines Modells installieren, den Code des Angreifers statt eines Fehlers ziehen. Er funktioniert, weil Modelle wiederholt dieselben plausiblen Paketnamen halluzinieren, was diese Namen vorhersagbar und squatting-wert macht.

Die wichtigsten Punkte

• Die Angriffskette ist einfach: Ein Modell erfindet einen Paketnamen, ein Angreifer hat diesen Namen bereits auf npm oder PyPI mit bösartigem Code registriert, und eine entwickelnde Person oder ein Agent führt den Install-Befehl ohne Prüfung aus.
• Er nutzt ein wiederholbares Muster aus, da Modelle dazu neigen, über Sitzungen hinweg dieselben plausibel klingenden Namen zu halluzinieren, was Angreifern erlaubt, Kandidatennamen zu ernten, indem sie Modelle in großem Maßstab prompten.
• Agentische Workflows erhöhen den Einsatz. Ein KI-Coding-Agent, der seine eigenen Abhängigkeiten installiert, kann die gesamte Angriffskette abschließen, ohne dass ein Mensch den Paketnamen liest.
• Gegenmaßnahmen sind gewöhnliche Supply-Chain-Disziplin, angewendet auf einen neuen Auslöser: verifizieren, dass ein Paket existiert und legitim ist, bevor Sie installieren, Lockfiles und private Registries nutzen, und agenteninitiierte Installationen hinter Freigabe oder einer Allowlist gaten.

So funktioniert es

Sprachmodelle generieren Code, indem sie plausible Tokens vorhersagen, und Import-Statements sind keine Ausnahme. Wenn ein Modell Funktionalität braucht, an die es sich nicht präzise erinnert, kann es eine Abhängigkeit ausgeben, die richtig aussieht, den Namenskonventionen des Ökosystems folgt, und nicht existiert. Sicherheitsforschende, die das über 576.000 generierte Code-Beispiele von 16 LLMs hinweg maßen, fanden, dass durchschnittlich 5,2 % der von kommerziellen Modellen empfohlenen Pakete, und 21,7 % bei Open-Source-Modellen, nicht existierten [1]. Entscheidend: Die Erfindungen waren kein zufälliges Rauschen: In derselben Studie wiederholten sich 43 % der halluzinierten Paketnamen in allen 10 Neuläufen desselben identischen Prompts, und 58 % traten über 10 Iterationen hinweg mehr als einmal auf [2].

Diese Vorhersagbarkeit ist der gesamte Angriff. Ein Gegner promptet populäre Modelle mit gängigen Coding-Aufgaben, sammelt die zurückkommenden Paketnamen, filtert auf unregistrierte, und veröffentlicht bösartige Pakete unter diesen Namen. Die Payload läuft typischerweise bei der Installation oder beim ersten Import: Diebstahl von Zugangsdaten, Exfiltration von Umgebungsvariablen, oder eine Hintertür. Von da an reitet der Angriff auf normalem Entwicklerverhalten. Jemand akzeptiert einen KI-Vorschlag, führt pip install oder npm install aus, und die Registry liefert bereitwillig den Code des Squatters. Der Name ist kein Tippfehler von irgendetwas, was Slopsquatting von klassischem Typosquatting unterscheidet; der Name war nie real.

Verteidigungen stapeln sich. Einzelne Entwickelnde verifizieren unbekannte Pakete vor der Installation: die Registry-Seite prüfen, den Repository-Link, die Download-Historie, und das Veröffentlichungsdatum, denn ein letzte Woche erstelltes Paket ohne Repository ist eine rote Flagge. Teams erzwingen Lockfiles, Abhängigkeits-Review bei Pull Requests, private Registries oder Proxys mit Allowlists, und Scanner, die kürzlich veröffentlichte oder Pakete mit niedrigem Reputationswert markieren. Für Agenten ist der Guardrail strukturell: Der Agent schlägt Abhängigkeiten vor, aber ein Mensch oder eine Policy-Prüfung genehmigt sie, und die Sandbox, in der der Agent baut, hat keine Zugangsdaten, die es zu stehlen lohnt.

Beispiel

Eine entwickelnde Person bittet einen Coding-Agenten, Retry-Logik zu einem Python-Service hinzuzufügen, der eine unzuverlässige API aufruft. Der Agent schreibt sauberen Code, der eine Helper-Bibliothek mit einem perfekt idiomatischen Namen importiert, der Aufgabe und Framework verschmilzt, fügt sie dann zu requirements.txt hinzu und führt die Installation als Teil seiner Schleife aus. Das Paket existiert auf PyPI, drei Wochen zuvor veröffentlicht, weil ein Angreifer es aus Modell-Outputs geerntet hatte. Sein Setup-Skript exfiltriert bei der Installation die CI-Umgebungsvariablen. Das Team fängt es im Staging, als ihre Abhängigkeits-Firewall ein Paket markiert, das jünger ist als ihre Mindestalter-Richtlinie. Die Post-Incident-Änderung: agenteninitiierte Installationen lösen jetzt nur noch über den internen Registry-Proxy des Unternehmens auf, der genehmigte Pakete spiegelt und alles andere ablehnt.

Häufige Missverständnisse

Das Missverständnis ist, dass Slopsquatting nur Typosquatting mit einem trendigen Namen ist, bereits von bestehendem Tooling abgedeckt. Typosquatting verteidigt gegen menschliche Finger: Tools vergleichen Namen mit populären Paketen und fangen Ein-Zeichen-Abweichungen ab. Slopsquattete Namen sind nichts nahe. Sie sind neuartige, plausible, konventionsfolgende Namen, die keine Ähnlichkeitsprüfung markieren wird, und die installierende Instanz ist zunehmend ein Agent statt eine Person, die zögern könnte. Die Verteidigung muss sich verschieben von "sieht dieser Name wie ein Tippfehler aus" zu "hat dieses Paket eine verifizierbare Historie."

Package Hallucination

Package Hallucination ist die modellseitige Hälfte des Problems: Ein KI-System referenziert selbstbewusst eine Bibliothek, ein Modul oder eine API, die nicht existiert. Es ist ein spezifischer Fall von KI-Halluzination, und es passiert am meisten bei Nischenaufgaben, neueren Ökosystemen, und plausibel klingenden Kombinationen echter Projektnamen. Für sich genommen ist ein halluziniertes Paket ein Build-Fehler und ein paar verschwendete Minuten. Es wird zum Sicherheitsproblem in dem Moment, in dem jemand den Namen registriert, was genau das ist, was Slopsquatting tut. Der Namenspool ist nicht klein: Die USENIX-Security-2025-Messstudie verzeichnete insgesamt 440.445 Package-Halluzinationen, darunter 205.474 einzigartige nicht existierende Namen, die ein Angreifer registrieren könnte [3]. Die Rate variiert nach Modell und Ökosystem, aber kein aktuelles Modell ist immun, und Agenten, die Install-Befehle in einer Schleife generieren und ausführen, verwandeln jede Halluzination in einen Download-Versuch. Reduzierung hilft: Retrieval gegen einen echten Paket-Index, Verifikationsschritte in der Agentenschleife, und Prompts, die das Modell zwingen, jede neue Abhängigkeit zu begründen, senken alle die Rate. Elimination steht bei aktuellen Architekturen nicht zur Debatte, weshalb die registry- und pipeline-seitigen Verteidigungen das echte Gewicht tragen.

FAQ

Woher kommt der Name Slopsquatting? Er mischt AI Slop, den abwertenden Begriff für nachlässigen, maschinengenerierten Output, mit Typosquatting, dem älteren Angriff, Fast-Treffer-Domain- und Paketnamen zu registrieren. Der Begriff verbreitete sich 2025 in der Security-Community, nachdem Forschung quantifizierte, wie oft Coding-Modelle Abhängigkeiten fabrizieren.

Welche Ökosysteme sind am stärksten exponiert? Jede Registry mit offener, sofortiger Veröffentlichung: npm und PyPI sind die Hauptziele, weil Veröffentlichung reibungslos ist und Install-Skripte Code ausführen. Ökosysteme mit kuratierten oder namensraum-basierten Registries sind schwerer anzugreifen, und interne Mirrors mit Allowlists schließen die Tür fast vollständig.

Wie prüfe ich, ob ein von einer KI vorgeschlagenes Paket echt und sicher ist? Schlagen Sie es direkt in der Registry nach, nicht über eine Suche. Prüfen Sie dann Alter, Download-Zahlen, ein verlinktes Quell-Repository, das tatsächlich den Code enthält, und einen Maintainer mit Historie. Wenn KI-Codegenerierung es vorgeschlagen hat und es eine dieser Prüfungen nicht besteht, behandeln Sie es als feindlich, bis das Gegenteil bewiesen ist.

Quellen

1. arXiv / USENIX Security 2025 (Spracklen et al.). "5,2 % der Paketempfehlungen kommerzieller Modelle und 21,7 % bei Open-Source-Modellen existierten nicht, über 576.000 Code-Beispiele von 16 LLMs hinweg." https://arxiv.org/abs/2406.10279. Abgerufen im August 2026.
2. arXiv / USENIX Security 2025 (Spracklen et al.). "43 % der halluzinierten Paketnamen wiederholten sich in allen 10 Neuläufen desselben Prompts; 58 % traten mehr als einmal auf." https://arxiv.org/html/2406.10279v3. Abgerufen im August 2026.
3. arXiv / USENIX Security 2025 (Spracklen et al.). "440.445 Package-Halluzinationen insgesamt, darunter 205.474 einzigartige nicht existierende Paketnamen." https://arxiv.org/abs/2406.10279. Abgerufen im August 2026.