Je coding agent pinde de commit. Hij controleerde nooit waar hij landde

Een pin die vroeg maar nooit controleerdeHover to explore

Er bestaat een soort beveiligingsbevinding die meer waard is dan haar severity-score, omdat het mechanisme je iets leert dat je elders kunt toepassen. Dit is er zo een.

De details komen uit de berichtgeving over de onthulling van AIR door The Register, Help Net Security en Cyber Security News. Patchstatus en leveranciersstandpunten zijn zoals gemeld bij de onthulling en kunnen inmiddels zijn opgeschoven; paragraaf 7 zegt wat ik niet beweer. De lezing van het mechanisme, en alles vanaf paragraaf 4, is van mij.

1. Wat er is onthuld

Op 17 september 2026 publiceerden onderzoekers van AIR Plugin4Shell: een zero-click remote code execution-lek in de pluginsystemen van vier grote AI-coding agents. Ze vonden het in mei 2026, bouwden werkende proof-of-concept exploits tegen alle vier, en meldden het in juni bij de leveranciers.

Status zoals gemeld bij publicatie:

Dat laatste is het signaal. Als vier concurrenten dezelfde bug uitleveren, zijn dat geen vier momenten van onoplettendheid. Het is een gedeelde aanname die niemand ooit heeft opgeschreven.

2. Het mechanisme: een pin die vraagt maar niet controleert

Pluginmarketplaces pinnen een plugin na review aan een specifieke commit-hash. Dit is de controle waar iedereen op vertrouwt: pin een SHA en je krijgt precies de bytes waar iemand naar gekeken heeft. Het is hetzelfde instinct dat achter een lockfile zit.

Dit is wat de getroffen agents werkelijk deden:

1. De marketplace pint de plugin aan een beoordeelde commit-hash van 40 tekens.

   Tot zover goed. Dit deel werkt.

2. De agent vraagt Git om die hash uit te checken.

   Op zichzelf ook prima.

3. Een aanvaller die de pluginrepository beheert pusht een branch met precies diezelfde tekenreeks van 40 tekens als naam.

   Niets houdt je tegen om een branch a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 te noemen. Het is gewoon een tekenreeks.

4. Git lost de referentienaam op vóórdat het de reeks als object-id behandelt, dus de checkout landt op de branch van de aanvaller — en de agent meldt de gepinde SHA als voldaan.

   Omdat hij nooit keek. Zoals de onderzoekers het formuleren: de agent checkt precies de commit uit die de marketplace pinde, maar verifieert nooit dat hij daar landde.

De Gemini CLI-variant is een andere route naar dezelfde plek — een branch met de naam FETCH_HEAD die de checkout weg van de opgehaalde commit stuurt — en dat detail maakt hier een klasse van bugs van in plaats van de misstap van één leverancier.

3. Auto-update is wat het zero-click maakte

Een supply chain-lek vraagt normaal iets van de gebruiker: installeren, bijwerken, een prompt goedkeuren. Plugin4Shell had daar niets van nodig, en de reden is een functie die iedereen prettig vindt.

Claude Code en Codex draaien standaard auto-updates op de achtergrond. Wanneer een marketplace een gepinde SHA ophoogt, draait de agent de checkout op eigen schema opnieuw. Heeft de aanvaller de kwaadaardige branch al klaargezet, dan gebeurt de wissel stil, zonder prompt, zonder installatie en zonder dat er iemand bij is.

Wat het gebruikelijke advies omkeert:

Voor gewone dependencies is "zet automatische updates aan" goed beveiligingsadvies, want het meeste dat auto-update brengt zijn patches. Voor een uitvoeringsoppervlak waar het updatepad zélf het kwetsbare onderdeel is, is automatisch bijwerken het bezorgmechanisme. De twee gevallen zien er op een beleidspagina identiek uit en gedragen zich tegengesteld.

4. De blast radius is je developer, geen sandbox

Het is verleidelijk om "pluginkwetsbaarheid" te lezen als een ingeperkt probleem. Dat is het niet, en dit is het deel dat zou moeten bepalen hoe serieus een klein team het neemt.

Code die via het pluginsysteem van een coding agent wordt uitgevoerd krijgt, in de formulering van de onderzoekers, hetzelfde bereik over de systemen en data van een bedrijf als de medewerker die de agent draait. Op een gewone developerlaptop betekent dat:

Een developerlaptop is bij de meeste bedrijven de minst gesegmenteerde machine en heeft het grootste bereik. Dat is prima zolang de code die erop draait code is die een mens gekozen heeft. Het is iets heel anders wanneer een updatepad kan veranderen wat er draait zonder dat iemand besloot iets te veranderen.

5. De dependency tree die niemand inventariseert

Hier zit het structurele punt, en de reden waarom dit volgens mij verder reikt dan één patchronde.

Je applicatiedependencies zijn gereguleerd. Er is een lockfile, een scanner, een reviewstap als iemand een package toevoegt, en een SBOM als je verkoopt aan iemand die erom vraagt. Die machinerie kostte de sector twintig jaar en werkt grotendeels.

De plugins, skills, extensies en marketplace-installaties van je agent hebben daar niets van.

Applicatiedependencies draaien meestal binnen een service met een afgebakende identiteit. Agentplugins draaien op een werkplek met het volledige gezag van een mens. De laag met de minste review heeft het meeste bereik, wat precies andersom is, en het gebeurde per ongeluk: plugins kwamen binnen als productiviteitsfunctie, niet als software-supply chain, dus niemand hing de supply chain-machinerie eraan.

De meeste teams die ik spreek kunnen "welke agentplugins zijn er in het team geïnstalleerd, in welke versies, van welke makers" niet beantwoorden zonder bureau voor bureau te gaan. Dat is geen nalatigheid. Niemand heeft ze ooit verteld dat het een vraag was.

6. Wat je deze week doet

Vier dingen, ruwweg een middag, en geen ervan vraagt om een securityteam.

1. Werk de agents bij en controleer daarna of de versies er echt op staan.

   Claude Code 2.1.179 en Codex 0.146.0 of nieuwer. Voor alles wat als niet gepatcht of uitgefaseerd wordt gemeld is de vraag of het überhaupt een pluginoppervlak houdt: een ongerepareerd updatepad bewaak je niet, dat zet je uit.

2. Maak de inventaris.

   Elke agentplugin, skill en extensie die in het team is geïnstalleerd, met maker en versie. Meestal is het een korte lijst en ben je er in een uur doorheen. Blijkt het een lange lijst, dan is dat de bevinding.

3. Bepaal het auto-updatebeleid bewust, per oppervlak.

   Update de agent-binary automatisch: zo ontvang je fixes als deze. Overweeg pluginupdates langs een mens te laten gaan, in elk geval voor plugins die code kunnen uitvoeren. Dit zijn twee verschillende beslissingen en de meeste teams nemen er nu standaard één voor allebei.

4. Beperk wat er geauthenticeerd op de werkplek staat.

   Kortlevende cloudcredentials, geen langlevende productietokens in shellprofielen, en geen databasetunnel die de hele dag openstaat. Dit is de maatregel die standhoudt ongeacht welke agent de volgende bug uitlevert, en daarom is hij het eerst de moeite waard.

En één ding om aan je eigen code toe te voegen, wat je ook bouwt:

Zoek elke plek waar je ophaalt op identifier — een commit, een digest, een modelversie, een document-id — en kijk of iets die identifier opnieuw afleidt uit wat er daadwerkelijk binnenkwam. Is het antwoord "we vroegen erom, dus zal het het wel zijn", dan heb je de vorm van Plugin4Shell in je eigen systeem. Dichten kost een paar regels en het is onzichtbaar tot de dag dat het dat niet meer is.

7. Wat ik niet zal beweren

Er is geen bevestigde uitbuiting in de praktijk gemeld. Dit is een onthulling met werkende proof-of-concept exploits, geen incidentrapport. Cijfers die rondgaan over hoeveel agents een kwaadaardige plugin zou kunnen bereiken zijn scenariomodellering, geen telling van gecompromitteerde installaties, en die heb ik bewust weggelaten.

De patchstatus bewoog tijdens de onthulling en bronnen verschillen. Claude Code en Codex worden consistent als gerepareerd gemeld in de bovenstaande versies. De berichtgeving over de blootstelling van Copilot is niet consistent: sommige verslagen noemen het niet gepatcht, andere gemitigeerd door platformmaatregelen. Raadpleeg het advies van je eigen leverancier in plaats van deze tabel.

Dit is geen kwetsbaarheid in Git. Dat Git een dubbelzinnige referentie in een gedocumenteerde volgorde oplost, is Git die werkt zoals gespecificeerd. De bug zit in de agents die aannamen dat het resultaat overeenkwam met het verzoek. De tool de schuld geven zou de verkeerde les zijn en zou je niets laten repareren.

Ik heb hier niets van gereproduceerd. Alles in paragraaf 2 is mijn lezing van gepubliceerde beschrijvingen van het mechanisme, geen onafhankelijke verificatie.

De eerlijke samenvatting

Het interessante hier is niet dat vier coding agents een bug hadden. Het is welke aanname ze allemaal deelden: dat iets precies benoemen hetzelfde is als controleren dat je het gekregen hebt.

Die aanname zit overal. Ze zit in elke integratie die een webhook vertrouwt omdat er het juiste id op staat, in elke cache die op sleutel antwoordt zonder de inhoud te valideren, in elke pipeline die latest ophaalt en zichzelf reproduceerbaar noemt. Pinnen op een hash voelde veilig omdat een hash specifiek is — maar specificiteit is geen verificatie, en het gat daartussen is precies waar deze klasse bugs woont.

Ondertussen is de praktische blootstelling onglamoureus en direct: een codepad dat kan veranderen wat er op een developerlaptop draait zonder dat iemand die verandering goedkeurt, op de minst gesegmenteerde machine van het pand.

Werk de agents vandaag bij. Besteed daarna een uur aan uitzoeken welke plugins je team geïnstalleerd heeft, want dat is op dit moment een vraag die de meeste teams niet kunnen beantwoorden — en het is dezelfde vraag die de eerste serieuze securityreview van een klant gaat stellen.

Bronnen: The Register, "AI coding agents' 0-click RCE flaw could hand attackers keys to the kingdom", 17 september 2026 — de tijdlijn van de onthulling, de twee aanvalsroutes en de standpunten van de leveranciers. Help Net Security, "Zero-click RCE vulnerability hit four major AI coding agents", 18 september 2026 — de ontdekking in mei 2026, de melding in juni, de gepatchte versies 2.1.179 en 0.146.0, en de formulering van de privileges die de uitgevoerde code erft. Cyber Security News — het mechanisme met de branch van 40 tekens en de FETCH_HEAD-variant die Gemini CLI treft. Het onderzoek is van AIR. De generalisatie in paragraaf 2, het argument over auto-update in paragraaf 3, het inventarisargument in paragraaf 5 en alle aanbevelingen zijn van mij. Voor het vorige supply chain-incident op dit thema, zie de pakketvloed bij RubyGems, en voor het permissiemodel dat beperkt hoever een gecompromitteerde plugin reikt, zie permissiesystemen voor agents.

Related Posts

Een register gaf publicatiesleutels af vóór e-mailverificatie. Toen kwamen er 2.000 packages14 september 2026

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026

AI Agents Need Permission Systems, Not Better Prompts — A Founder’s GuideJuly 14, 2026