GuardFall: oeroude shell-trucs omzeilen de beveiliging van 10 van 11 open-source AI-codeeragents

Een beveiligingsfilter dat een AI-codeeragent tegen destructieve shell-commando's moet beschermen, blijkt in de praktijk vaak niet te beschermen tegen trucs die al dertig jaar oud zijn. Het onderzoeksbureau Adversa AI testte elf populaire open-source AI-codeeragents en computer-use-agents, en tien ervan lieten zich met simpele Bash-herschrijvingen om de tuin leiden. Alleen Continue hield stand. Adversa noemt het patroon GuardFall, en het raakt precies het gereedschap waarmee steeds meer ontwikkelteams productiecode laten schrijven.

Het gaat niet om een losse bug in een enkel product, maar om een structureel ontwerpprobleem dat door bijna de hele categorie loopt. De onderzoekers kozen de elf bekendste open-source agents op basis van hun GitHub-sterren (samen goed voor zo'n 548.000 sterren) en zetten ze op macOS onder Claude Sonnet 4.6. De tien die door de mand vielen: Hermes van NousResearch, opencode, Goose van Block, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands en SWE-agent.

Hoe het filter en de shell langs elkaar heen kijken

Een AI-codeeragent voert shell-commando's uit met de volledige rechten van de ontwikkelaar die hem aanstuurt. Om ongelukken te voorkomen zetten de meeste tools er een filter voor: een lijst met patronen die gevaarlijke commando's zoals rm -rf moet tegenhouden. Het probleem is dat dat filter naar de ruwe tekst kijkt, terwijl Bash diezelfde tekst daarna nog uitpakt, van aanhalingstekens ontdoet en herschrijft voordat hij hem uitvoert. Adversa vat het bondig samen: het filter en de shell kijken naar twee verschillende dingen, en Bash pelt de vermomming pas af nadat het filter het commando al heeft doorgelaten.

De voorbeelden zijn ontnuchterend simpel. r''m leest voor een patroonfilter als losse tekens, maar wordt door Bash gewoon rm. In rm$IFS-rf$IFS/ vouwt Bash de variabele $IFS pas na de inspectie uit tot een spatie, zodat een filter dat op spaties let niets ziet. $(echo rm) -rf / verstopt de commandonaam volledig, en een keten als echo <payload> | base64 -d | sh oogt per schakel onschuldig. De gevaarlijkste categorie zijn destructieve vlaggen op commando's die wel zijn toegestaan: find /x -delete, dd of=/dev/sda of tar -C / -x doen hun schade zonder dat het woord rm ooit valt. Adversa ordent de trucs in vijf klassen, A tot en met E, en het is klasse E, dezelfde commandovorm met een andere vlag, die de meeste filters overleeft.

Van een vergiftigde README tot een gewiste omgeving

De trucs werken alleen onder twee voorwaarden, en juist die maken er een supply-chain-risico van. Ten eerste moet het taalmodel meewerken. Vraag je een model rechtstreeks om rm uit te voeren, dan weigert het doorgaans. Maar verpakt in operationele context, een target in een Makefile, een instructie in een README, een reactie van een MCP-server of een pakketbeschrijving op npm of PyPI, komt hetzelfde commando er als routineklus doorheen. Ten tweede moet automatisch uitvoeren aanstaan, of moet een sandbox naar lokale modus zijn omgezet.

Daarmee wordt een schadelijke repository de aanvalsvector. Als een engineer een vergiftigde README of Makefile laat lezen door een kwetsbare agent, dan kan die stilletjes worden verleid tot commando's die AWS-inloggegevens wegsluizen of complete ontwikkelomgevingen wissen, zeker in CI-pijplijnen waar auto-ja standaard aanstaat, waarschuwt Adversa-onderzoeker Omer Ben Simon. Wat er binnen handbereik ligt is precies wat pijn doet: de sleutels in ~/.ssh, de cloud-credentials in ~/.aws, git-ondertekensleutels en browser-sessietokens, en in een CI-omgeving ook deploy-sleutels, registry-inloggegevens en toegang tot je eigen build-runners.

Het patroon is inmiddels herkenbaar. Eerder liet onderzoek al zien hoe een schone GitHub-repo een AI-coderingsagent via een verstopte foutmelding ongemerkt malware laat installeren, en hoe vergiftigde MCP-toolomschrijvingen een AI-agent kapen en bedrijfsdata laten lekken. Telkens is niet het model gehackt, maar de autonomie eromheen misbruikt.

Waarom Continue wel standhield

Het verschil zit in de aanpak. Waar de gevallen tools op ruwe tekst matchen, ontleedt Continue een commando eerst zoals Bash dat zou doen en canoniseert het voordat het langs de regels gaat: tokenizen met echte shell-parsing, variabele-uitvouwing detecteren, geneste commandosubstituties uitrekenen, pijpen naar sh of python blokkeren en pas daarna toetsen aan een harde lijst van destructieve patronen. Van de 21 omzeilingen die Adversa erop losliet, kwam er geen enkele ongevraagd door, en alle twaalf canoniek-destructieve gevallen werden correct tegengehouden. De tools die faalden, faalden juist massaal: opencode liet 16 van de 16 testgevallen door, Goose 22 van de 23. Meer patronen aan de zwarte lijst toevoegen, benadrukken de onderzoekers, lost daar niets aan op, want het onderliggende ontwerp blijft hetzelfde.

Geen CVE, geen patch: wat je nu zelf regelt

Adversa geeft GuardFall bewust geen CVE-nummer. Het is geen bug maar een gevaarlijke conventie en een hele klasse problemen tegelijk, en voor de tien getroffen tools is er geen patch. Daarmee ligt de verantwoordelijkheid bij de teams die deze agents nu inzetten. De meest effectieve maatregel is de agent draaien vanuit een afgeschermde shell met $HOME omgeleid, bijvoorbeeld met een wrapper die naar een wegwerpmap wijst: dat haalt je ~/.ssh, ~/.aws en shell-historie in een klap uit bereik, en er is geen vlag die het per ongeluk weer uitzet. Daarnaast: automatisch-ja-modi uitzetten, repo-configuraties zoals een Makefile of .aider.conf.yml behandelen als niet-vertrouwde code, agent-uitvoering op fork-pull-requests in CI blokkeren, en een sandbox in de veilige containermodus laten staan in plaats van hem naar lokaal om te zetten. Op de langere termijn is er maar een echte oplossing: een Continue-achtige guard die commando's canoniseert voordat ze draaien.

De grotere les is dat een AI-codeeragent geen gewone code-editor is maar een programma dat met jouw rechten commando's uitvoert op basis van tekst die het van buiten binnenhaalt. Dat maakt hem onderdeel van je AI-toolchain als nieuw aanvalsoppervlak, waar veiligheid een ontwerpkeuze is en geen product dat je koopt. De vraag voor elk ontwikkelteam is dus niet of je zulke agents gebruikt, maar met welke rechten en in welke omgeving je ze laat draaien voordat ze aan productiecode mogen komen. Wie dat nu vastlegt, hoeft niet te wachten op een patch die er voorlopig niet komt.