Was ist Slopsquatting und wie schützt man sich davor?

Slopsquatting ist das Registrieren von Paketnamen, die KI-Modelle halluzinieren – Entwickler, die eine KI-empfohlene Dependency ungeprüft installieren, erhalten den Code des Angreifers. Der Schutz schließt den Installations-Pfad: Lockfiles und interne Mirrors, damit unbekannte Namen nicht auflösen; ein Review-Gate für jede neue Dependency; und jede Dependency, die ein KI-Run hinzufügt, als Scope-Ereignis behandeln, das explizite Freigabe braucht. Den Begriff prägte PSF-Security-Entwickler Seth Larson.

Wie häufig sind halluzinierte Pakete, gemessen?

Die USENIX-Security-2025-Studie „We Have a Package for You!“ hat es über 16 code-generierende Modelle gemessen: 19,7 % der empfohlenen Pakete existierten nicht, mit über 205.000 einzigartigen erfundenen Namen. Kommerzielle Modelle halluzinierten weniger als Open-Source-Modelle, aber kein Modell war sauber. Die Größenordnung zählt: Das ist kein gelegentlicher Ausrutscher, sondern eine systematische Output-Eigenschaft – groß genug, um sie abzuernten.

Warum ist die 43-%-Persistenz-Zahl so wichtig?

Weil sie eine Kuriosität in eine Angriffsfläche verwandelt. Als die Forscher halluzinations-auslösende Prompts zehnmal wiederholten, tauchten 43 % der erfundenen Namen jedes einzelne Mal wieder auf (58 % mehr als einmal). Ein Name, den Modelle zuverlässig neu erfinden, ist ein Name, den ein Angreifer einmal registriert und dann wartet – die Opfer kommen von selbst, gelenkt von denselben statistischen Rillen im Modell. Zufallsrauschen wäre nicht ausnutzbar; wiederholbare Halluzination ist Infrastruktur für den Angreifer.

Wurde Slopsquatting schon in freier Wildbahn ausgenutzt?

Die Bausteine sind alle dokumentiert: Typosquatting- und Dependency-Confusion-Angriffe haben eine lange Vorfalls-Historie, bösartige Pakete erscheinen kontinuierlich auf Registries, und Forscher haben den Weg von der Halluzination zur Registrierung Ende-zu-Ende demonstriert. Konkrete Vorfälle spezifisch Slopsquatting zuzuschreiben ist schwerer – gerade weil eine erfolgreiche Installation wie jede Dependency-Ergänzung aussieht. Das ist ein Argument dafür, den Pfad zu schließen, nicht dafür, auf den Schlagzeilen-Fall zu warten.

Schützen die Paket-Registries dagegen?

Teilweise und zunehmend: Registries entfernen gemeldete Malware, manche scannen Uploads, und Ökosystem-Arbeit an Trusted Publishing und Provenance hebt die Latte. Nichts davon verhindert, dass ein Angreifer einen plausiblen, unbeanspruchten Namen mit funktionierend-aber-bösartigem Code registriert, bevor ihn jemand meldet. Registry-Hygiene ist echter Fortschritt und kein Ersatz für das Gate auf Konsumenten-Seite: Euer Build sollte keine Namen auflösen, die niemand freigegeben hat.

Sicherheit

Slopsquatting

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 4 Min.

Slopsquatting ist der Lieferketten-Angriff, der aus KI-Halluzination geboren wurde: Angreifer registrieren die Paketnamen, die Modelle erfinden – und wer KI-empfohlene Dependencies ungeprüft installiert, erhält den Code des Angreifers. Die Zahlen machen es systematisch: 19,7 % der LLM-empfohlenen Pakete existierten nicht, über 205.000 einzigartige erfundene Namen, und 43 % dieser Halluzinationen wiederholen sich konsistent – vorhersagbare Ziele. Die Verteidigung schließt den Installations-Pfad: Mirrors, Lockfiles und ein Gate für jede neue Dependency.

Inhalt

Die Mechanik, Schritt für Schritt

Der Angriff braucht keinen Exploit – er reitet auf dem Vertrauen in den Paketmanager. Ein Modell, nach einer Lösung gefragt, empfiehlt eine Dependency, die nicht existiert, aber exakt richtig klingt. Ein Angreifer, der weiß, welche Namen Modelle zu erfinden pflegen, registriert einen davon auf der öffentlichen Registry – mit Code, der gut genug funktioniert, um keinen Alarm auszulösen, plus Payload. Ein Entwickler (oder ein Agent mit Installations-Rechten) führt den Install-Befehl aus der KI-Antwort aus, der Name löst jetzt auf, und die Lieferkette ist durch die Vordertür verletzt. Den Begriff prägte PSF-Security-Entwickler Seth Larson; die Mechanik ist das klügere Geschwister des Typosquattings – der Angreifer rät nicht mehr, was Menschen vertippen, das Modell sagt ihm, was es empfehlen wird.

Die USENIX-2025-Zahlen

Befund	Zahl	Warum er zählt
Empfohlene Pakete, die nicht existieren	19,7 %	Systematische Output-Eigenschaft, kein gelegentlicher Ausrutscher
Beobachtete einzigartige halluzinierte Namen	205.000+	Ein großer, aberntbarer Namensraum registrierbarer Ziele
Halluzinationen, die in allen 10 Wiederholungen auftauchen	43 %	Vorhersagbare Namen – einmal registrieren, die Opfer kommen von selbst
Mehr als einmal wiederholt	58 %	Die Mehrheit der Halluzinationen sind stabile Artefakte, kein Rauschen

Kernbefunde von „We Have a Package for You!“ (USENIX Security 2025, 16 code-generierende Modelle) – die Persistenz-Zeile verwandelt Halluzination von Rauschen in Angriffsfläche.

Die Studie fand außerdem: Kommerzielle Modelle halluzinieren weniger als Open-Source-Modelle – aber kein Modell ist sauber. Und der Angriff kombiniert sich mit älteren Klassen: Slopsquatting trifft Dependency Confusion, wo intern klingende halluzinierte Namen mit öffentlichen Registries kollidieren. Die BSI/ANSSI-Empfehlungen markierten Paket-Halluzination schon 2024 als Lieferketten-Vektor.

Die Verteidigung, deterministisch-zuerst

Unbekannte Namen nicht auflösen lassen. Interne Mirrors oder Registry-Allowlists bedeuten: Ein halluzinierter Name installiert schlicht nicht – der stärkste Einzel-Control, und Standard-Ausrüstung in isolierten Umgebungen aus genau diesem Grund.
Lockfiles und gepinnte Dependencies. Builds installieren, was gelockt ist, nicht was eine Antwort vorschlug – neue Namen brauchen eine bewusste Lockfile-Änderung, die im Review sichtbar ist.
Ein Gate für jede neue Dependency. Menschliche Freigabe mit Minimal-Check: Existiert es, seit wann, gepflegt von wem, gebraucht wofür. Minuten pro Vorkommnis – und Vorkommnisse sind selten, wenn Aufträge begrenzt sind.
Keine Installations-Rechte für Agenten per Default. Ein Agent, der nicht installieren kann, kann keine Malware installieren – die Rechte-Leiter, angewandt auf den Paketmanager.

Warum der Verifikations-Loop es strukturell fängt

Nimmt man die Security-Payload weg, ist eine halluzinierte Dependency vertraut: Sie ist Halluzination plus Scope Creep – die KI hat etwas hinzugefügt, das der Auftrag nicht verlangte. Ein schriftlicher Auftrag mit Grenzen macht jede neue Dependency zur sichtbaren Abweichung statt zur Zeile, die im Diff untergeht, und der Änderung-gegen-Auftrag-Check markiert sie, bevor etwas einen geteilten Branch erreicht. Die Security-Controls oben lassen den nicht freigegebenen Pfad dann physisch scheitern. Gürtel und Hosenträger – und der Gürtel ist derselbe Verifikations-Loop, den der Rest dieser Seite beschreibt.

Wo Reality Graph ansetzt

Reality Graph ist kein Registry-Scanner und analysiert keine Paket-Payloads. Sein Beitrag ist der strukturelle Fang: Mit pro Run deklarierten Grenzen taucht eine Dependency, die der Auftrag nicht verlangte, als Scope-Befund im Prüfbericht auf, vor dem menschlichen Gate – egal wie der Name lautet und wer ihn registriert hat. Die Registry-seitigen Controls bleiben eure Aufgabe; die zwei Schichten schließen den Pfad von beiden Enden.

Diese Analyse gibt euch

Die Mechanik und die USENIX-Zahlen, präzise belegt
Die Persistenz-Einsicht, die den Angriff aberntbar macht
Vier Verteidigungen, nach Determinismus geordnet
Den strukturellen Fang über die Scope-Verifikation

Sie gibt euch nicht

Einen Registry-Malware-Scanner – fahrt Dependency-Review-Tooling
Die Behauptung dokumentierter Massen-Ausnutzung – Attribution ist schwer
Schutz vor den anderen Typosquatting-Varianten – die Verteidigungen überlappen, fahrt sie
Einen Grund, KI-Vorschläge zu verbieten – das Gate skaliert, das Verbot nicht

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Was ist Slopsquatting und wie schützt man sich davor?: Slopsquatting ist das Registrieren von Paketnamen, die KI-Modelle halluzinieren – Entwickler, die eine KI-empfohlene Dependency ungeprüft installieren, erhalten den Code des Angreifers. Der Schutz schließt den Installations-Pfad: Lockfiles und interne Mirrors, damit unbekannte Namen nicht auflösen; ein Review-Gate für jede neue Dependency; und jede Dependency, die ein KI-Run hinzufügt, als Scope-Ereignis behandeln, das explizite Freigabe braucht. Den Begriff prägte PSF-Security-Entwickler Seth Larson.
Wie häufig sind halluzinierte Pakete, gemessen?: Die USENIX-Security-2025-Studie „We Have a Package for You!“ hat es über 16 code-generierende Modelle gemessen: 19,7 % der empfohlenen Pakete existierten nicht, mit über 205.000 einzigartigen erfundenen Namen. Kommerzielle Modelle halluzinierten weniger als Open-Source-Modelle, aber kein Modell war sauber. Die Größenordnung zählt: Das ist kein gelegentlicher Ausrutscher, sondern eine systematische Output-Eigenschaft – groß genug, um sie abzuernten.
Warum ist die 43-%-Persistenz-Zahl so wichtig?: Weil sie eine Kuriosität in eine Angriffsfläche verwandelt. Als die Forscher halluzinations-auslösende Prompts zehnmal wiederholten, tauchten 43 % der erfundenen Namen jedes einzelne Mal wieder auf (58 % mehr als einmal). Ein Name, den Modelle zuverlässig neu erfinden, ist ein Name, den ein Angreifer einmal registriert und dann wartet – die Opfer kommen von selbst, gelenkt von denselben statistischen Rillen im Modell. Zufallsrauschen wäre nicht ausnutzbar; wiederholbare Halluzination ist Infrastruktur für den Angreifer.
Wurde Slopsquatting schon in freier Wildbahn ausgenutzt?: Die Bausteine sind alle dokumentiert: Typosquatting- und Dependency-Confusion-Angriffe haben eine lange Vorfalls-Historie, bösartige Pakete erscheinen kontinuierlich auf Registries, und Forscher haben den Weg von der Halluzination zur Registrierung Ende-zu-Ende demonstriert. Konkrete Vorfälle spezifisch Slopsquatting zuzuschreiben ist schwerer – gerade weil eine erfolgreiche Installation wie jede Dependency-Ergänzung aussieht. Das ist ein Argument dafür, den Pfad zu schließen, nicht dafür, auf den Schlagzeilen-Fall zu warten.
Schützen die Paket-Registries dagegen?: Teilweise und zunehmend: Registries entfernen gemeldete Malware, manche scannen Uploads, und Ökosystem-Arbeit an Trusted Publishing und Provenance hebt die Latte. Nichts davon verhindert, dass ein Angreifer einen plausiblen, unbeanspruchten Namen mit funktionierend-aber-bösartigem Code registriert, bevor ihn jemand meldet. Registry-Hygiene ist echter Fortschritt und kein Ersatz für das Gate auf Konsumenten-Seite: Euer Build sollte keine Namen auflösen, die niemand freigegeben hat.
Wie hängt das mit allgemeiner KI-Code-Verifikation zusammen?: Eine halluzinierte Dependency ist Scope Creep mit Supply-Chain-Payload: Die KI hat etwas hinzugefügt, das der Auftrag nicht verlangte. Deshalb fängt der allgemeine Verifikations-Loop sie strukturell – ein schriftlicher Auftrag mit Grenzen macht jede neue Dependency zur sichtbaren Abweichung, und ein menschliches Gate gibt sie frei oder lehnt ab, bevor etwas installiert. Die security-spezifischen Verteidigungen (Mirrors, Lockfiles) lassen den nicht freigegebenen Pfad dann physisch scheitern.

Weiterlesen

SicherheitPrompt Injection gegen Coding-AgentenEin Agent liest ein vergiftetes README und führt die Anweisungen des Angreifers aus – OWASPs LLM-Risiko Nr. 1, mit 2026er-CVEs gegen Copilot, Claude Code und MCP-Server. Warum es strukturell sein könnte und warum Containment die Heilung schlägt.GuideDer erste PrüfberichtEin Teamleiter bekommt den ersten KI-Code-Prüfbericht an einem Nachmittag hin, ohne Plattform – der tool-agnostische Fahrplan, eine kopierbare Bericht-Vorlage und der Weg von einem Bericht zur Team-Praxis.Alle ArtikelDie ganze Sammlung – 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.