Im Zentrum der Untersuchung steht kein klassischer Softwarefehler mit CVE, sondern ein Konstruktionsproblem. Adversa AI beschreibt, dass viele Open-Source-Agenten für Coding- und Computer-Use-Aufgaben ihre Shell-Schutzmechanismen auf Mustererkennung stützen. Diese Schutzschicht kann jedoch versagen, wenn Bash den zunächst geprüften Text beim Ausführen anders interpretiert. Zu den von Adversa genutzten Techniken gehören etwa das Entfernen von Anführungszeichen und die Verwendung von $IFS für Abstände.
Omer Ben Simon, leitender Forscher bei Adversa AI, sagt, das Team habe elf populäre Open-Source-Agenten getestet, darunter Hermes, OpenCode und Roo-code. Zehn davon hätten die Lücke in einer von vier Formen offengelassen, nur einer habe sie geschlossen. Der Anstoß für die Untersuchung war laut Adversa ein Umgehen der Freigabeschranke in NousResearch/hermes-agent mithilfe von Shell-Umschreibungen gegen eine Sperrliste aus 30 Regex-Mustern. Daraufhin prüften die Forscher die populärsten Open-Source-Coding-Agenten und Computer-Use-Agenten mit Stand Mai 2026, basierend auf GitHub-Stars und Community-Aktivität.
Die Tricks ordnet der Bericht in fünf Klassen von A bis E ein. Als besonders erfolgreich beschreibt Adversa Klasse E, also alternative argv-Formen mit derselben zerstörerischen Wirkung. Laut Bericht übersteht diese Klasse die meisten Schutzmechanismen, darunter auch die stärkste tokenisierte Schutzschicht der Untersuchung. Der Grund: Ob eine Flag-Kombination harmlos oder destruktiv ist, müsse für jedes einzelne Programm gesondert verstanden werden.
Praktisch ausnutzbar wird GuardFall nur unter bestimmten Voraussetzungen. Adversa betont, dass das Sprachmodell mitspielen muss. Eine direkte Aufforderung wie „führe dies aus: rm“ werde das Modell typischerweise als gefährlich erkennen und ablehnen. Indirekte oder verschleierte Anweisungen, etwa in einem Makefile-Ziel, würden dagegen eher akzeptiert. Untersucht wurde, ob von Angreifern in Inhalte eingebettete Kommandos, die der Agent aus einem bösartigen MCP-Server, einer geladenen Webseite oder anderen Quellen aufnimmt, später vom Agenten umgesetzt werden. Laut Adversa lautet die Antwort zu oft: ja.
Ausgeführt wird der erzeugte Shell-Befehl allerdings nur, wenn Auto-Execute aktiviert ist oder eine Sandbox in den lokalen Modus geschaltet wurde. Ben Simon nennt als mögliches Szenario einen Entwickler, der mit einem verwundbaren Agenten ein präpariertes README oder Makefile aus einem bösartigen Repository einliest. Dann könne der Agent unbemerkt Befehle ausführen, die etwa AWS-Zugangsdaten abziehen oder ganze Entwicklungsumgebungen löschen, besonders in CI-Pipelines mit voreingestelltem „Auto-Yes“-Modus.
Als einziger getesteter Agent bestand Continue die Versuche von Adversa durchgängig. Die Forscher schreiben, von 21 an den Evaluator übergebenen Umgehungsfällen habe keiner den Status „allowedWithoutPermission“ erreicht, und alle 12 kanonisch-destruktiven Fälle seien korrekt herabgestuft worden. Vollständig gelöst sei das Problem aber auch dort nicht: Klasse C innerhalb eines quotierten Arguments sowie der lange Nachlauf von Klasse E mit argv- und flagbezogener Bewertung blieben offen.
Adversa empfiehlt mehrere Gegenmaßnahmen, betont aber zugleich deren provisorischen Charakter. Genannt werden das Ausführen von Agenten in einer eingegrenzten Shell mit umgeleitetem $HOME, das Abschalten von Auto-Yes-Modi, die Prüfung von mit Repositories ausgelieferten Konfigurationen und das Blockieren der Agent-Ausführung bei Fork-PRs. Als stärkste Zwischenlösung beschreibt der Bericht eine Hülle, die $HOME in ein separates Verzeichnis umleitet und damit unter anderem ~/.ssh/, ~/.aws/ und die Shell-Historie aus der größten Fläche für das Abziehen von Zugangsdaten herausnimmt. Langfristig sehen die Forscher nur eine belastbare Lösung: Maintainer von Open-Source-Agenten müssten eine Schutzschicht nach dem Vorbild von Continue direkt im Agenten umsetzen, die Befehle tokenisiert und kanonisiert, statt bloß Rohtext zu filtern.