Du lässt dir von einem KI-Assistenten schnell eine Funktion schreiben, die PDFs im Kundenprojekt zusammenführt. Der Code sieht gut aus, oben steht ein npm install pdf-merge-lite, du führst es aus, es funktioniert. Was du nicht siehst: Das Paket pdf-merge-lite gab es gestern noch gar nicht. Die KI hat den Namen erfunden – und jemand hat genau diesen erfundenen Namen abgefangen, ein Paket draufgesetzt und wartet darauf, dass Entwickler es installieren. Dieses Szenario hat 2026 einen Namen: Slopsquatting. Und es trifft ausgerechnet die, die am meisten mit KI-Code arbeiten – also auch kleine Agenturen.
Dieser Beitrag erklärt, wie der Angriff funktioniert, warum er gerade jetzt gefährlich wird und mit welchen wenigen Handgriffen du deine Kundenprojekte davor schützt.
Slopsquatting: Wenn die KI ein Paket erfindet, das Angreifer registrieren
Der Begriff lehnt sich an das bekannte Typosquatting an, verschiebt aber den Ausgangspunkt. Beim klassischen Typosquatting setzen Angreifer auf menschliche Tippfehler: Sie registrieren ein Paket namens cross-env mit einem Dreher als crossenv und hoffen, dass sich jemand vertippt – ein realer Fall aus dem npm-Ökosystem von 2017. Paket-Registries wie npm blockieren inzwischen Namen, die bestehenden zu ähnlich sind, was diese Masche erschwert.
Slopsquatting dreht das Prinzip um. Hier zielen Angreifer nicht auf fehlerhafte Finger, sondern auf eine selbstbewusst falsche KI. Große Sprachmodelle empfehlen beim Programmieren regelmäßig Pakete, die es schlicht nicht gibt – frei erfundene Namen, die plausibel klingen. Ein Angreifer muss diese Namen nur beobachten, registrieren und mit Schadcode füllen. Der nächste Entwickler, dessen KI denselben Namen vorschlägt, installiert dann ahnungslos das präparierte Paket. Die Sicherheitsfirma Aikido bringt es auf den Punkt: Statt auf den Tippfehler eines Menschen zu wetten, wetten die Angreifer darauf, dass eine KI überzeugt daneben liegt.
Der Unterschied ist nicht akademisch. Tippfehler-Namen sehen dem Original ähnlich und lassen sich mit etwas Aufmerksamkeit erkennen. Halluzinierte Namen dagegen können völlig eigenständig und seriös wirken – und eröffnen Angreifern eine ungleich größere Zahl möglicher Ziele.
Wie groß das Problem wirklich ist
Dass KI Pakete erfindet, ist keine Randbeobachtung, sondern inzwischen gründlich vermessen. Eine auf der Sicherheitskonferenz USENIX Security 2025 vorgestellte Studie mit dem Titel „We Have a Package for You!" untersuchte 16 verschiedene Sprachmodelle anhand von rund 576.000 generierten Code-Beispielen. Das Ergebnis: Knapp 19,7 Prozent der von den Modellen empfohlenen Pakete existierten überhaupt nicht. Fast jedes fünfte vorgeschlagene Paket war also eine Erfindung.
Zwei weitere Zahlen aus der Untersuchung machen die Lage für Angreifer besonders komfortabel. Erstens die schiere Menge: Die Forschenden stießen auf über 205.000 einzigartige halluzinierte Paketnamen – ein riesiger Vorrat an potenziellen Zielscheiben. Zweitens die Verlässlichkeit: Rund 43 Prozent der Halluzinationen tauchten bei jedem von zehn Wiederholungsläufen mit demselben Prompt erneut auf. Die Modelle erfinden also nicht wild durcheinander, sondern phantasieren oft denselben Namen immer wieder. Für einen Angreifer heißt das: Er muss nicht raten. Er lässt sich von denselben Modellen die immer gleichen Phantomnamen vorschlagen und registriert sie gezielt.
Interessant ist auch, woher die Erfindungen rühren. Laut der Auswertung von Aikido sind gut die Hälfte reine Fabrikationen, etwa 38 Prozent Verschmelzungen zweier echter Pakete zu einem neuen und rund 13 Prozent Tippfehler-Varianten. In 8,7 Prozent der Fälle schlug ein Modell für Python einen Namen vor, der zwar dort nicht, aber im JavaScript-Ökosystem existierte – ein zusätzliches Einfallstor über Sprachgrenzen hinweg.
Vom Proof of Concept zum echten Angriff
Die Theorie ist längst Praxis. Bereits Anfang 2024 registrierte der Sicherheitsforscher Bar Lanyado ein von KI halluziniertes Python-Paket namens huggingface-cli als Testfall. Innerhalb von drei Monaten verzeichnete das harmlose Platzhalter-Paket nach Angaben von Aikido über 30.000 echte Downloads – von Entwicklern, die dem KI-Vorschlag blind gefolgt waren.
Zwei Jahre später ist aus der Demonstration ein laufendes Risiko geworden. Aikido beschreibt den Fall eines nicht beanspruchten npm-Pakets namens react-codeshift, das sich Anfang 2026 über Forks auf 237 Repositories ausbreitete und weiterhin täglich von KI-Agenten heruntergeladen wurde, die stur ihre Anweisungen abarbeiteten. Ein bereits bösartig gewordenes Paket namens unused-imports kam demnach Anfang Februar 2026 noch auf 233 Downloads pro Woche. Genau hier liegt die neue Brisanz: Solange ein Mensch den Installationsbefehl abtippt, besteht wenigstens die Chance, dass ihm der unbekannte Name auffällt. Autonome KI-Agenten, die Code schreiben und gleich selbst installieren, nehmen diese letzte Kontrollinstanz heraus.
Warum das Thema für Agenturen jetzt akut ist
Kleine Agenturen sind doppelt exponiert. Zum einen gehört KI-gestütztes Programmieren längst zum Alltag – gerade in Teams ohne eigene Entwicklungsabteilung ist der KI-Assistent oft der schnellste Weg zu einer Lösung. Zum anderen landet der so entstandene Code direkt in Kundenprojekten, für deren Sicherheit du haftest. Ein eingeschleustes Schadpaket in der Website eines Kunden ist kein theoretisches Ärgernis, sondern ein handfester Vorfall mit möglichen Melde- und Haftungsfolgen.
Slopsquatting ist dabei nicht dasselbe wie ein klassischer Angriff über eine gekaperte, eigentlich legitime Komponente. Wie du dich gegen manipulierte echte Pakete in der Lieferkette wappnest, haben wir im Beitrag zum Supply-Chain-Angriff über npm beschrieben. Beim Slopsquatting kommt eine zusätzliche Ebene hinzu: Das Einfallstor ist nicht ein echtes Paket, sondern eine Erfindung der KI. Das rückt das Thema in dieselbe Familie wie die generelle Frage, wie sicher KI-generierter Code im Kundenprojekt überhaupt ist.
Dahinter steckt ein grundsätzliches Muster, das weit über das Programmieren hinausreicht: Eine KI-Ausgabe, die niemand gegen eine verlässliche Quelle prüft, ist eine Risikoquelle – egal, ob es sich um einen Paketnamen, eine Rechtsauskunft oder eine Antwort im Kundenchat handelt. Es ist derselbe Grundgedanke, aus dem heraus ein belegbasierter Assistent wie Ragnova nur beantwortet, was sich in den hinterlegten Inhalten tatsächlich belegen lässt. Wo keine Quelle ist, sollte keine Behauptung stehen.
Vier Handgriffe, die das Risiko entschärfen
Die gute Nachricht: Du brauchst kein Sicherheitsteam, um Slopsquatting den Großteil seiner Wirkung zu nehmen. Vier Gewohnheiten reichen weit.
Erstens: Prüfe jedes von der KI vorgeschlagene Paket, bevor du es installierst. Ein kurzer Blick auf die Registry-Seite verrät dir Alter, Download-Zahlen, Zahl der Veröffentlichungen und den Namen des Maintainers. Ein angeblich zentrales Werkzeug, das erst vor drei Tagen angelegt wurde und zwei Downloads hat, ist ein Warnsignal.
Zweitens: Arbeite konsequent mit Lockfiles. Wenn package-lock.json oder das Äquivalent deines Paketmanagers jede Abhängigkeit mit exakter Version und Prüfsumme festhält, zieht ein späterer Build nicht versehentlich ein frisch untergeschobenes Paket.
Drittens: Kopiere Installationsbefehle aus KI-Antworten nie blind in die Konsole. Diese eine Sekunde, in der du den Paketnamen bewusst liest, ist die billigste Sicherheitsmaßnahme überhaupt – und genau die, die autonome Agenten auslassen.
Viertens: Lass Abhängigkeiten automatisiert überwachen. Werkzeuge, die deine Projekte gegen bekannte Schwachstellen und verdächtige Pakete abgleichen, fangen vieles ab, was im Alltag untergeht. Für Agenturen, die solche Pflege ohnehin als wiederkehrende Leistung für Kunden anbieten, ist das zugleich ein Argument fürs eigene Geschäftsmodell.
Keine dieser vier Gewohnheiten kostet nennenswert Zeit, und keine setzt Spezialwissen voraus. Zusammen verschieben sie aber genau die Annahme, auf die Slopsquatting baut – nämlich dass niemand hinschaut. Wo ein zweiter, bewusster Blick zwischen KI-Vorschlag und Installation liegt, verliert der Angriff den Großteil seiner Wirkung.
Fazit
Slopsquatting ist die Schattenseite des Produktivitätsschubs, den KI-Assistenten beim Programmieren bringen. Weil Modelle Paketnamen nicht nur erfinden, sondern denselben Namen verlässlich wieder und wieder erfinden, haben Angreifer einen planbaren Angriffsweg – und erste reale Fälle mit Tausenden Downloads zeigen, dass er funktioniert. Für kleine Agenturen, die viel mit KI-Code arbeiten und für Kundenprojekte haften, ist das kein Nischenthema, sondern eine konkrete Lücke im Arbeitsalltag. Sie lässt sich mit erstaunlich wenig schließen: Pakete vor der Installation prüfen, Lockfiles nutzen, Befehle nicht blind kopieren und Abhängigkeiten überwachen. Der gemeinsame Nenner ist alt und bleibt gültig – prüfe, was die Maschine behauptet, bevor du dich darauf verlässt.
- Slopsquatting nutzt aus, dass KI-Coding-Assistenten regelmäßig Paketnamen erfinden: Angreifer registrieren diese Phantomnamen und füllen sie mit Schadcode.
- Eine USENIX-Studie von 2025 fand, dass rund 19,7 Prozent der von 16 Modellen empfohlenen Pakete nicht existierten – über 205.000 einzigartige erfundene Namen, von denen 43 Prozent bei Wiederholung zuverlässig wieder auftauchten.
- Real belegte Fälle reichen vom Proof-of-Concept-Paket huggingface-cli (über 30.000 Downloads in drei Monaten) bis zu bösartigen npm-Paketen, die 2026 von KI-Agenten automatisch installiert wurden.
- Autonome KI-Agenten, die Code schreiben und Abhängigkeiten gleich selbst installieren, nehmen die letzte menschliche Kontrolle heraus und verschärfen das Risiko.
- Vier Maßnahmen entschärfen den Angriff: Pakete vor der Installation prüfen, Lockfiles nutzen, Installationsbefehle nie blind kopieren und Abhängigkeiten automatisiert überwachen.