Was ist Slopsquatting?

Slopsquatting ist ein Angriffspfad, bei dem ein Angreifer ein Paket unter einem Namen veröffentlicht, den ein Modell vorschlagen kann, obwohl das gemeinte Paket nicht existierte. Für einen Schaden braucht es weitere Schritte. Der Name muss im relevanten Ökosystem auflösbar sein. Ein Mensch oder eine Automatisierung muss ihn akzeptieren und installieren. Das Paket muss in einem folgenreichen Kontext ausgeführt werden.

Ist Slopsquatting dasselbe wie Typosquatting oder Dependency Confusion?

Nein. Slopsquatting beginnt mit einem vom Modell vorgeschlagenen nicht existierenden Namen. Typosquatting nutzt einen Tippfehler oder verwechselbaren Namen. Dependency Confusion nutzt Resolver- oder Namespace-Prioritäten zwischen Paketquellen. Ein kompromittiertes legitimes Paket existierte bereits und wurde später verändert. Die Pfade können zusammenwirken, beginnen aber unter anderen Bedingungen.

Wie häufig sind Pakethalluzinationen?

Die USENIX-Security-2025-Studie testete 16 Modelle, zwei Prompt-Datensätze, Python und JavaScript sowie 576.000 erzeugte Samples. Sie berichtete mindestens 5,2 % halluzinierte Pakete bei den untersuchten kommerziellen und 21,7 % bei den untersuchten Open-Source-Modellen sowie 205.474 eindeutige halluzinierte Namen. Das sind Ergebnisse dieses Experiments, keine universelle aktuelle Prävalenz und kein Beleg erfolgreicher Angriffe.

Stoppt ein Lockfile Slopsquatting?

Ein geprüftes Lockfile kann eine nicht deklarierte Dependency-Änderung in einer kontrollierten Installation sichtbar machen oder verhindern. Es belegt nicht, dass das gesperrte Paket vertrauenswürdig ist, das Lockfile geprüft wurde oder jede Installation es erzwingt. Registry-Richtlinien, Quellenkonfiguration, Provenance-Prüfung, Least Privilege, Review und Monitoring adressieren andere Teile des Pfads.

Welche Nachweise sollte eine Dependency-Entscheidung behalten?

Dokumentiert angeforderte Dependency und Begründung, Paketökosystem und Quelle, aufgelösten Namen und Version, Lockfile-Diff, verfügbare Integritäts- oder Provenance-Daten, geprüften Publisher und Release-Verlauf, Scanner-Ausgabe, Freigabe, Installationsrechte und Restrisikoentscheidung. Der Nachweis gilt für diese Entscheidung und dieses Datum.

Slopsquatting durch erfundene Paketnamen

Zuletzt aktualisiert: 2026-07-17Lesezeit ca. 3 Min.

Slopsquatting ist ein mehrstufiger Paket-Supply-Chain-Pfad, kein Synonym für jede halluzinierte Dependency. Ein Modell schlägt einen nicht existierenden Namen vor; ein Angreifer publiziert darunter; ein Resolver wählt ihn; Mensch oder Agent installiert ihn; und sein Code erreicht nützliche Rechte. Jeder Schritt braucht Nachweise und lässt sich begrenzen, doch keine Einzelkontrolle entfernt das breitere Risiko.

Kurz: Prüft jeden Schritt der Kette. Gab es den Namen schon? Wer hat das Paket gebaut? Welche Quelle und welche Sperre hat das Tool genutzt? Was lief nach dem Download? Ein Lockfile oder Scan kann helfen, doch kein einzelner Check sperrt jeden Weg.

Startet beim Namen im Diff. Prüft ihn gegen die Quelle, die ihr nutzen dürft. Seht nach, ob das Paket echt ist, wer es pflegt und wann es erschien. Sperrt neue Namen bis zur Freigabe, wenn das zum Risiko passt.

Nutzt Lockfile, Hash und Scan als getrennte Checks. Prüft auch Skripte beim Bau und Rechte zur Laufzeit. Wenn ein Check grün ist, bleiben die anderen Fragen offen. Haltet Fund, Wahl und Rest-Risiko fest. So kann ein Mensch den Fall prüfen, ohne einem Namen blind zu trauen.

Inhalt

Mit dem gemessenen Phänomen beginnen

Die USENIX-Security-2025-Studie untersuchte 16 Modelle, zwei Prompt-Datensätze, Python und JavaScript sowie 576.000 erzeugte Samples. Sie berichtete mindestens 5,2 % halluzinierte Pakete bei den untersuchten kommerziellen Modellen, 21,7 % bei den untersuchten Open-Source-Modellen und 205.474 eindeutige halluzinierte Namen. Geprüft am 17. Juli 2026. Das sind begrenzte Experimentbefunde-keine aktuelle universelle Rate, Zahl bösartiger Pakete oder Beleg einer Kompromittierung.

Quellen- und Messgrenze

Scope: Modellgenerierte Python- und JavaScript-Paketempfehlungen, der spätere Registry- und Resolver-Pfad sowie verbraucherseitige Kontrollen.
Stand: 17. Juli 2026
Methode: Modellausgabe, Paketexistenz zum Beobachtungszeitpunkt, Angreiferpublikation, Auflösung, Installation, Ausführung, beobachtete Wirkung, Kontrolle, Nachweis und Restrisiko trennen.
Primärquellen: Experimentpopulation: Das Paper untersuchte 16 codegenerierende Modelle mit zwei Prompt-Datensätzen und 576.000 erzeugten Samples in Python und JavaScript.USENIX-Security-2025-Paper · 2026-07-17Die Ergebnisse hängen von Modellen, Prompts, Ökosystemen, Zeitpunkten und der Paketexistenz-Methode des Papers ab.
Beobachtete Pakethalluzinationen: Das Paper berichtet mindestens 5,2 % für die untersuchten kommerziellen Modelle, 21,7 % für die untersuchten Open-Source-Modelle und 205.474 eindeutige halluzinierte Paketnamen.USENIX-Security-2025-Paper · 2026-07-17Diese Werte sind Experimentausgaben, keine universelle Prävalenzschätzung oder Vorfallzahl.
Verbraucherseitige Grenze: BSI und ANSSI empfehlen, KI-Coding-Ausgaben als nicht vertraut zu behandeln und Dependencies sowie generierten Code in einem breiteren Sicherheitsprozess zu prüfen.BSI/ANSSI-Empfehlungen · 2026-07-17Empfehlungen benennen Risikobehandlungen; sie belegen nicht Setup oder Wirksamkeit einer Kontrolle in einem konkreten Workflow.
Nicht abgeleitet: Kein behaupteter Slopsquatting-Vorfall und keine aktuelle Angriffshäufigkeit
Keine Übertragung der Befunde auf jedes Modell, jeden Prompt, jede Sprache, Registry oder jedes Datum
Kein Sicherheitsurteil aus Paketname, Lockfile, Scanner, Mirror oder Allowlist allein
Grenzen: Ein halluzinierter Name ist noch kein Angreiferpaket und keine erfolgreiche Installation
Paketexistenz, Ownership, Resolver-Setup und Registry-Verhalten können sich ändern
Kontrollen reduzieren einzelne Pfade; Konfigurations-, Publisher-, transitive und Laufzeitrisiken bleiben

Die zitierte Studie misst Pakethalluzinationen in einem definierten Experiment; sie misst weder aktuelle Ökosystem-Prävalenz noch erfolgreiche Kompromittierung oder die Wirksamkeit eurer Kontrollen.

Benachbarte Supply-Chain-Pfade getrennt halten

Slopsquatting beginnt mit einem vom Modell vorgeschlagenen Namen, der zum relevanten Beobachtungszeitpunkt in der vorgesehenen Quelle nicht existierte. Typosquatting beginnt mit einem verwechselbar ähnlichen Namen. Dependency Confusion beginnt mit Quellen- oder Namespace-Priorität. Die Kompromittierung eines legitimen Pakets beginnt, nachdem Paket oder Publisher bereits existiert. Dieselbe Registry, derselbe Resolver oder dieselbe Laufzeit kann in mehreren Pfaden vorkommen; ähnliche Wirkung belegt nicht dieselbe Bedrohung.

Den Pfad verfolgen, bevor das Angriffslabel fällt

Modellvorschlag, veröffentlichtes Paket, Installation und beobachtete Wirkung sind getrennte Ereignisse mit getrennten Nachweisen.
	Modellvorschlag	Angreiferpublikation	Auflösung und Installation	Ausführung und Wirkung	Benachbarte Angriffsklasse
FrageWas muss belegt werden?	Nannte das Modell ein Paket, das damals in der vorgesehenen Quelle fehlte?Bedrohungszerlegung · 2026-07-17Eine Prüffrage, kein Vorfallbefund.	Wurde der Name von einem Angreifer statt einem legitimen Owner publiziert?Bedrohungszerlegung · 2026-07-17Eine Prüffrage, kein Vorfallbefund.	Welche Quelle, welchen Namen und welche Version löste der Paketmanager auf?Bedrohungszerlegung · 2026-07-17Eine Prüffrage, kein Vorfallbefund.	Welcher Code lief mit welcher Identität sowie Daten-, Netzwerk- und Dateisystemrechten?Bedrohungszerlegung · 2026-07-17Eine Prüffrage, kein Vorfallbefund.	Begann der Pfad stattdessen mit Tippfehler, Quellenpriorität oder Kompromittierung eines bestehenden Pakets?Bedrohungszerlegung · 2026-07-17Eine Prüffrage, kein Vorfallbefund.
KontrolleWas begrenzt diesen Schritt?	Geerdete Kataloge, Dependency-Richtlinie und explizite AuftragsgrenzenMehrschichtige BeispielkontrolleKontrollen für tatsächliches Ökosystem und Resolver auswählen und testen.	Freigegebene Quellen, Namespace-Ownership, Provenance-Prüfung und Publisher-ReviewMehrschichtige BeispielkontrolleKontrollen für tatsächliches Ökosystem und Resolver auswählen und testen.	Quellen-Pinning, Scoped Namespaces, Mirrors, Lockfile-Erzwingung und FreigabeMehrschichtige BeispielkontrolleKontrollen für tatsächliches Ökosystem und Resolver auswählen und testen.	Isolation, Least Privilege, Egress-Grenzen, Laufzeitmonitoring und RollbackMehrschichtige BeispielkontrolleKontrollen für tatsächliches Ökosystem und Resolver auswählen und testen.	Bedrohungsspezifische Registry- und Resolver-Kontrollen plus VorfallanalyseMehrschichtige BeispielkontrolleKontrollen für tatsächliches Ökosystem und Resolver auswählen und testen.
NachweisWas lässt sich behalten?	Prompt/Ausgabe, vorgesehene Quelle, Suchmethode und ZeitstempelBeobachtbares ArtefaktVerfügbarkeit und Bedeutung unterscheiden sich je Paketökosystem.	Registry-Metadaten, Provenance, Artefakt-Hash und Review-ProtokollBeobachtbares ArtefaktVerfügbarkeit und Bedeutung unterscheiden sich je Paketökosystem.	Resolver-Setup, Lockfile-Diff, Installationslog und IntegritätsresultatBeobachtbares ArtefaktVerfügbarkeit und Bedeutung unterscheiden sich je Paketökosystem.	Prozess-, Netzwerk-, Dateisystem-, Identitäts- und VorfalltelemetrieBeobachtbares ArtefaktVerfügbarkeit und Bedeutung unterscheiden sich je Paketökosystem.	Ursprünglicher Name, Quellenreihenfolge, Ownership- und ArtefaktverlaufBeobachtbares ArtefaktVerfügbarkeit und Bedeutung unterscheiden sich je Paketökosystem.
RestrisikoWas bleibt offen?	Eine spätere Publikation kann ändern, ob der Name auflösbar istRestrisikogrenze · 2026-07-17Keine Einzelkontrolle entfernt Supply-Chain-Risiko.	Identitäts- und Provenance-Signale können fehlen, gefälscht oder unvollständig seinRestrisikogrenze · 2026-07-17Keine Einzelkontrolle entfernt Supply-Chain-Risiko.	Fehlkonfiguration, transitive Dependencies und erlaubte bösartige Versionen bleibenRestrisikogrenze · 2026-07-17Keine Einzelkontrolle entfernt Supply-Chain-Risiko.	Ein erlaubtes Paket kann unerwartet handeln oder später kompromittiert werdenRestrisikogrenze · 2026-07-17Keine Einzelkontrolle entfernt Supply-Chain-Risiko.	Ähnliche Folgen belegen nicht denselben AuslöserRestrisikogrenze · 2026-07-17Keine Einzelkontrolle entfernt Supply-Chain-Risiko.

Modellvorschlag, veröffentlichtes Paket, Installation und beobachtete Wirkung sind getrennte Ereignisse mit getrennten Nachweisen.

Kontrollen um Auflösung, Installation und Ausführung schichten

Behandelt eine KI-vorgeschlagene Dependency bis zum Review als nicht vertraut. Begrenzt Quellen und Namespaces und macht neue Dependencies zu expliziten Scope-Änderungen. Prüft Lockfile und Publisher-Nachweise. Behaltet Integritäts- oder Provenance-Daten des Ökosystems, scannt Artefakte, begrenzt automatische Installationsrechte, isoliert Builds und beschränkt Egress und Credentials. Die BSI/ANSSI-Empfehlungen ordnen Dependency- und Codeprüfung in einen breiteren Sicherheitsprozess ein.

Geprüft am 17. Juli 2026. Eine Allowlist kann Auflösung begrenzen, ein Lockfile Änderungen sichtbar machen und ein Scanner bekannte Regeln auswerten. Keines davon belegt allein Paketvertrauen.

Wo Reality Graph ansetzt

Reality Graph kann einen KI-Coding-Run an deklarierte Dateien, Dependency-Grenzen, ausgewählte Checks, beobachtete Ergebnisse, geänderte Dateien und eine Operatorentscheidung binden. So lässt sich eine nicht deklarierte Dependency sichtbar machen und Review-Evidenz behalten. Es prüft nicht jeden Paket-Payload, betreibt keine Registry, validiert keine Publisher-Identität, überwacht kein Laufzeitverhalten und ersetzt weder Paketmanager- noch Scanner-, Build-Isolations- oder Incident-Response-Kontrollen. Siehe die breitere Grenze für KI-Code-Schwachstellen.

Ein begrenzter Nachweis kann zeigen

Welche Dependency warum aus welchem Ökosystem und welcher Quelle angefordert wurde
Welche Namen, Versionen, Hashes, Quellen, Lockfile-Änderungen und Policy-Ergebnisse beobachtet wurden
Wer freigab, welche Checks liefen und welche Restrisiken akzeptiert wurden

Er kann nicht belegen

Dass ein nicht existierender Vorschlag oder verdächtiges Paket einen Slopsquatting-Angriff beweist
Dass Allowlist, Mirror, Lockfile, Scanner, lokales Modell oder Prüfung Supply-Chain-Risiko entfernt
Dass Publisher-Ownership, Paketinhalt, transitive Dependencies oder Laufzeitverhalten sicher bleiben

Eine governte Dependency-Entscheidung kann Pfad und beobachtete Kontrollen dokumentieren; sie belegt nicht die Sicherheit einer Registry, eines Pakets oder künftiger Installationen.

FAQ

Was ist Slopsquatting?: Slopsquatting ist ein Angriffspfad, bei dem ein Angreifer ein Paket unter einem Namen veröffentlicht, den ein Modell vorschlagen kann, obwohl das gemeinte Paket nicht existierte. Für einen Schaden braucht es weitere Schritte. Der Name muss im relevanten Ökosystem auflösbar sein. Ein Mensch oder eine Automatisierung muss ihn akzeptieren und installieren. Das Paket muss in einem folgenreichen Kontext ausgeführt werden.
Ist Slopsquatting dasselbe wie Typosquatting oder Dependency Confusion?: Nein. Slopsquatting beginnt mit einem vom Modell vorgeschlagenen nicht existierenden Namen. Typosquatting nutzt einen Tippfehler oder verwechselbaren Namen. Dependency Confusion nutzt Resolver- oder Namespace-Prioritäten zwischen Paketquellen. Ein kompromittiertes legitimes Paket existierte bereits und wurde später verändert. Die Pfade können zusammenwirken, beginnen aber unter anderen Bedingungen.
Wie häufig sind Pakethalluzinationen?: Die USENIX-Security-2025-Studie testete 16 Modelle, zwei Prompt-Datensätze, Python und JavaScript sowie 576.000 erzeugte Samples. Sie berichtete mindestens 5,2 % halluzinierte Pakete bei den untersuchten kommerziellen und 21,7 % bei den untersuchten Open-Source-Modellen sowie 205.474 eindeutige halluzinierte Namen. Das sind Ergebnisse dieses Experiments, keine universelle aktuelle Prävalenz und kein Beleg erfolgreicher Angriffe.
Stoppt ein Lockfile Slopsquatting?: Ein geprüftes Lockfile kann eine nicht deklarierte Dependency-Änderung in einer kontrollierten Installation sichtbar machen oder verhindern. Es belegt nicht, dass das gesperrte Paket vertrauenswürdig ist, das Lockfile geprüft wurde oder jede Installation es erzwingt. Registry-Richtlinien, Quellenkonfiguration, Provenance-Prüfung, Least Privilege, Review und Monitoring adressieren andere Teile des Pfads.
Welche Nachweise sollte eine Dependency-Entscheidung behalten?: Dokumentiert angeforderte Dependency und Begründung, Paketökosystem und Quelle, aufgelösten Namen und Version, Lockfile-Diff, verfügbare Integritäts- oder Provenance-Daten, geprüften Publisher und Release-Verlauf, Scanner-Ausgabe, Freigabe, Installationsrechte und Restrisikoentscheidung. Der Nachweis gilt für diese Entscheidung und dieses Datum.

Weiterlesen

SicherheitSicherheitslücken in KI-CodeVeracodes 100+ LLMs: 45 % führten OWASP-Top-10-Lücken ein, XSS scheiterte bei 86 %, Java bei 72 % - und Security blieb über Modellgenerationen flach. Die Klassen, die Ursachen und ein deterministisch-zuerst geordneter Verteidigungs-Stapel.Local-firstWas KI-Coding-Tools alles mitlesenPrompts, Repo-Kontext, Indizes, Telemetrie - die fünf Übertragungspfade auf Gegenmaßnahmen abgebildet, mit den gemessenen Zahlen: KI-gestützte Commits leaken Secrets doppelt so oft.Alle ArtikelDie ganze Sammlung - 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.

Quellen

Wollt ihr sehen, wie euer letzter Agenten-Run ausgesehen hätte?

Zugang anfragen