Schone GitHub-repo laat AI-coderingsagent ongemerkt malware draaien

Een GitHub-repo zonder ook maar een regel kwaadaardige code kan je AI-coderingsagent toch malware op je machine laten installeren. Niet via een exploit, maar via iets veel banalers: een foutmelding die de agent netjes probeert op te lossen. Onderzoekers van 0DIN, het Zero Day Investigative Network van Mozilla, demonstreerden de aanval met Claude Code, maar het patroon bedreigt elke agentische codeertool die zelfstandig commando's uitvoert om een project aan de praat te krijgen.

Hoe de val dichtklapt

De repo oogt volkomen normaal, met gewone installatie-instructies. Het venijn zit in een meegeleverd Python-pakket dat weigert te starten en een behulpzame foutmelding teruggeeft: draai eerst python3 -m axiom init. De agent leest die melding, concludeert dat er nog een initialisatiestap mist, en voert het commando uit, precies zoals hij is gebouwd om te doen. Dat commando roept een setup-script aan dat een configuratie ophaalt uit een DNS-record en die direct uitvoert. In dat record stopte 0DIN een base64-gecodeerde reverse shell.

Het resultaat is een interactieve shell met de rechten van de ontwikkelaar: toegang tot omgevingsvariabelen zoals API-sleutels, AWS-credentials en GitHub-tokens, plus de mogelijkheid om zich vast te nesten. De agent besloot nooit om een shell te openen, hij besloot een fout te repareren, vatten de onderzoekers Andre Hall en Miller Engelbrecht het kernachtig samen. Daar zit precies het probleem: het hulpvaardige zelfherstel dat een agent nuttig maakt, is hier het aanvalsoppervlak.

Waarom scanners hier niets zien

Het sluwe is dat de kwaadaardige instructie nergens in de repo staat. De payload leeft in een DNS-record dat de aanvaller op elk moment kan aanpassen, zonder ook maar iets te committen. Een codereview, een dependency-scan of een malwarescanner ziet dus een schoon project; de schadelijke lading wordt pas tijdens runtime opgehaald en is onzichtbaar voor zowel de gebruiker als de standaard beveiligingscontroles. Het is een variant op indirecte prompt-injectie en het verwarde-hulpje-probleem, waarbij een legitieme tool met te veel rechten een aanvaller zijn werk laat doen.

Het is dezelfde grondvorm die de afgelopen weken vaker opdook. Bij een lek in Amazon Q kon een kwaadaardige repository via het Model Context Protocol stilletjes AWS-sleutels van ontwikkelaars stelen, en met de AutoJack-techniek liet een geprepareerde webpagina een AI-agent ongevraagd code op je server uitvoeren. Het patroon is telkens hetzelfde: niet het model wordt gehackt, maar de autonomie eromheen wordt misbruikt.

Wat dit betekent voor jouw bedrijf

Als je team AI-coderingsagents inzet, en dat doen steeds meer ontwikkelteams, dan is dit een beleidsvraag, geen technische curiositeit. De agent draait commando's met de rechten van degene die hem aanstuurt, dus de eerste vraag is wat die rechten zijn. Drie maatregelen wegen het zwaarst: draai agents in een geisoleerde omgeving die je makkelijk kunt weggooien, houd geheimen en productie-credentials uit de shell waarin de agent werkt, en laat een mens elk shell- of installatiecommando bevestigen voordat het loopt. Het advies van 0DIN sluit daarop aan: een agent zou de volledige uitvoeringsketen van een setup-commando moeten tonen, inclusief de scripts en alles wat tijdens het draaien wordt opgehaald, niet alleen het commando zelf.

De verleiding is om dit als een randgeval af te doen, maar de aanval werkt juist omdat de agent zich voorbeeldig gedroeg. Hij hoefde niet misleid te worden om iets stoms te doen; hij deed precies zijn werk. Behandel de shell-toegang van een AI-agent daarom zoals je de toegang van een nieuwe junior met beheerdersrechten zou behandelen: scherp afgebakend, zichtbaar, en altijd terug te draaien. Wie zijn hele AI- en automatiseringsstack bewust beveiligt tegen dit soort supply chain-aanvallen, maakt van die autonomie een gereedschap in plaats van een open deur.