Typosquatting, das Registrieren einer falsch geschriebenen Version eines beliebten Pakets und das Warten darauf, dass ein Entwickelnde versehentlich das falsche Paket eingibt und installiert, gibt es in npm seit einem Jahrzehnt. Das ist nichts Neues – das Register verfügt über Schutzmechanismen dafür.
Dann kam AI und änderte wieder alles. Slopsquatting ist die neue, AI-spezifische Variante des Typosquatting. Anstatt auf menschliche Tippfehler zu setzen, setzen Angreifer auf AI-Halluzinationen, also Paketnamen, die LLMs selbstbewusst empfehlen, die aber tatsächlich nicht existieren. Eine Zeit lang wurde dies als theoretisches Risiko behandelt, doch das ist nicht mehr der Fall. AI-Halluzinationen sind unter uns, und damit auch die Slopsquatter.
In diesem Artikel werden wir untersuchen, wie Slopsquatting funktioniert, was Forschende derzeit in der Praxis finden und was Sie tatsächlich dagegen tun können.
Was ist Slopsquatting?
Slopsquatting, auch Halluzinations-Squatting genannt, tritt auf, wenn ein Angreifer einen Paketnamen registriert, den AI-Modelle tendenziell halluzinieren, und dann darauf wartet, dass Entwickelnde ihn auf Empfehlung einer AI installieren. Squatting-Angreifer verlassen sich darauf, dass AI-Assistenten selbstbewusst Paketnamen vorschlagen, die nicht existieren, und dass Entwickelnde darauf vertrauen, dass es sich um ein echtes Paket handelt, das sie angefordert haben.
Wenn ein Entwickelnde diesen Paketnamen installiert, erhält er das Paket des Angreifers. Das Paket führt im Allgemeinen ein Post-Install-Skript aus, das alle im Environment vorhandenen Anmeldeinformationen (API-Schlüssel, Cloud-Tokens, npm-Auth-Tokens) stiehlt und an den Angreifer weiterleitet.
Während einige Pakete den Angriff einfach in einem Post-Install-Skript enthalten, verzichten ausgefeiltere Pakete gänzlich darauf, bösartigen Code in das Paket zu integrieren, und nutzen stattdessen die Unterstützung von npm für URL-basierte Abhängigkeiten, um eine Payload zum Zeitpunkt der Installation von einem externen Server abzurufen. Das Paket erscheint jedem naiven statischen Scanner sauber, da kein offensichtlich bösartiger Code vorhanden ist.
Nehmen wir an, Sie bitten Ihre AI, ein JavaScript-Linter-Paket zu installieren. Es bietet an unused-imports und fragt, ob Sie es installieren möchten (falls es das Fragen nicht ganz umgeht). Das klingt nach dem Paket, das Sie schon einmal verwendet haben, also installieren Sie es.
Claude möchte folgenden Befehl ausführen: npm install unused-imports
[y] Akzeptieren [n] Ablehnen [e] Bearbeiten [Esc] AbbrechenDas echte Paket ist jedoch eslint-plugin-unused-imports. Es stellt sich heraus, unused-imports ist ein bösartiges Paket, und Überraschung! Sie haben gerade Malware installiert! (Dies ist tatsächlich ein echtes bösartiges Paket, übrigens, und potenziell ein absichtlicher Slopsquatting-Angriff. Sie können es auf Aikido Intel nachschlagen. npm hat es jetzt unter einem Security Hold.)
LLMs halluzinieren tatsächlich recht häufig Paketnamen. Mackenzie Jackson, Developer Advocate bei Aikido Security, beschrieb eine Halluzination, die er in einer Episode des Secure Disclosure Podcasts erlebte. Er bat eine KI, ihm zu helfen, sein Node.js-Projekt mit einer OrientDB-Datenbank zu verbinden, eine technisch machbare, aber ungewöhnliche Kombination ohne offensichtliche Paketlösung. Anstatt zuzugeben, dass es ratlos war, erfand das Modell Paketnamen. Mackenzie sagt über den Denkprozess der KI: „Ich habe nichts für dich, aber ich muss etwas für dich haben, also hier ist, wie ich denke, dass Pakete dafür heißen würden.“
Worin unterscheidet sich Slopsquatting von Typosquatting?
Typosquatting liegt vor, wenn ein Angreifer ein bösartiges Paket mit einem Namen registriert, der einem beliebten Paket so ähnlich ist, dass ein Benutzer sich vertippt und es unbeabsichtigt verwendet. Angreifer suchen ein häufig heruntergeladenes Paket mit einem leicht falsch zu schreibenden Namen, lassen einen Bindestrich weg, tauschen zwei Buchstaben aus, fügen ein zusätzliches Zeichen hinzu und „squatten“ auf dem falsch geschriebenen Paket, bevor es jemand anderes tut. Typosquatting ist seit mindestens 2017 ein fester Bestandteil von npm, als ein Angreifer veröffentlichte crossenv, ein Squat des beliebten cross-env Pakets. npm verfügt nun über Schutzmaßnahmen dagegen, indem die Registrierung von Paketnamen verhindert wird, die zu ähnlich zu bestehenden sind.
Slopsquatting ist Typosquatting, aber anstatt auf die „dicken Finger“ eines Menschen zu setzen, setzen Angreifer darauf, dass eine KI selbstbewusst falsch liegt. (Ja, so zuverlässig wird KI derzeit eingeschätzt). Der Hauptunterschied zwischen Slopsquatting und Typosquatting, wie wir es in der Vergangenheit kannten, besteht darin, dass die Varianten völlig unterschiedlich aussehen und bei Ersterem eine größere Anzahl von Namen für Angreifer zur Auswahl steht.
Zum Beispiel erwiesen sich 8,7 % der von KI halluzinierten Python-Paketnamen als gültige JavaScript-Pakete. In diesem Fall stellt das Modell die richtige Verbindung zu einer realen Sache her, nur im falschen Ökosystem. Ein fruchtbarer Boden für Angreifer, um Paketnamen aus anderen Ökosystemen zu registrieren.
Forscher der USENIX Security 2025 testeten 16 Modelle über 576.000 Code-Samples hinweg und fanden heraus, dass Halluzinationen vorhersagbaren Mustern folgen: 38 % sind Konfabulationen wie express-mongoose, bei denen das Modell zwei reale Dinge miteinander vermischt, 13 % sind Tippfehler-Varianten und 51 % sind reine Fiktionen. Das ist ein viel größerer Pool an „squattable“ Namen, als Typosquatting je geboten hat, und im Gegensatz zu Typosquatting haben diese neuen Namen nichts, womit sie im Schutzsystem von npm „ähnlich“ wären.
Findet Slopsquatting bereits statt?
Wir glauben schon. Wir sehen Malware-Pakete, deren Namen mit dem Slopsquatting-Muster übereinstimmen, aber wir können nicht beweisen, was die Angreifer mit den Namen beabsichtigen. Nehmen Sie unused-imports, das bestätigte bösartige Paket, über das wir zuvor gesprochen haben. Anfang Februar verzeichnete es immer noch 233 Downloads pro Woche. Diese Entwickelnde folgen entweder KI-Empfehlungen, die immer noch auf diesen Namen verweisen, haben es irgendwo in ihrem Abhängigkeitsbaum und installieren es neu, oder haben es in den Dokumentationen oder auf Stack Overflow gefunden, die nicht aktualisiert wurden.
Forscher finden und beweisen jedoch definitiv die ersten Vorläufer von Slopsquatting in der Praxis. Anfang 2024, Bar Lanyado von Lasso Security bemerkte, dass KI-Modelle wiederholt ein Python-Paket halluzinierten namens huggingface-cli. Das eigentliche Tool wird anders installiert, nämlich als pip install -U "huggingface_hub[cli]", aber Modelle schlugen immer wieder die kürzere, nicht existierende Version vor. Lanyado lud ein leeres Paket unter diesem Namen auf PyPI hoch, um zu sehen, was passieren würde.
huggingface-cli erhielt in drei Monaten über 30.000 authentische Downloads. Alibaba hatte den halluzinierten Installationsbefehl in das README eines ihrer öffentlichen Repositories kopiert. Das Paket war harmlos, aber Lanyado bewies, dass diese Strategie funktioniert. Alibaba hatte einfach Glück, dass Lanyado es herausfand, bevor ein Angreifer es tat.
Eine AI-Paket-Halluzination, die sich von selbst verbreitete
Charlie Eriksen, Sicherheitsforscher bei Aikido fand etwas noch Unglaublicheres– ein halluzinierter Paketname, der sich über echte AI-Infrastruktur verbreitete, wobei echte Agenten versuchten, ihn auszuführen, und den niemand absichtlich platziert hatte. Im Januar 2026 beanspruchte Charlie dieses npm-Paket namens react-codeshift. Das Paket war nicht real, hatte keinen Autor und war definitiv noch nicht registriert worden. Der Name ist eine klassische Halluzination durch Vermischung. Zwei echte Pakete mit ähnlichen Namen existieren, jscodeshift und react-codemod, die ein LLM zusammenmischte, um den Namen zu erfinden react-codeshift.
Das Paket tauchte erstmals in einem einzigen Commit von 47 LLM-generierten Agent Skills auf. Wir können davon ausgehen, dass eine KI gebeten wurde, eine Reihe von Anweisungen für Coding-Agenten zu generieren, und dabei Paketnamen halluzinierte, die sie zur Ausführung dieser Aufgaben benötigen würde. Kein Mensch überprüfte die Ausgabe (oder testete sie zumindest nicht), sodass diese AI-Halluzination über GitHub verewigt wurde.
Als Charlie es als Teil von seiner Forschung zu nicht beanspruchten Paketen, hatte sich der Name dieses nicht existierenden Pakets über Forks auf 237 Repositories verbreitet und war ins Japanische übersetzt worden. Nachdem Charlie es beansprucht hatte, react-codeshift erhielt es weiterhin täglich ein paar Downloads. Das sind AI-Agenten, die Skill-Anweisungen befolgen und npx-Installationen in realen Umgebungen auslösen. Hätte ein Angreifer es zuerst registriert, hätte es einen größeren Slopsquatting-Angriff geben können, der sich organisch verbreitet hätte.
Wie man sich vor Slopsquatting-Angriffen schützt
Überprüfen Sie den Herausgeber, nicht nur den Namen
Die offensichtliche Antwort ist, Paketnamen vor der Installation zu überprüfen, aber so einfach ist es wirklich nicht. Die Download-Anzahl ist kein zuverlässiges Signal (wir haben gesehen, dass bösartige Pakete immer noch regelmäßige tägliche Downloads haben). Was wirklich zählt, ist der Herausgeber: Wer hat dieses Paket wann registriert und entspricht das dem, was man von einem legitimen Maintainer erwarten würde? Ein Paket, das vorgibt, ein eslint Plugin ohne Maintainer-Informationen und einem Registrierungsdatum vom letzten Dienstag ist ein Warnsignal, unabhängig von seinen Download-Zahlen.
Behandeln Sie die autonome Paketinstallation als privilegierten Vorgang
Wenn Sie AI-Agenten betreiben, die Pakete ohne Bestätigung installieren können, Claude Code im Bypass-Modus, ein agentenbasiertes Coding-Setup oder CI-Pipelines mit umfassenden npm-Berechtigungen, entfällt der Verifizierungsschritt, den Sie normalerweise als Mensch durchführen würden. Der Agent wird einfach fortfahren, wenn er die Berechtigung dazu hat. Das ist das Bedrohungsmodell, auf dem Slopsquatting basiert, also passen Sie diese Berechtigungen entsprechend an.
Scannen Sie Ihren vollständigen Abhängigkeitsbaum
Einige halluzinierte Paketnamen landen als verschachtelte Abhängigkeiten statt als direkte Installationen, was bedeutet, dass sie nicht in Ihrer package.json auftauchen werden. Ein Software-Kompositionsanalyse (SCA)-Scanner untersucht Ihren vollständigen Abhängigkeitsbaum, um versteckte, vergrabene bösartige Pakete zu erkennen.
Nutzen Sie SafeChain für Schutz auf npm-Ebene
Aikido SafeChain ist ein Open-Source-Wrapper für npm, npx, yarn, und pnpm der Paketinstallationsbefehle abfängt und sie gegen Aikido Intel überprüft, bevor etwas auf Ihre Maschine gelangt.
Fazit
Nicht beanspruchte Paketnamen waren schon immer beanspruchbar, aber wir haben jetzt KIs, die uns selbstbewusst gefälschte Paketnamen zur Installation liefern, und KI-Agenten, die diese Namen über Repositories verbreiten.
Da Vibe Coding zur Norm wird und immer mehr KI-Agenten im Hummer-Design ohne menschliche Beteiligung zu programmieren beginnen (lesen Sie unseren Artikel „Warum der Versuch, OpenClaw zu sichern, lächerlich ist“), schrumpft das Zeitfenster für einen Menschen, einen schlechten Paketnamen zu erkennen, bevor er ausgeführt wird, immer weiter. Wir haben festgestellt, dass die von LLMs halluzinierten Namen konsistent und wiederholbar sind, und Angreifer nutzen dies aus.
Überprüfen Sie Ihre Abhängigkeitsbäume. Verifizieren Sie Publisher. Und nutzen Sie ein Tool, das zwischen Ihrem Paketmanager und dem Registry sitzt und die Überprüfung für Sie übernimmt.
