Was ist Slopsquatting? Der neue HalluSquatting-Angriff auf KI-Coding-Agenten

Was ist Slopsquatting?

Slopsquatting ist die Praxis, einen Software-Paketnamen zu registrieren, der nicht existiert, den ein großes Sprachmodell aber wahrscheinlich halluziniert, sodass ein Entwickler oder ein KI-Agent das Paket des Angreifers in dem Glauben installiert, es sei legitim. Der Begriff wurde im April 2025 von Seth Larson geprägt, Security Developer-in-Residence bei der Python Software Foundation, als Kofferwort aus "AI slop" und "typosquatting".

Zwei Ideen liegen darunter, und es hilft, sie auseinanderzuhalten. Paket-Halluzination (package hallucination) ist das Modellverhalten: Ein LLM, aufgefordert Code zu schreiben, verweist auf ein Installationsziel, das nie veröffentlicht wurde. Slopsquatting ist der Angriff, der dieses Verhalten in einen Auslieferungsmechanismus verwandelt, indem er den halluzinierten Namen zuerst beansprucht. Die Halluzination ist die Schwachstelle, Slopsquatting ist der Exploit.

“

Ein Mensch, der "pip install reqwest-py" liest, hält vielleicht inne und prüft. Ein Agent führt den Befehl aus. In dem Moment, in dem ein Paketname von einem Vorschlag, den eine Person tippt, zu einer Aktion wird, die ein Agent ausführt, verschwindet der letzte menschliche Kontrollpunkt.

Slopsquatting vs. Typosquatting: Worin liegt der Unterschied?

Beide sind Namensverwechslungs-Angriffe auf die Software-Lieferkette (supply chain), aber sie nutzen unterschiedliche Fehler aus und, entscheidend, sie umgehen unterschiedliche Abwehrmechanismen.

Der tragende Unterschied ist die dritte Zeile. Typosquatting-Abwehr geht davon aus, dass der bösartige Name wie ein echter aussieht, also markiert sie Pakete innerhalb einer kleinen Editierdistanz zu beliebten Bibliotheken. Ein halluzinierter Name ist die Fehlschreibung von gar nichts. Sockets Analyse halluzinierter Namen ergab, dass fast die Hälfte jedem echten Paket höchst unähnlich war, frei erfunden und doch im Kontext glaubhaft, was genau der Grund ist, warum Lookalike-Erkennung glatt an ihnen vorbeigleitet.

Wie funktioniert ein Slopsquatting-Angriff eigentlich?

Der Angriff hat vier Schritte, und das Unangenehme daran ist, dass der Angreifer nicht raten muss. Das Modell sagt ihm, was er registrieren soll.

Was Schritt zwei ausnutzbar macht, ist, dass Halluzinationen kein zufälliges Rauschen sind. In der bislang größten Studie führten Forscher denselben Prompt zehnmal erneut aus und stellten fest, dass 43 % der halluzinierten Paketnamen in allen zehn Durchläufen erneut auftauchten und 58 % mehr als einmal. Das Modell erfindet nicht jedes Mal einen anderen Fake-Namen, es tendiert zu denselben. Ein Angreifer kann diese Namen in großen Mengen abschöpfen, die hartnäckigen registrieren und warten. Weil Agenten in autonomen oder "Yolo"-Modi ohne Bestätigung installieren und ausführen, feuert der Post-Install-Hook der Payload in der Sekunde, in der das Paket landet, bevor ein Pull Request zum Prüfen überhaupt existiert.

Wie verbreitet sind halluzinierte Pakete?

Verbreitet genug, um ein Vertriebskanal statt eines Randfalls zu sein. Die maßgebliche Messung ist die USENIX-Security-2025-Studie "We Have a Package for You!" der University of Texas at San Antonio und Virginia Tech, die 2,23 Millionen Code-Beispiele analysierte, die von 16 Modellen über Python und JavaScript hinweg generiert wurden.

Die Rate ist nicht einheitlich. Open-Source-Modelle halluzinierten Pakete in 21,7 % der Beispiele gegenüber 5,2 % bei kommerziellen Modellen, ein grob vierfacher Abstand, und einige auf Code spezialisierte Modelle erfanden in mehr als einem Drittel ihrer Ausgaben ein Paket. Zwei Kräfte treiben das Risiko über die Zeit dann nach oben, nicht nach unten: Teams lassen Agenten zunehmend unbeaufsichtigt Abhängigkeiten schreiben und installieren, und dieselben Modelle schlagen weiterhin dieselben frei erfundenen Namen jedem vor, der fragt.

Ist Slopsquatting in der realen Welt vorgekommen?

Ja, und der Beweis liegt zeitlich vor dem Namen. Ende 2023 bemerkte der Sicherheitsforscher Bar Lanyado von Lasso Security, dass mehrere Modelle wiederholt ein Python-Paket namens huggingface-cli halluzinierten. Als harmlosen Machbarkeitsnachweis veröffentlichte er ein leeres Paket unter diesem Namen. Innerhalb von drei Monaten war es mehr als 30.000-mal heruntergeladen worden, und wie The Register berichtete, verwies ein großes Unternehmen (Alibaba) in der README eines seiner eigenen Forschungs-Repositories auf den Installationsbefehl. Das Paket war harmlos. Ein bösartiger Akteur, der dieselbe Halluzination beobachtet hätte, wäre es nicht gewesen.

Die Wendung von 2026 ist, dass KI-Agenten diese Namen nun für Sie verbreiten. Die Forschungsnotiz der Cloud Security Alliance zu Slopsquatting vom April 2026 dokumentiert, wie sich halluzinierte Installationsbefehle über kopierte "Agent-Skill"-Dateien ausbreiten. In einem Fall vom Januar 2026 wurde ein frei erfundenes npm-Paket (ein Name, den ein Modell durch das Vermengen zweier echter Tools hervorbrachte) bereits von 237 GitHub-Repositories referenziert, bevor es jemand meldete, größtenteils ausgesät durch einen einzigen Commit, der Dutzende LLM-generierter Skill-Dateien hinzufügte. Die Halluzination blieb nicht in einem Chatfenster, sie wurde committet, geteilt und von jedem Agenten, der den Skill las, erneut ausgeführt.

Was ist der HalluSquatting-Angriff (Juli 2026)?

Für den Großteil der kurzen Geschichte von Slopsquatting war der Angreifer opportunistisch: registriere, welche Namen das Modell zufällig bevorzugt, und warte dann. Ein am 8. Juli 2026 veröffentlichtes Paper, "Beware of Agentic Botnets" von Spira, Cohen, Feldman, Bitton, Wool und Nassi (Tel Aviv University, Technion und Intuit), beseitigt das Warten. Es demonstriert einen universellen, übertragbaren feindlichen Auslöser (adversarial trigger), der Agenten dazu bringt, auf Abruf eine bestimmte, vom Angreifer gewählte Ressource zu halluzinieren, statt darauf zu hoffen, dass sie bei einer landen, die der Angreifer bereits besitzt.

Der Mechanismus verkettet zwei Fehler, die die früheren Abschnitte beschreiben. Erstens lenkt der Auslöser den Agenten dazu, eine Ressource (ein Repo, einen Skill, ein Paket) unter einem Namen abzurufen, den der Angreifer kontrolliert. Zweitens führt sich indirekte Prompt Injection, die in dieser abgerufenen Ressource verborgen ist, aus, wenn das Terminal des Agenten sie ausführt, erreicht damit die Remote-Ausführung von Tools und installiert sich selbst verbreitende Botnet-Schadsoftware. Die Forscher rahmen das Ergebnis als ungezielten, skalierbaren Angriff ein: ein feindlicher Auslöser, keine Einrichtung pro Opfer, Schadsoftware, die sich von einem kompromittierten Agenten zum nächsten ausbreitet.

Warum kann ein Scanner es nicht abfangen?

Weil die zwei Kontrollen, auf die sich die meisten Teams verlassen, beide am falschen Ort suchen oder zu spät eintreffen.

Lesen Sie die rechte Spalte von oben nach unten, und ein einziges Thema tritt hervor. Jede dieser Kontrollen wirkt auf das Paket, nachdem es auf der Festplatte ist, oder sucht nach einer Ähnlichkeit, die ein frei erfundener Name nicht hat. Das Installationsskript einer bösartigen Abhängigkeit läuft zum Installationszeitpunkt, was für einen autonomen Agenten Sekunden nach dem Erfinden des Namens durch das Modell ist und lange bevor irgendein Scanner, Prüfer oder CVE-Feed sich einschaltet. Der einzige Ort, um es zu stoppen, ist, bevor der Installationsbefehl ausgeführt wird.

Wie man Slopsquatting verhindert

Nichts davon ist exotisch. Die Disziplin liegt darin, sie auf Agenten anzuwenden, die sich schneller bewegen als die Menschen, die sie beaufsichtigen.

1. Blinde Auto-Installation abschalten. Führen Sie Agenten nicht in vollständig autonomen "Installieren-und-Ausführen"-Modi gegen echte Zugangsdaten aus. Verlangen Sie ausdrückliche Genehmigung für jede neue Abhängigkeit, sodass ein frei erfundener Name einen menschlichen Blick passieren muss.

2. Prüfen Sie, dass ein Paket existiert und echt ist, bevor es hinzugefügt wird. "Es hat sich installiert" ist kein Beweis für Legitimität; der Angreifer hat dafür gesorgt, dass es sich installieren lässt. Prüfen Sie, dass das Paket eine echte Historie hat: Alter, Download-Verlauf, ein echtes Quell-Repository, namentlich genannte Maintainer. Ein letzte Woche registriertes Paket, das ein Modell als Standard beschwört, ist genau die Form dieses Angriffs.

3. Versionen anpinnen und Lockfiles mit Integritäts-Hashes committen. Ein Lockfile mit Hashes bedeutet, dass eine ausgetauschte oder neu vergiftete Version sich nicht still selbst ersetzen kann, und es macht eine neue Abhängigkeit als prüfbare Änderung sichtbar statt als unsichtbares transitives Nachziehen einer Abhängigkeit.

4. Beschränken Sie, woher Pakete kommen dürfen. Verwenden Sie einen internen Spiegel, eine private Registry oder eine Allowlist, damit der Agent nur aus geprüften Quellen installieren kann. Ist ein halluzinierter Name nicht im Spiegel, schlägt die Installation sicher fehl (fail closed), statt zur öffentlichen Registry auszugreifen.

5. Führen Sie Software Composition Analysis (SCA) aus, als Sicherheitsnetz. SCA lohnt sich bei jeder neuen Abhängigkeit, aber behandeln Sie es als das letzte Netz, nicht als das erste. Es fängt bekannt schlechte Pakete und Versionen ab; es fängt kein bösartiges Zero-Day-Paket an dem Tag ab, an dem es registriert wird.

6. Prüfen Sie neue Abhängigkeiten gezielt. Machen Sie "hat diese Änderung eine Abhängigkeit hinzugefügt?" zu einem ausdrücklichen Prüfschritt. Eine einzeilige Ergänzung in package.json oder requirements.txt verdient mehr Aufmerksamkeit als hundert Zeilen Geschäftslogik, weil sie den Code eines anderen mit Ihren Rechten importiert.

7. Isolieren Sie nicht vertrauenswürdige Agentenarbeit. Wenn ein Agent gegen ein unbekanntes Repository oder Drittanbieter-Inhalte läuft, geben Sie ihm einen Container ohne Host-Geheimnisse und ohne Pfad zur Produktion. Installationsskripte laufen sofort, also sollte ein gelenkter Agent nichts Wertvolles in Reichweite haben, wenn eines auslöst.

8. Behandeln Sie vom Agenten vorgeschlagene Pakete als nicht vertrauenswürdige Eingabe. Das Selbstbewusstsein des Vorschlags ist kein Beweis. Ein Name, den das Modell als offensichtlich präsentiert, ist genau der Name, von dem ein Angreifer bereits geprüft hat, dass das Modell ihn mag.

Wo Prävention leben muss: Durchsetzung zum Agentenzeitpunkt

Gehen Sie diese Liste noch einmal durch, und die wirksamen Kontrollen teilen eine Eigenschaft: Sie wirken, bevor der Installationsbefehl läuft. Der Scanner, der ein Diff liest, der SCA-Feed, die CVE-Datenbank, sie alle treffen ein, nachdem der Agent das Paket bereits abgerufen und ausgeführt hat. Im Agententakt ist das zu spät. Der Ort, an dem "installiere kein Paket, das du nicht verifizieren kannst" durchzusetzen ist, liegt innerhalb der Agentenschleife, in dem Moment, in dem der Agent nach dem Installationsbefehl greift.

Das ist die Ebene, die VibeDefend hinzufügt. Es ist eine kostenlose npm-CLI, die in etwa fünf Sekunden installiert ist und Ihre KI-Coding-Agenten (Claude Code, OpenAI Codex, Cursor, Windsurf und VS Code Copilot) in Governance verdrahtet, die läuft, während sie arbeiten, nicht danach.

Zwei der vier Ebenen bilden diesen Angriff direkt ab. Action Guard fängt die riskante Aktion ab, bevor sie auslöst: Die Installation eines Pakets, das nicht verifiziert, brandneu oder nicht auf Ihrer Allowlist ist, wird gewarnt oder blockiert, mit dem Abfangen im Audit-Trail, sodass die frei erfundene Abhängigkeit den Installationsschritt nie erreicht. Security Rules laden die Disziplin selbst in den Kontext des Agenten, bevor er schreibt, sodass "verifiziere, dass eine Abhängigkeit existiert und vertrauenswürdig ist, bevor du sie hinzufügst" eine Regel ist, die der Agent zum Zeitpunkt des Prompts liest, statt eines Checklistenpunkts, den niemand angewendet hat. Neben ihnen hält Live Findings jedes Ergebnis aus CybeDefends Scannern (SAST mit Erreichbarkeit, SCA, Secrets, IaC und CI/CD) live im Kontext des Agenten, sodass ein Abhängigkeitsproblem in der Schleife triagiert wird, statt Tage später aufzutauchen.

Und CybeDefends SCA aktualisiert seine Schwachstellendaten fortlaufend, ein frischer Abruf etwa alle fünfzehn Minuten, sodass ein Paket in dem Moment, in dem es als bösartig offengelegt wird, innerhalb von Minuten im Agenten auftaucht statt erst beim nächsten nächtlichen Scan, und jede Abhängigkeit, die der Agent hereinzieht, wird in der Schleife geprüft. Die beiden Ebenen schließen gegenseitig ihre Lücken: Action Guard stoppt die Installation eines brandneuen Pakets, das noch niemand markiert hat, und die fortlaufend aktualisierte SCA fängt jene ab, die sich erst später als bösartig herausstellen.

Entscheidend ist: Nichts über Ihren Code geht über die Leitung. Entscheidungen geschehen lokal neben dem Agenten; nur strukturierte Governance-Metadaten (die ausgelöste Regel, der Dateipfad, die Schwere, ein Zeitstempel) erreichen das Backend, und EU- und US-Mandanten sind physisch getrennt. Dies ist kein Ersatz für Lockfiles, Allowlists und menschliche Prüfung. Es ist die Ebene, die sie in dem Tempo durchsetzbar macht, in dem ein Agent tatsächlich arbeitet, sodass die Installation eines Pakets, das nie echt war, gestoppt wird, bevor sie geschieht, statt danach untersucht zu werden.

CybeDefend ist die AppSec-Ebene zum Agentenzeitpunkt, die genau dafür gebaut ist. Sie verdrahtet jeden KI-Coding-Agenten auf Ihrem Rechner mit Ihren Geschäftsregeln, Ihren Sicherheits-Frameworks (OWASP, SOC 2, GDPR, ISO 27001), einem Action Guard, der unsichere oder nicht verifizierte Installationen blockiert, bevor sie laufen, und einem fortlaufend aktualisierten Scanning jeder Abhängigkeit und jeder Zeile, die der Agent schreibt. Slopsquatting funktioniert nur in der Lücke zwischen einem Modell, das einen Namen erfindet, und einem Menschen, der es bemerkt. CybeDefend schließt diese Lücke, innerhalb der Schleife, bevor der Pull Request überhaupt geöffnet wird.

Häufig gestellte Fragen

Was ist Slopsquatting?

Slopsquatting ist ein Angriff auf die Software-Lieferkette (supply chain), der einen Paketnamen registriert, den ein KI-Modell wahrscheinlich halluziniert, sodass Entwickler und KI-Coding-Agenten das bösartige Paket des Angreifers in dem Glauben installieren, es sei eine echte Abhängigkeit. Der Begriff, im April 2025 von Seth Larson von der Python Software Foundation geprägt, verbindet "AI slop" und "typosquatting". Er funktioniert, weil große Sprachmodelle plausible Paketnamen erfinden, die nicht existieren, und sie erfinden konsistent dieselben, was Angreifern eine vorhersehbare Liste von Namen zum Beanspruchen gibt.

Worin unterscheiden sich Slopsquatting und Typosquatting?

Typosquatting nutzt menschliche Tippfehler aus, indem es Namen registriert, die echten Paketen stark ähneln, sodass es durch das Messen der Zeichenketten-Distanz zu beliebten Bibliotheken erkannt werden kann. Slopsquatting nutzt KI-Halluzination aus, indem es völlig frei erfundene Namen registriert, die ein Modell erfindet, die keine Fehlschreibungen irgendeines echten Pakets sind und deshalb der Lookalike-Erkennung entgehen. Kurz gesagt: Typosquatting setzt darauf, dass Ihre Finger abrutschen; Slopsquatting setzt darauf, dass Ihr KI-Assistent eine Abhängigkeit erfindet und sie für Sie installiert.

Was ist der HalluSquatting-Angriff?

HalluSquatting ist eine Eskalation von Slopsquatting aus dem Jahr 2026, beschrieben im Paper "Beware of Agentic Botnets" (arXiv, 8. Juli 2026). Statt darauf zu warten, dass ein Modell zufällig auf einen Namen stößt, den der Angreifer bereits besitzt, nutzt es einen universellen, übertragbaren feindlichen Auslöser (adversarial trigger), um KI-Agenten dazu zu bringen, auf Abruf eine bestimmte, vom Angreifer gewählte Ressource zu halluzinieren, und verkettet ihn dann mit indirekter Prompt Injection, um Remote-Code-Ausführung zu erreichen und Botnet-Schadsoftware zu verbreiten. Die Forscher berichteten Halluzinationsraten bei Ressourcen von bis zu 85 % beim Klonen von Repositories und 100 % bei der Skill-Installation über neun Assistenten hinweg, darunter Cursor, Windsurf, Copilot, Cline und Gemini CLI.

Wie verbreitet sind KI-Paket-Halluzinationen?

Sehr verbreitet. Eine USENIX-Security-2025-Studie von 2,23 Millionen KI-generierten Code-Beispielen ergab, dass 19,7 % mindestens ein halluziniertes Paket referenzierten, katalogisierte 205.474 einzigartige frei erfundene Namen und zeigte, dass die Halluzinationen wiederholbar sind: 43 % von ihnen traten in allen zehn erneuten Durchläufen desselben Prompts erneut auf. Open-Source-Modelle waren schlechter (21,7 %) als kommerzielle (5,2 %). Die Wiederholbarkeit macht das Problem ausnutzbar, weil Angreifer die Namen, die ein Modell bevorzugt, vorhersagen und vorab registrieren können.

Kann ein SCA-Scanner oder Typosquatting-Erkennung Slopsquatting abfangen?

Nicht zuverlässig, und aus zwei verschiedenen Gründen. Typosquatting-Erkennung sucht nach Namen innerhalb einer kleinen Editierdistanz zu echten Paketen, aber ein halluzinierter Name ist frei erfunden statt einer Beinahe-Übereinstimmung, also ist er nichts nahe, was der Filter beobachtet. Software Composition Analysis läuft, nachdem ein Paket installiert ist, und sucht nach bekannt verwundbaren Versionen, aber ein frisch registriertes bösartiges Paket hat noch keine CVE, und sein Installationsskript hat sich bereits ausgeführt, wenn SCA nachschaut. Beide lohnen sich als Sicherheitsnetze; keines stoppt die Installation selbst.

Wie hindere ich meinen KI-Coding-Agenten daran, halluzinierte Pakete zu installieren?

Lassen Sie Agenten keine Abhängigkeiten unbeaufsichtigt installieren, verifizieren Sie, dass jedes neue Paket tatsächlich existiert und eine echte Historie hat, bevor es hinzugefügt wird, beschränken Sie Installationen auf eine private Registry oder Allowlist, und committen Sie Lockfiles mit Integritäts-Hashes, damit neue Abhängigkeiten sichtbar und prüfbar sind. Weil diese Prüfungen nur helfen, wenn etwas sie durchsetzt, bevor der Installationsbefehl läuft, ist die dauerhafte Lösung die Durchsetzung zum Agentenzeitpunkt: eine Kontrolle wie VibeDefend, die die Installation eines nicht verifizierten oder nicht existierenden Pakets innerhalb der Agentenschleife abfängt, statt eines Scanners, der den Schaden im Nachhinein liest.