Plugin4Shell: zero-click lek in plug-inupdates van AI-codeassistenten

Plugin4Shell is de naam die Air Security geeft aan een gemeld, ernstig zero-click-lek voor remote code execution (RCE) in de plug-inafhandeling van grote AI-codeassistenten. Het gaat niet om een fout in het taalmodel zelf, maar om een risico in de softwareleveringsketen: een aanvaller kan een plug-in die een ontwikkelaar al vertrouwt, omzetten in een route om kwaadaardige code op diens computer uit te voeren. 23

Waar de SHA-pinning misgaat

Plug-inmarktplaatsen koppelen een plug-inversie vaak aan de SHA van een Git-commit. Zo'n pin hoort de verwachte code onveranderlijk te maken: de agent moet precies die revisie ophalen en controleren of het resultaat met de verwachte SHA overeenkomt.

Volgens Air ging het bij het gemelde patroon mis ná het uitchecken van de code. De agent checkte de commit uit die de marktplaats aanwees, maar verifieerde niet of de bestanden die daadwerkelijk op schijf terechtkwamen ook bij die vastgepinde commit hoorden. Iemand die de plug-inrepository beheerst, zou het uitchecken daardoor naar kwaadaardige code kunnen laten verwijzen, terwijl de agent de plug-in toch als vastgepind en vertrouwd behandelt. 2

Dat onderscheid is cruciaal: een hash biedt alleen bescherming als de applicatie onafhankelijk controleert of het ontvangen artefact overeenkomt met de onveranderlijke waarde die zij wilde ophalen. Een pin in de metadata van een marktplaats is onvoldoende wanneer die controle na het ophalen ontbreekt.

Waarom dit een zero-click-aanval heet

De ontwikkelaar hoeft op het moment van de aanval geen nieuwe installatie goed te keuren. Als een legitieme plug-in al is geïnstalleerd, kan een automatische update een door de aanvaller vervangen versie ophalen en uitvoeren — zonder nieuwe melding, klik of herinstallatie. 26

Het eerste toegangspunt ligt dus stroomopwaarts van de ontwikkelaar: bij controle over een vertrouwde plug-inrepository of een gerelateerd publicatiepad. Dit is daarom vooral een risico in de softwareleveringsketen, en niet een geval waarin een gebruiker bewust een duidelijk onveilige extensie installeert.

Wat een aanvaller na code-uitvoering kan bereiken

RCE in een ontwikkelomgeving kan een aanvaller in de praktijk dezelfde reikwijdte geven als de gebruiker en het agentproces. Volgens berichtgeving over de melding kan dat toegang omvatten tot bedrijfssystemen en gegevens die voor de medewerker beschikbaar zijn. 34

De mogelijke blootstelling omvat lokale broncode, repositories, buildgereedschap, omgevingsvariabelen en in de ontwikkelaarsessie beschikbare inloggegevens. Als die inloggegevens toegang geven tot cloudaccounts, broncodebeheerdiensten, CI/CD-systemen of gekoppelde hulpmiddelen, kan een gecompromitteerd werkstation een opstap zijn naar bredere toegang binnen de organisatie. De werkelijke impact hangt af van de rechten en geheimen die de agent en gebruikersaccount daadwerkelijk hebben. 34

Gemelde status per leverancier

Air meldde Plugin4Shell voor Claude Code, OpenAI Codex, Copilot en Gemini CLI. 2

• Anthropic Claude Code: Air en latere berichtgeving noemen Claude Code 2.1.179 als versie met een oplossing. 12
• OpenAI Codex: Codex 0.146.0 zou een oplossing bevatten. 12
• Google Gemini CLI: het getroffen Gemini CLI-pad wordt in de berichtgeving als verouderd beschreven. Google zou dat oude pad niet repareren; gebruikers moeten ervan migreren in plaats van op een patch te wachten. 13
• Microsoft en GitHub Copilot: Air rekende Copilot tot de getroffen agenten, maar openbare beschrijvingen geven geen eenduidige conclusie over de oplossing. Organisaties moeten daarom nagaan welk Copilot-product, extensiekanaal, updatebeleid en welke centraal afgedwongen maatregelen zij gebruiken, in plaats van aan te nemen dat een claim over één route voor elke implementatie geldt. 234

Dit is een snel ontwikkelende openbaarmaking. Controleer daarom altijd de versie en beveiligingsadviezen voor de specifieke agent voordat een installatie als hersteld wordt beschouwd.

Zo verklein je het risico

Bijwerken naar een versie die als opgelost is gemeld, is de eerste stap. De bredere les is dat plug-ins voor codeassistenten behandeld moeten worden als uitvoerbare software van derden, met toegang tot een relatief bevoorrechte ontwikkelomgeving.

Aanbevolen maatregelen:

• Beperk automatische plug-in- en extensie-updates. Laat wijzigingen in code die een agent installeert of uitvoert vooraf beoordelen.
• Gebruik alleen toegestane plug-ins, uitgevers en onveranderlijke versies. Beperk het aantal relaties in de softwareketen dat de ontwikkelomgeving vertrouwt.
• Verifieer het artefact na het ophalen. Dwing af dat de code op schijf overeenkomt met de goedgekeurde, vastgepinde commit of artefactidentiteit; breek de installatie af als dat niet zo is. 28
• Leg herkomst sterker vast. Koppel goedkeuring aan een vertrouwde uitgever én een onveranderlijk artefact of versie, niet alleen aan gedrag van een wijzigbaar updatekanaal.
• Pas het least-privilegeprincipe toe. Geef een agentproces geen brede productietoegang of langlevende inloggegevens als dat niet nodig is. Isoleer of sandbox de uitvoering waar dat haalbaar is.
• Controleer blootstelling van geheimen. Als een getroffen agent of plug-in op een ontwikkelaarsapparaat kan hebben gedraaid, roteer dan relevante inloggegevens en onderzoek toegangslogs. De mogelijke schade volgt de toegang die dat apparaat had. 34

Waarom Plugin4Shell verder reikt dan één lek

Plugin4Shell laat zien hoe AI-agenten bekende beveiligingsproblemen kunnen versterken. Codeassistenten halen steeds vaker plug-ins op en werken naast repositories, cloudtools, tokens en deploymentworkflows. Een inbreuk via een updatepad kan zo uitmonden in diefstal van inloggegevens of toegang tot broncode en infrastructuur. 34

Het probleem komt naast, en niet in plaats van, zorgen over promptinjectie. Een kwaadaardige repository, issue, document of tooluitvoer kan een agent proberen te bewegen tot een onveilige actie. Plugin4Shell is anders: de gemelde zwakte in het updatepad kan kwaadaardige code uitvoeren zonder te wachten op een nieuwe instructie of toestemming van de gebruiker. Beide risico's worden ernstiger wanneer agenten tools mogen gebruiken en betekenisvolle rechten hebben.

De kernboodschap is eenvoudig: beheer een AI-codeassistent als een bevoorrecht automatiseringspunt. Werk hem snel bij, beperk wat hij mag installeren en benaderen, en controleer welke code exact in de ontwikkelomgeving terechtkomt.