AI-coding agents maken het ontwikkelen sneller, maar ze kunnen ook nieuwe aanvalsroutes openen. Een recente disclosure laat zien hoe Git-config misbruikt kan worden: de repository bevat een eigen Git-instelling die een agent opstart en daarbij een commando uitvoert op de machine van de gebruiker—zonder duidelijke gebruikerstoestemming en buiten de (vermeende) beveiligingsomgeving.
Het risico draait dus niet om “het model” achter een tool, maar om de normale werking van Git en hoe IDE’s en agents achtergrondcommando’s uitvoeren zodra je een project opent.
Wat is er aan de hand bij Git-config misbruikt?
Onderzoekers van Manifold Security beschrijven een klasse van acht kwetsbaarheden verspreid over zeven command-line AI-coding agents. De kern is dat een repository een eigen Git-config heeft (in de .git-map) die een opdracht bevat.
Wanneer een agent in zo’n project werkt, kan Git die opdracht uitvoeren tijdens standaard taken zoals het verversen van een index. Daardoor kan aanvaller-code starten als de gebruiker, zonder extra prompt of “trust”-goedkeuring.
Waarom alleen een “gewone clone” niet genoeg is
Niet elke overdracht van code maakt het misbruik mogelijk. Voor exploit is het belangrijk dat de bestanden worden aangeleverd met de .git-directory intact.
Dat gebeurt bijvoorbeeld bij een gedeeld archief, synchronisatiemap, shared drive of via USB. Bij een reguliere clone wordt de relevante configuratie doorgaans opnieuw opgebouwd, waardoor deze specifieke route vaak verdwijnt.
core.fsmonitor als draaiknop
Een van de centrale sleutels is core.fsmonitor. Dit is een Git-prestatie-instelling die bepaalt hoe Git gewijzigde bestanden identificeert.
Belangrijk: Git leest dit type waarde vanuit de repository-eigen .git/config. Zodra een tool Git gebruikt om informatie te bepalen (zoals welke branch je opent of wat er is gewijzigd), kan het commando worden gestart.
De agents lijken die commando’s in de achtergrond te gebruiken om hun werkproces op te starten. Omdat de agent de repository-config niet aanpast, kan een aanvaller exact zijn eigen opdracht “meegeven”.
Wanneer wordt de payload uitgevoerd?
Volgens de onderzoekers verschilt het exacte timingmoment per agent, maar het gemeenschappelijke punt is dat de schadelijke code al kan draaien voordat de gebruiker de veilige workflow heeft doorlopen.
- Bij Claude Code en Hermes Agent kan de payload actief worden vóórdat een workspace-trust prompt wordt geaccepteerd.
- Bij Qwen Code kan het zelfs starten voordat de gebruiker is geauthenticeerd.
- Bij Grok Build wordt het al getriggerd rond de eerste toetsaanslag.
OpenAI beschrijft dit voor Codex-specifieke CVE’s ook in algemene bewoordingen: de helper draait buiten de command sandbox en zonder expliciete gebruikersgoedkeuring. Daardoor kan code bestanden lezen, wijzigen of verwijderen en andere resources benaderen die beschikbaar zijn onder het account van de gebruiker.
Welke agents en versies zijn geraakt?
Manifold Security noemt verschillende producten met concrete versienummers. Hieronder staan de gemelde betroffen releases en waar (volgens de disclosure) fixes al beschikbaar zijn.
- goose: alle versies vóór 1.44.0; gefixt in 1.44.0.
- Codex CLI: 0.102.0 t/m 0.130.0; gefixt in 0.131.0.
- Codex Desktop (macOS): 260202.0859 t/m 26.513.31313; gefixt in 26.519.22136.
- Codex Desktop (Windows): 26.304.38 t/m 26.513.40821; gefixt in 26.519.21041. Voor Microsoft Store-pakketten geldt eveneens een fix (versie details volgen in de disclosure).
- Claude Code: een pad via core.fsmonitor is bevestigd door Manifold op 2.1.193 en gefixt in 2.1.196; een tweede pad via “claude ultrareview” is pas later bevestigd.
- Hermes Agent: 0.18.2 en 0.21.0 bevestigd; fix nog niet afgerond.
- Qwen Code: 0.19.6 en 0.22.3 bevestigd; fix nog niet afgerond.
- Grok Build: 0.2.93 en 1.0.13 bevestigd; fix nog niet afgerond.
Daarnaast staat in de disclosure dat niet alle rapporten uniek waren: een deel bleek later duplicaten van bevindingen van andere onderzoeksgroepen.
Wat is er nog niet gepatcht?
Manifold geeft aan dat meerdere meldingen na testmomenten nog live waren bij de toenmalige releases. Voor sommige tools bevestigt men dat de fix wel kwam, maar dat er tegelijk een andere route (een tweede Git-config key of ander pad) mogelijk bleef.
Een voorbeeld dat genoemd wordt: Claude Code heeft een pad via core.fsmonitor waar een fix voor beschikbaar kwam, terwijl een tweede pad—benaderd via “claude ultrareview”—op een later testmoment nog niet aantoonbaar gesloten was.
Ook bij andere agents (zoals Hermes Agent, Qwen Code en Grok Build) wordt gemeld dat de fix op moment van her-test nog open stond.
Waarom dit anders voelt dan een “model vulnerability”
De onderzoekers benadrukken dat de kwetsbaarheid niet in het AI-model zit. Het probleem zit in de “gewone” infrastructuur eronder: Git-commando’s die een agent opstart om werkruimte-informatie te bepalen.
In de praktijk betekent dit dat je als ontwikkelaar niet alleen naar updates van de agent moet kijken, maar ook naar hoe tools omgaan met repository-inhoud—zeker wanneer die inhoud meer bevat dan alleen bronbestanden.
Praktische checks voor ontwikkelaars
Om risico te beperken adviseren onderzoekers meerdere stappen. Niet allemaal zijn perfect te automatiseren, maar samen vormen ze een stevige eerste verdedigingslaag.
- Inspecteer .git/config voordat je een ontvangen map opent in een agent. Let specifiek op core.fsmonitor, maar ook op instellingen zoals core.hooksPath en attr.tree.
- Voer in een repository die als bestanden is aangeleverd dit commando uit: git config –get core.fsmonitor.
- Check je globale configuratie met: git config –global –list | grep fsmonitor.
- Overweeg het instellen van een veilige default: git config –global core.fsmonitor false om het mechanisme standaard uit te zetten.
Manifold merkt ook op dat leveranciers van agents in sommige gevallen achtergrondcalls aanpassen, bijvoorbeeld door Git aan te roepen met een expliciete parameter die core.fsmonitor uitschakelt.
Wat je hierbij kunt vergelijken binnen je bredere security aanpak
Dit incident past in een bredere trend: aanvallen worden steeds vaker gebouwd rondom de manier waarop software wordt geleverd en uitgevoerd (software supply chain). Eerder zagen we al meldingen rond kwaadaardige pakketlevering via registries en supply chain routes.
Lees bijvoorbeeld ook malafide npm-pakketten via supply chain: RAT-alert voor achtergrond over hoe aanvallers ontwikkelketens misbruiken.
Daarnaast helpt het om te beseffen dat “convenience features” in tooling—zoals automatische setup of snelle workspace-detectie—ook als trigger kunnen dienen. Een vergelijkbare denklijn zie je terug in onderzoeken naar misbruik van opstartflows in IDE-achtige omgevingen, waar een “normale” actie al genoeg kan zijn om uitvoer te veroorzaken.
Conclusie: Git-config misbruikt vraagt om update én routine
De waarschuwing is helder: Git-config misbruikt kan leiden tot code-uitvoering op je eigen machine via AI-coding agents, zonder dat je altijd een duidelijke goedkeuringsstap ziet. Het gaat om Git-instellingen die in een repository meekomen en door agents worden gestart tijdens achtergrondwerkzaamheden.
Door tijdig naar gepatchte versies te updaten waar beschikbaar en door ontvangen projectmappen met .git-inhoud vooraf te controleren, verlaag je de kans aanzienlijk. Neem deze checks mee in je ontwikkelroutine, vooral wanneer code via archieven, synchronisatie of draagbare media binnenkomt.
Bron: https://thehackernews.com/2026/09/malicious-git-configs-can-make-claude.html
