Plugin4Shell: Sikkerhedshul i AI-kodeagenter kan køre skadelig kode uden klik

Plugin4Shell er navnet, sikkerhedsfirmaet Air har givet et rapporteret, alvorligt zero-click-sikkerhedshul med fjernkørsel af kode (RCE) i håndteringen af plugins hos store AI-kodeagenter. Det er ikke en fejl i selve sprogmodellen, men et problem i softwareforsyningskæden: En angriber kan gøre et plugin, som udvikleren allerede har tillid til, til en vej ind for skadelig kode på udviklerens computer. 23

Sådan kan SHA-pinning blive omgået

Pluginmarkedspladser bruger ofte en Git commit-SHA til at identificere en bestemt pluginrevision. Ideen er enkel: Når et plugin er låst til en konkret commit, bør agenten hente præcis den uforanderlige version og kontrollere, at den hentede kode svarer til den forventede SHA.

Ifølge Airs rapport fejlede den afgørende kontrol efter checkout. Agenten checkede den commit ud, som markedspladsen havde angivet, men bekræftede ikke, at filerne på disken faktisk svarede til den låste commit. Hvis en angriber får kontrol over pluginets repository, kan vedkommende derfor få checkout-processen til at ende i skadelig kode, mens agenten fortsat opfatter pluginet som fastlåst og betroet. 2

Det er en væsentlig forskel: En hash beskytter kun, hvis programmet selv sammenligner det modtagne artefakt med den uforanderlige værdi, det skulle hente. En pin i markedspladsens metadata er ikke i sig selv nok, hvis valideringen efter checkout mangler.

Hvorfor angrebet kaldes “zero click”

Udvikleren skal ikke godkende en ny installation på det tidspunkt, hvor kompromitteringen sker. Er et legitimt plugin allerede installeret, kan en automatisk opdatering hente og afvikle angriberens erstatning uden nyt klik, prompt eller geninstallation. 26

Angriberens første adgang ligger dermed opstrøms for udvikleren: kontrol over et betroet pluginrepository eller en tilknyttet udgivelsesvej. Det er derfor først og fremmest en risiko i forsyningskæden – ikke et tilfælde, hvor brugeren bevidst installerer en åbenlyst usikker udvidelse.

Hvad en angriber kan få adgang til

Fjernkørsel af kode i et udviklingsmiljø kan give angriberen samme praktiske adgang som den bruger og agentproces, der afvikler koden. Ifølge rapporteringen kan det omfatte virksomhedens systemer og data, som medarbejderen har adgang til. 34

Det kan i praksis være lokale kildefiler, repositories, buildværktøjer, miljøvariabler og legitimationsoplysninger, der er tilgængelige i udviklersessionen. Giver disse oplysninger adgang til cloudkonti, kildekodetjenester, CI/CD-systemer eller forbundne værktøjer, kan en kompromitteret arbejdsstation blive springbræt til bredere adgang i organisationen. Konsekvensen afhænger dog af de konkrete rettigheder og hemmeligheder, som agenten og brugerkontoen har adgang til. 34

Status for de berørte leverandører

Air rapporterede Plugin4Shell på tværs af Claude Code, OpenAI Codex, Copilot og Gemini CLI. 2

• Anthropic Claude Code: Air og efterfølgende rapportering peger på Claude Code 2.1.179 som en version med rettelsen. 12
• OpenAI Codex: Codex 0.146.0 blev rapporteret som rettet. 12
• Google Gemini CLI: Den berørte vej i Gemini CLI blev beskrevet som forældet. Rapporteringen angiver, at Google ikke ville rette denne ældre vej, og at brugere derfor bør migrere frem for at afvente en patch. 13
• Microsoft og GitHub Copilot: Air inkluderede Copilot blandt de berørte agenter, men offentlige beskrivelser giver ikke én uomstridt konklusion om afhjælpning. Organisationer bør derfor vurdere det præcise Copilot-produkt, udvidelseskanalen, opdateringsopsætningen og de centralt håndhævede kontroller – og ikke antage, at en vurdering af én vej gælder alle installationer. 234

Da dette er en hurtigt udviklende offentliggørelse, og leverandørernes status kan ændre sig, bør teams kontrollere versioner og aktuelle sikkerhedsmeddelelser for den konkrete agent, de bruger, før en installation betragtes som afhjulpet.

Sådan mindskes risikoen

Opdatering til en version, der er rapporteret som rettet, er første skridt. Den bredere læring er, at plugins til kodeagenter skal behandles som eksekverbar tredjepartssoftware med adgang til et privilegeret udviklingsmiljø.

Anbefalede tiltag omfatter:

• Begræns automatiske plugin- og udvidelsesopdateringer. Kræv gennemgang af ændringer i kode, som agenten skal installere eller køre.
• Brug tilladelseslister for nødvendige plugins, udgivere og uforanderlige versioner. Begræns antallet af relationer i forsyningskæden, som udviklingsmiljøet stoler på.
• Kontrollér artefaktet efter hentning. Håndhæv, at koden på disken matcher den godkendte, låste commit eller artefaktidentitet; afbryd ellers processen. 28
• Indfør stærkere provenienskrav. En godkendelsespolitik bør binde en betroet udgiver til et uforanderligt artefakt eller en version – ikke kun til en opdateringskanal, der kan ændres.
• Anvend princippet om mindst mulige rettigheder. Giv ikke agentprocessen bred produktionsadgang eller langlivede legitimationsoplysninger, medmindre det er nødvendigt. Isolér eller sandbox agentafvikling, hvor det er muligt.
• Gennemgå eksponering af hemmeligheder. Hvis en berørt agent eller et plugin kan have kørt på en udviklers endpoint, bør relevante legitimationsoplysninger roteres, og adgangslogs undersøges. Den mulige skade følger den adgang, endpointet havde. 34

Hvorfor sagen rækker ud over én fejl

Plugin4Shell viser, hvordan AI-agenters udrulning kan forstærke kendte sikkerhedsproblemer. Kodeagenter henter i stigende grad plugins og arbejder tæt på repositories, cloudværktøjer, tokens og deployment-workflows. Et kompromis i opdateringsvejen kan derfor blive en rute til tyveri af legitimationsoplysninger eller adgang til kildekode og infrastruktur. 34

Sagen supplerer – men erstatter ikke – bekymringer om prompt injection. Et ondsindet repository, issue, dokument eller værktøjsoutput kan forsøge at overtale en agent til at udføre en usikker handling. Plugin4Shell er anderledes: Den rapporterede svaghed i opdateringsvejen kan afvikle skadelig kode uden at afvente en ny instruktion eller brugergodkendelse. Begge risici bliver større, når agenter kan bruge værktøjer og har betydelige rettigheder.

Den centrale sikkerhedslære er enkel: En AI-kodeagent bør administreres som et privilegeret automatiseringsendepunkt – ikke som en passiv editorudvidelse. Opdatér den hurtigt, begræns hvad den må installere og tilgå, og verificér den præcise kode, der kommer ind i udviklingsmiljøet.