Halluzinationen, die infizieren: Slopsquatting und neue Lieferkettenangriffe im Zeitalter der KI-Agenten

Einleitung

Die Integration von Coding-Agenten auf Basis großer Sprachmodelle (LLMs) hat einen Kipppunkt erreicht: Werkzeuge wie GitHub Copilot, Cursor oder Gemini CLI schreiben, installieren Abhängigkeiten und führen sogar Befehle autonom aus. Gerade diese Autonomie birgt eine systemische Schwachstelle, die drei kürzlich durchgeführte Kampagnen – genannt Slopsquatting, Phantom Squatting und HalluSquatting – aufgedeckt haben. Der Mechanismus ist so einfach wie verheerend: Die Modelle „halluzinieren“ Bezeichner (Paketnamen, Domains, Repositorys), und wenn ein Angreifer diese zuvor registriert hat, führt der Agent ohne jegliche menschliche Interaktion Schadcode aus. Kein Phishing, kein Diebstahl von Anmeldedaten – es genügt die statistische Vorhersagbarkeit der Halluzinationen.

Technische Analyse

Ein Forscherteam unter Leitung von Ben Nassi (Tel Aviv University, Technion, Intuit) hat das Problem quantitativ nachgewiesen: Von LLMs generierte Repository-Anfragen lassen sich in bis zu 85 % der Fälle vorhersagen, bei der Installation von Skills sogar zu 100 %. Das bedeutet, ein Angreifer kann die nicht existierenden Namen, die ein Copilot oder Cline zu verwenden versuchen wird, vorab erraten, sie registrieren und mit schädlichen Payloads befüllen. Die drei Angriffe basieren auf demselben Prinzip, wenden es jedoch auf unterschiedliche Angriffsflächen an:

• Slopsquatting (Januar 2026): Der Agent schlägt ein nicht existierendes Paket zur Lösung einer Aufgabe vor; der Name ist so „typisch“, dass der Angreifer es bereits mit Malware auf einer öffentlichen Registry (z. B. PyPI, npm) bereitgestellt hat.
• Phantom Squatting (Juni 2026): Die Vorhersage betrifft halluzinierte Domains oder API-Endpunkte; der Agent kontaktiert sie, lädt Skripte herunter und führt sie in der Überzeugung aus, sie seien legitim.
• HalluSquatting (Juli 2026): Kompromittiert die Installation von „Skills“ oder Erweiterungen, die die KI für nützlich hält, um die Aufgabe zu erledigen; auch hier sind die Namen vorherberechenbar und bereit, Schadcode aufzunehmen.

In allen Fällen verwandelt das implizite Vertrauen in das Modell eine Halluzination in einen deterministischen Angriffsvektor. Und da die Agenten oft mit erhöhten Rechten und innerhalb von CI/CD-Pipelines agieren, breitet sich der Schaden weit aus. Die Forschung hat ergeben, dass traditionelle Sicherheitstools – Antivirus, Abhängigkeitsscanner, digitale Signaturen – die Bedrohung nicht erkennen: Es gibt keine einzelne infizierte Datei zu entdecken, sondern einen Workflow, der dynamisch Code aus nicht verifizierten Quellen einbindet, möglicherweise sogar über transitive Abhängigkeiten scheinbar harmloser Pakete.

Auswirkungen

Die Schwere ist hoch, und die Forscher warnen, dass das Beobachtete das minimale Risikoniveau darstellt. Die Vorhersagbarkeit der Halluzinationen ermöglicht den Aufbau vollständig automatisierter Infektionsketten: zukünftige Namen registrieren, darauf warten, dass ein Agent sie aufgreift, und Remotecodeausführung erlangen, ohne ein menschliches Opfer überzeugen zu müssen. Zu den unmittelbaren Folgen gehören:

• Kompromittierung von Entwicklungsumgebungen, lokalen Maschinen und CI/CD-Servern, mit Zugriff auf Secrets, Quellcode und Produktionsinfrastrukturen.
• Schaffung stiller Botnetze, in denen Tausende von KI-Agenten als Knoten dienen, ohne die klassischen Verbreitungswege.
• Kaskadierende Kontamination in Software-Lieferketten: Eine durch eine Halluzination eingeschleuste bösartige Komponente kann von allen Projekten übernommen werden, die von diesem Build abhängen, und statische Kontrollrichtlinien aushebeln.
• Schwierigkeiten bei Erkennung und Attribution, da sich das bösartige Ereignis mit dem normalen Verhalten des Agenten vermischt und keine Spuren traditioneller Exploits hinterlässt.

Gegenmaßnahmen

Die Verteidigung erfordert einen Paradigmenwechsel: Man kann blind weder automatischen Vorschlägen vertrauen noch sich darauf beschränken, bereits installierte Pakete zu scannen. Die von Forschern und Unternehmen wie ActiveState vorgeschlagenen Gegenmaßnahmen umfassen:

1. Präventive Überprüfung der Bezeichner – Vor der Installation, dem Klonen oder der Ausführung einer von einem LLM vorgeschlagenen Ressource muss deren tatsächliche Existenz und Urheberschaft geprüft werden. Abfragen offizieller Registries, Überprüfungen des Domain-Eigentums und der Repository-Reputation müssen zu Standardabläufen werden.
2. „At-Source“-Governance der Lieferkette – Kontrollen integrieren, die alles validieren, was vor den Sicherheitsscans in den Build gelangt, und den Schwerpunkt von der nachträglichen Erkennung auf die Prävention verlagern.
3. Einschränkung der Privilegien von KI-Agenten – Agenten in Sandboxen mit minimalen Berechtigungen ausführen, direkten Zugriff auf kritische Systeme verbieten und für jede Aktion, die das Herunterladen und Ausführen von Code umfasst, eine obligatorische menschliche Autorisierung einführen.
4. Inspektion des gesamten Abhängigkeitsbaums – Oft gelangt Schadcode über nicht überwachte transitive Abhängigkeiten ins System. Jeder Ast des Baums muss analysiert werden, nicht nur die erste Ebene, und verdächtige Änderungen müssen langfristig überwacht werden.
5. Frühzeitiges Binding – Die verzögerte Auflösung von KI-generierten Bezeichnern so weit wie möglich reduzieren. Wo möglich, explizit autorisierte und vor der Ausführung verifizierte Namen verwenden und alle unerwarteten dynamischen Lookup-Versuche blockieren.
6. Prädiktive Überwachung – Listen von Namen erstellen, die die eigenen Modelle in bestimmten Kontexten tendenziell halluzinieren. Diese Namen können in einer internen Dummy-Registry vorregistriert werden, um Ausführungsversuche abzufangen, oder auf Blacklists gesetzt werden, um externe Anfragen zu verhindern.

FAQ

1. Was genau ist Slopsquatting und wie unterscheidet es sich vom traditionellen Typosquatting?
Beim Slopsquatting werden die Halluzinationen von Sprachmodellen ausgenutzt, nicht Tippfehler. Beim Typosquatting registriert der Angreifer einen ähnlichen Namen wie einen legitimen (z. B. „googel.com“) in der Hoffnung auf einen menschlichen Fehler; beim Slopsquatting ist der Name völlig vom Modell erfunden, aber statistisch wahrscheinlich, und der Angreifer registriert ihn, bevor der Agent danach sucht, und erlangt so Codeausführung ohne jeden menschlichen Fehler.

2. Auf welche ersten Anzeichen sollte eine Organisation achten, um einen solchen Angriff zu bemerken?
Auf Anfragen von KI-Tools an Domains oder Paketregistries nach nicht existierenden Namen sollte geachtet werden; eine Häufung von Versuchen auf halluzinierte Ressourcen kann darauf hindeuten, dass ein Agent nicht autorisierten Code ausführt. Auch ungewöhnliche Änderungen an transitiven Abhängigkeiten oder die Ausführung von Skripten aus unbekannten Quellen sind Warnsignale.

3. Reicht es, die automatische Ausführung zu deaktivieren, um sicher zu sein?
Nein, denn Slopsquatting und seine Abarten beruhen auf der Fähigkeit der KI, den Benutzer (oder ein automatisiertes System) davon zu überzeugen, die bösartige Ressource einzubinden. Selbst mit menschlicher Kontrolle kann ein „halluziniertes“ Paket freiwillig installiert werden, wenn der vorgeschlagene Name nicht manuell gegen offizielle Registries geprüft wird. Die wirksamste Gegenmaßnahme ist die präventive Überprüfung jedes Bezeichners, unabhängig davon, wer den Ausführungsknopf drückt.