Slopsquatting: wenn Ihr KI-Assistent ein Paket installiert, das es nicht gibt

Wer einen Coding-Assistenten um Hilfe bittet, bekommt mit dem Code oft auch gleich eine Bibliothek vorgeschlagen. Meistens ist die Bibliothek echt. Manchmal nicht: Das Modell erzeugt einen Namen, der richtig klingt, den Namenskonventionen des Ökosystems folgt und auf npm oder PyPI schlicht nicht existiert. Wenn Sie den Installationsbefehl ungeprüft ausführen, passiert eines von zwei Dingen. Entweder schlägt die Installation fehl, was lästig, aber harmlos ist. Oder jemand hat unter genau diesem Namen bereits ein Paket veröffentlicht, und Sie haben gerade dessen Code ausgeführt.

Was Slopsquatting ist

Slopsquatting ist der Name für diesen zweiten Fall: Paketnamen zu registrieren, die KI-Modelle gern erfinden, und darauf zu warten, dass jemand sie installiert. Der Begriff wird meist Seth Larson zugeschrieben, dem Security Developer-in-Residence der Python Software Foundation, und spielt auf Typosquatting an, bei dem Angreifer Falschschreibungen beliebter Pakete registrieren. Der Unterschied liegt darin, wer den Fehler macht. Beim Typosquatting vertippt sich ein Mensch. Beim Slopsquatting schlägt ein Modell selbstbewusst den falschen Namen vor, und ein Mensch vertraut ihm.

Das Risiko ist nicht hypothetisch. In einem vielbeachteten Experiment bemerkte ein Forscher, dass Modelle immer wieder ein Paket namens huggingface-cli empfahlen, obwohl das echte Hugging-Face-Tool nicht so installiert wird. Er veröffentlichte unter diesem Namen ein leeres Paket, um zu sehen, was passiert, und es wurde Zehntausende Male heruntergeladen. Das Paket war harmlos. Ein bösartiges wäre es nicht gewesen.

Wie oft Modelle Pakete erfinden

Die bislang gründlichste Studie ist „We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs“, vorgestellt auf der USENIX Security 2025. Die Autoren erzeugten mit 16 verbreiteten Modellen 576.000 Codebeispiele in Python und JavaScript und prüften jedes Paket, auf das der Code verwies. Sie stellten fest, dass der durchschnittliche Anteil halluzinierter Pakete bei kommerziellen Modellen mindestens 5,2 % und bei Open-Source-Modellen 21,7 % betrug, und sammelten 205.474 eindeutige Paketnamen, die nicht existierten.

Zwei Details aus dem Paper sind wichtiger als die Schlagzeilenzahlen. Erstens sind die erfundenen Namen oft reproduzierbar: Als die Autoren Prompts, die eine Halluzination erzeugt hatten, zehnmal erneut ausführten, kamen 43 % dieser Namen jedes Mal wieder. Vorhersagbare Namen sind genau das, was ein Angreifer braucht. Zweitens sind die meisten keine knappen Falschschreibungen echter Pakete, eine Tippfehlerprüfung fängt sie also nicht ab. Nur etwa 13 % lagen innerhalb von ein oder zwei Zeichen eines existierenden Namens.

Seit diesen Experimenten sind die Modelle besser geworden, und Assistenten, die die Registry durchsuchen, bevor sie ein Paket vorschlagen, machen das Problem seltener. Seltener heißt aber nicht verschwunden, besonders bei Nischenaufgaben, zu denen das Modell nur wenige echte Beispiele gesehen hat.

Warum der Angriff praktikabel ist

Auf npm oder PyPI zu veröffentlichen ist kostenlos und dauert Minuten. Ein Angreifer muss nichts kompromittieren; er muss nur Namen erraten, die Modelle erzeugen, und sie zuerst registrieren. Installationsskripte erledigen dann den Rest: npm führt preinstall- und postinstall-Skripte standardmäßig aus, und ein Python-Paket kann beim Bauen oder Importieren Code ausführen. Eine einzige Installation auf einem Entwickler-Laptop oder einem CI-Runner kann SSH-Schlüssel, Cloud-Zugangsdaten und Tokens in Umgebungsvariablen offenlegen.

Agents verschärfen das. Wenn ein Assistent npm install oder pip install selbst ausführen kann, schaut womöglich überhaupt kein Mensch mehr auf den Paketnamen.

Ein Paket in einer Minute prüfen

Bevor Sie eine Abhängigkeit hinzufügen, die Sie nicht selbst ausgewählt haben, schlagen Sie sie in der Registry nach:

# npm: does it exist, who publishes it, when was it first released?$ npm view some-package name version time.created repository.url # PyPI: same questions, from the JSON API$ curl -s https://pypi.org/pypi/some-package/json | jq '.info | {name, version, home_page, project_urls}'

Stellen Sie dann ein paar schnelle Fragen:

• Existiert es überhaupt? Ein 404 bedeutet, dass der Name erfunden wurde. Legen Sie ihn nicht an und installieren Sie keine „ähnlich genug“ wirkende Alternative, ohne auch diese zu prüfen.
• Ist es brandneu? Ein Paket, das erst in den letzten Wochen veröffentlicht wurde, mit einer einzigen Version und ohne Historie, verdient einen zweiten Blick, besonders wenn sein Name dem Vorschlag Ihres Assistenten entspricht.
• Verweist es auf ein echtes Projekt? Ein verlinktes Repository mit Commits, Issues und anderen Nutzern ist ein gutes Zeichen. Ein leeres oder fehlendes Repository nicht.
• Ist es das Paket, das die Dokumentation zur Installation nennt? Die eigene Dokumentation des echten Tools ist die beste Quelle für den korrekten Namen. huggingface-cli im Vergleich zum dokumentierten Installationsbefehl zeigt gut, warum.

Gewohnheiten, die helfen

• Verwenden Sie Lockfiles und installieren Sie in der CI daraus (npm ci, pip install -r mit gepinnten Versionen und Hashes), damit sich während eines Builds kein neuer Name einschleichen kann.
• Reviewen Sie Änderungen an Abhängigkeiten in Pull Requests so sorgfältig wie Codeänderungen. Ein Diff, der drei Pakete hinzufügt, verdient drei Nachschlagevorgänge.
• Bitten Sie Ihren Assistenten, die Registry-Seite oder die offizielle Dokumentation des Pakets zu verlinken, wenn er etwas Neues vorschlägt. Das ist ein günstiger Weg, einen erfundenen Namen aufzudecken.
• Wenn Ihr Agent selbstständig Installationen ausführen kann, geben Sie ihm eine Allowlist oder verlangen Sie eine Bestätigung für neue Abhängigkeiten.
• Erwägen Sie, Installationsskripte standardmäßig zu deaktivieren (npm config set ignore-scripts true) und nur für Pakete zu aktivieren, die sie brauchen. Das bricht manche Pakete, testen Sie es also vorher.

Den langweiligen Teil automatisieren

Manuelles Nachschlagen funktioniert für ein Paket. Es skaliert nicht auf ein Repository mit Hunderten Abhängigkeiten oder auf Importe, die in Code vergraben sind, den ein Assistent letzte Woche erzeugt hat. Das ist eine gute Aufgabe für Tooling.

Die Suite für KI-Code-Risiken von vetkit schlägt die Abhängigkeiten und Importe in Ihren Manifesten in öffentlichen Registrys wie npm und PyPI nach. Sie meldet Namen, die nicht existieren, Versionen, die nie veröffentlicht wurden, und Pakete, die in den letzten 30 Tagen erstmals veröffentlicht wurden. An die Registrys werden nur Paketnamen und Versionen gesendet, nie Ihr Quellcode, und Pakete aus privaten Registrys oder Ihren eigenen Workspaces werden nicht nachgeschlagen. Der MCP-Server von vetkit bietet außerdem eine Paketprüfung, sodass ein Assistent einen Namen verifizieren kann, bevor er irgendetwas installiert.

Was Sie auch verwenden, das Prinzip ist dasselbe: Ein Paketname, der von einem Modell stammt, ist eine Behauptung, und Behauptungen lassen sich günstig überprüfen, bevor Sie sie ausführen.