Ein typisches Entwicklerproblem wirkt zunächst harmlos: Ein Team testet einen neuen KI-Coding-Agenten, lässt ihn ein populäres Repository klonen oder eine passende „Skill“-Erweiterung installieren — und erlaubt ihm, die nötigen Shell-Befehle direkt auszuführen. Genau diese Komfortfunktion steht im Zentrum eines neuen Angriffsmodells. Die am 8. Juli veröffentlichte Forschung zu „HalluSquatting“ zeigt: KI-Agenten schreiben nicht nur Code. Sie können auch Ressourcennamen erfinden. Angreifer können diese vorhersehbaren Fantasienamen registrieren und für Angriffe nutzen.
Wichtiger als der griffige Name ist der praktische Befund. In vielen Unternehmen laufen Coding-Agenten inzwischen auf Entwicklerrechnern, in CI/CD-Umgebungen oder in Sandboxen. Sie haben Zugriff auf Git-Repositories, Paketmanager, Terminals, lokale Dateien und mitunter auch auf Cloud- oder API-Zugangsdaten. Wenn ein Agent eine externe Ressource falsch auflöst und anschließend Anweisungen aus dieser Quelle befolgt, wird aus einer Halluzination eine Supply-Chain-Schwachstelle.
Was bei HalluSquatting technisch passiert
HalluSquatting steht für „adversarial hallucination squatting“. Der Angriff verbindet zwei bekannte Schwachstellen: Große Sprachmodelle halluzinieren plausible, aber nicht existierende Ressourcenbezeichner — etwa GitHub-Pfade oder Skill-Namen. Gleichzeitig können externe Inhalte indirekte Prompt-Injection-Anweisungen enthalten, die ein Agent liest und danach als Arbeitsauftrag interpretiert.
Der Ablauf ist einfach genug, um für Unternehmen relevant zu sein. Ein Angreifer beobachtet, welche Bibliotheken, Tools oder Agenten-Skills gerade an Bedeutung gewinnen. Dann testet er, welche falschen Repository- oder Skill-Namen verschiedene Modelle besonders häufig erzeugen. Ist ein solcher Name noch frei, registriert er ihn und platziert dort scheinbar hilfreiche Inhalte. Bittet ein Nutzer seinen Agenten später, das echte Tool zu klonen oder eine Fähigkeit zu installieren, kann der Agent beim erfundenen, inzwischen registrierten Ziel landen. Enthält diese Ressource Anweisungen zum Ausführen von Shell-Befehlen, kann der Agent den nächsten Schritt selbst erledigen.
Die Forschergruppe um Aya Spira, Ben Nassi und weitere Autoren der Tel Aviv University, des Technion und von Intuit beschreibt das als skalierbare, nicht zielgerichtete Promptware-Attacke. Laut Forschungspapier traten Halluzinationen in Repository-Clone-Szenarien in Spitzenfällen bis zu 85 Prozent auf. Bei Skill-Installationen berichten die Autoren von bis zu 100 Prozent für bestimmte Kombinationen. Getestet wurden unter anderem Cursor, Cursor CLI, Windsurf, GitHub Copilot, Cline, Gemini CLI sowie OpenClaw-, ZeroClaw- und NanoClaw-Varianten. Die veröffentlichten Payloads waren nach Angaben der Autoren harmlos. Es ging um Remote Tool Execution beziehungsweise Remote Code Execution als Machbarkeitsnachweis, nicht um eine reale Malware-Kampagne.
Warum das mehr ist als klassisches Typosquatting
Auf den ersten Blick erinnert HalluSquatting an Typosquatting bei npm, PyPI oder Domains: Angreifer registrieren Namen, die Opfer versehentlich nutzen. Der Unterschied liegt beim Auslöser des Fehlers. Beim Typosquatting vertippt sich der Mensch. Beim HalluSquatting schlägt der Agent selbst einen plausiblen, aber falschen Ort vor. Das senkt die Hürde für Angreifer. Sie müssen nicht erraten, welche Tippfehler Entwickler machen, sondern können systematisch testen, welche Falschnamen Modelle produzieren.
Die Forschung zeigt zudem, dass solche Fehler nicht völlig zufällig entstehen. Ein beschriebenes Muster ist die selbstreferenzielle Auflösung: Das Modell verwendet einen Repository-Namen zugleich als Account- und Repository-Namen. Bei neueren Projekten lag die Fehlerrate im Paper deutlich höher als bei älteren, etablierten Repositories. Für Enterprise-Teams ist das relevant, weil gerade neue KI-Tools, Agenten-Frameworks und Entwickler-Skills oft schnell ausprobiert werden, bevor sie in formale Softwarekataloge aufgenommen werden.
The Hacker News und Ars Technica griffen die Untersuchung am 8. Juli auf und ordnen sie ähnlich ein: Die Gefahr entsteht nicht durch einen einzelnen CVE, sondern durch die Kombination aus unzuverlässiger Namensauflösung, offen registrierbaren Ressourcen und Agenten mit Terminal- oder Installationsrechten. Ars Technica betont, dass dieser Mechanismus Pull-basierte Prompt-Injection skalierbarer machen kann, weil viele Agenten aus eigenem Antrieb dieselbe manipulierte Ressource abrufen könnten.
Branchenkontext: Agenten werden zur Ausführungsumgebung
Die Meldung passt in eine Reihe jüngerer Vorfälle und Forschungen zu KI-Agenten. Das Risiko liegt dabei nicht allein im Modell, sondern in der Umgebung darum herum: GitHub-Issues als Eingabe für agentische Workflows, MCP-Server mit zu weitreichenden Rechten, Agenten-Skills aus unsicheren Marktplätzen, infizierte Entwicklerpakete oder IDE-Erweiterungen. HalluSquatting ergänzt diese Liste um einen konkreten Kontrollpunkt: Löst und verifiziert ein Agent externe Namen, bevor er sie nutzt?
Für Entscheider markiert das eine wichtige Verschiebung. KI-Coding-Agenten sind nicht mehr nur Produktivitätstools. Sie werden zunehmend zu kleinen Automationsplattformen. Sie lesen Dokumentation, ändern Code, rufen Paketmanager auf, starten Tests und verwenden Shells. Damit überschreiten sie die Grenze zwischen Beratung und Ausführung. Ein falscher Ressourcenname ist in einem Chatbot ärgerlich. In einem Agenten mit Terminalzugriff kann er zum Initial Access werden.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen Agenten nicht unbeaufsichtigt installieren, klonen oder ausführen lassen, was diese gerade selbst im Netz gefunden haben. Besonders riskant sind „YOLO“-, „auto-run“- oder „skip permissions“-Modi auf Entwicklerrechnern mit produktiven Zugangsdaten. Solche Komfortmodi gehören mindestens in kurzlebige Sandboxen ohne Zugriff auf SSH-Schlüssel, Cloud-Tokens, Paketregistry-Credentials und interne Repositories.
Zweitens braucht Resource Resolution eine Sicherheitskontrolle. Ein Agent sollte vor git clone, npm install, Skill-Installation oder MCP-Konfiguration prüfen, ob die Ressource existiert, wem sie gehört, wie alt sie ist, ob sie zum erwarteten Hersteller passt und ob sie aus einem freigegebenen Katalog stammt. Für häufig genutzte Tools sollten Unternehmen interne Allowlisten oder Mirrors pflegen, statt Agenten beliebige öffentliche Namen interpretieren zu lassen.
Drittens müssen externe Inhalte, die ein Agent liest, als untrusted Input gelten. README-Dateien, Skill-Beschreibungen, Issues, Webseiten und Paket-Metadaten dürfen nicht dieselbe Autorität haben wie System- oder Entwickleranweisungen. Praktisch heißt das: klare Trennung von Daten und Instruktionen, Bestätigungen vor irreversiblen Aktionen, Logging der Agentenentscheidungen und Sperren für Befehle, die aus frisch abgerufenen externen Inhalten stammen.
Viertens sollten Security-Teams ihre Detection-Regeln anpassen. Verdächtig sind nicht nur klassische Malware-Indikatoren, sondern auch ungewöhnliche Agentenpfade: Ein Coding-Agent klont ein kaum bekanntes Repository, startet danach Shell-Skripte, öffnet Reverse-Connection-ähnliche Prozesse oder greift auf Secrets zu. EDR- und CI-Logs sollten den Agentennamen, das angefragte Ressourcenlabel und die tatsächlich abgerufene URL zusammenführen.
Risiken und Grenzen der aktuellen Erkenntnisse
Die Forschung ist ein Labor- und Proof-of-Concept-Szenario. Sie belegt nicht, dass bereits massenhaft Botnets über HalluSquatting aufgebaut wurden. Auch hängen die praktischen Folgen stark von Konfiguration und Berechtigungen ab. Ein Agent, der vor jedem Shell-Befehl sauber nachfragt und in einer isolierten Umgebung läuft, hat ein deutlich geringeres Schadpotenzial als ein Agent mit automatischer Ausführung und Zugriff auf reale Entwicklergeheimnisse.
Trotzdem wäre es falsch, das Thema als reine Theorie abzutun. Die Einzelteile sind bereits real: Paket-Squatting, Prompt Injection, Agenten mit Terminalzugriff und unsichere Skill-Distribution. Neu ist die systematische Verbindung über vorhersehbare Modellhalluzinationen. Entsprechend gibt es keinen einzelnen Patch, der das Problem erledigt. Anbieter müssen Namensauflösung, Planner-Logik und Marktplatzprüfungen verbessern. Unternehmen müssen Ausführungsrechte begrenzen und ihre Lieferkettenkontrollen schärfen.
Fazit
HalluSquatting ist ein nützlicher Weckruf, weil es ein unbequemes Muster sichtbar macht: KI-Agenten können nicht nur falsche Antworten geben, sondern falsche externe Ressourcen operationalisieren. Wer Agenten in Entwicklung, DevSecOps oder Plattformteams einsetzt, sollte deshalb nicht nur Prompts absichern, sondern den gesamten Ausführungspfad: Namensauflösung, Herkunftsprüfung, Rechte, Sandbox, Secrets und Logs. Der zentrale Grundsatz bleibt nüchtern: Alles, was ein Agent aus dem Internet holt, ist Eingabe von außen — und darf nicht automatisch zur ausführbaren Anweisung werden.
Quellen: Forschungspapier „Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting“ (Tel Aviv University/Technion/Intuit), The Hacker News vom 8. Juli 2026, Ars Technica vom 8. Juli 2026.
