Plugin4Shell: Fyra AI-kodagenter litade på en pin som de aldrig kontrollerade

Den 17 september 2026 publicerade AIR Security, en startup som bygger säkerhetsverktyg för företags-AI-agenter, forskning som beskriver Plugin4Shell – en zero-click-sårbarhet för fjärrkörning av kod i fyra AI-kodagenter: Anthropics Claude Code, OpenAIs Codex, GitHub Copilot och Googles Gemini CLI. Buggen finns inte i någon modell. Den ligger i den git checkout som varje agent gör när den installerar ett plugin, och i att ingen av de fyra verifierade att koden den tog emot var den kod den hade pinnat. Två av de fyra hade en patch när forskningen publicerades. Två hade det inte. Den här incidenten är en post i the Orca AI Incident Archive, som registrerar den som en leveranskedjesårbarhet med hög allvarlighetsgrad utan rapporterad exploatering.

Vad agenterna faktiskt gjorde fel

Varje drabbad agent installerar plugins från en marknadsplats, och varje marknadsplats låser en plugin till en specifik git-commit – en SHA på 40 tecken – när pluginen har granskats. Den låsningen utgör hela säkerhetsmodellen: en granskare godkänner en oföränderlig version, och agenten förväntas fortsätta köra den versionen även om repot bakom den senare ändras. AIR beskriver bristen som en bypass av SHA-låsning för plugins. Agenten checkar ut exakt den commit som marknadsplatsen låste men verifierar aldrig att arbetsträdet den hamnar i är den commiten. Med forskarnas ord: agenten "checkar ut exakt den commit som marknadsplatsen låste men verifierar aldrig att den landade där, så en angripare som kontrollerar pluginens repo får utcheckningen att resultera i skadlig kod medan låsningen fortfarande ser ut att respekteras."

{{1}}Git{{/1}} fyller luckan. {{2}}När ett namn både är en giltig gren och ett commit-objekt föredrar git grenen och skriver bara en varning om tvetydighet.{{/2}} {{3}}En angripare som kontrollerar pluginens repository skapar en gren vars namn är exakt den 40-teckens hexadecimala fästa SHA:n, pekar den mot skadlig kod och gör den till repots standardgren.{{/3}} {{4}}En vanlig klon tar då ner den grenen lokalt under det SHA-formade namnet, och den efterföljande utcheckningen löser sig till den.{{/4}} {{5}}Den fästa commiten kan i sig förbli orörd, så inget i den granskade versionen ser fel ut.{{/5}} {{6}}Enligt AIR måste två villkor vara uppfyllda: grenen med SHA-namn måste vara standardgren, eftersom en icke-standardgren endast hämtas som en fjärrspårande ref och utcheckningen skulle falla tillbaka på den riktiga commiten; och git-värden måste acceptera ett 40-teckens hexadecimalt grennamn.{{/6}} {{7}}GitHub avvisar sådana namn direkt.{{/7}} {{8}}Bitbucket och självhostade git-servrar gör det inte.{{/8}}

Gemini CLI misslyckades via en annan väg. Det hämtade den fastnaglade commiten, registrerade den i repositoryts FETCH_HEAD-fil och körde sedan en checkout av FETCH_HEAD – en checkout som inte behöver läsa den filen. Ett repository vars standardgren själv heter FETCH_HEAD omdirigerar checkouten till innehåll som angriparen kontrollerar och kastar tyst bort den commit som hämtades. Cybersecurity News redogörelse för mekanismen stämmer överens med AIR:s, inklusive åtskillnaden mellan de två varianterna.

Varför ingen behövde klicka på något

Samma utcheckning körs igen vid automatisk pluginuppdatering i bakgrunden, vilket är standard i Claude Code och Codex. Det är det som gör attacken till nollklick snarare än bara tyst: när en marknadsplats bumpar en pinnad SHA till en rutinmässig ny version, kör varje agent som redan har plugin installerat om utcheckningen utan prompt och utan användaråtgärd. AIR:s poäng är att offret inte behöver installera något oaktsamt. De behöver ha installerat ett plugin, från en marknadsplats de litar på, som granskades och pinnades exakt så som designen avser.

Det finns två sätt att nå den positionen, och inget av dem kräver att man kontrollerar marknadsplatsen. I det första publicerar en angripare ett genuint ofarligt plugin som klarar granskningen, bygger upp en installerad bas, släpper en normal uppdatering och skapar först därefter grenen med det skadliga namnet. I det andra tar angriparen över arkivet bakom ett plugin som någon annan har skrivit och som marknadsplatsen redan litar på, och skickar sedan ut den skadliga versionen till alla som har det installerat.

Siffrorna bakom de två vägarna kommer från AIR:s tidigare arbete, inte från Plugin4Shell. I en kampanj som företaget kallar The Story of Skills säger det att ett plugin som det byggde spreds till fler än 26 000 agenter innan det drogs tillbaka. I SkillJacking rapporterade det att 925 skills som redan användes aktivt hade tagits över från sina ursprungliga underhållare och nått 134 000 agenter. AIR:s rubrik för Plugin4Shell-inlägget hävdar "miljoner agenter påverkade"; forskningen anger ingen siffra för exponerade installationer, och ingen tredje part har publicerat någon.

Tidslinjen, och var åtgärderna landade

AIR säger att de hittade sårbarheten i maj 2026 med fungerande proof-of-concept-exploater mot alla fyra agenterna, och att de avslöjade den för varje leverantör följande månad inom ramen för koordinerad avslöjning. Anthropic bekräftade sin rättning i Claude Code 2.1.179 den 17 juni. Google meddelade AIR den 4 augusti att ingen rättning skulle släppas, eftersom Gemini CLI håller på att avvecklas. Codex 0.146.0 verifierades åtgärdad den 12 augusti. Microsoft har inte släppt någon rättning för GitHub Copilot.

Patchversionerna är den enda offentliga bekräftelsen på att sårbarheten var verklig i de två produkter som åtgärdade den. Anthropics publicerade ändringsloggpost för 2.1.179 listar hantering av anslutningsavbrott, WSL2-rullning, fixar för sandbox-glob och gränssnitt, och nämner inte pinning, pluginverifiering eller någon form av säkerhetsrättelse. The Hacker News gjorde samma iakttagelse, enligt The Next Webs redogörelse. Vid tidpunkten för forskningens publicering hade ingen CVE-identifierare tilldelats, och Cloud Security Alliances forskningsnotis om sårbarheten upprepar att ingen identifierare fanns tre månader efter det att leverantörerna hade meddelats.

Fyra leverantörer, tre olika svar

Google gick längre än att avstå från att patcha. Man utfasade Gemini CLI, vilket innebär att befintliga installationer förblir exponerade så länge folk fortsätter att köra dem. Rådet är att migrera till Antigravity, den nyare agentiska utvecklingsmiljön, som AIR säger att attacken inte når eftersom den inte har någon SHA-pinning för plugin från marknadsplatsen att kringgå.

GitHubs hållning är återigen en annan. En talesperson för GitHub sade till The Register att plattformen inte tillåter användare att skapa gren- eller taggnamn som liknar commit-SHA:er, och att "denna åtgärd säkerställer att den rapporterade sårbarheten inte kan utnyttjas på GitHub". AIR bestrider omfattningen av den åtgärden, inte dess existens: marknadsplatser kan ligga på andra plattformar som Bitbucket, sade forskarna till The Register, och GitHub Copilot stöder fortfarande marknadsplatser från dessa plattformar, så varianten med grennamn är fortfarande åtkomlig för Copilot-användare. AIR säger också att Anthropics egen dokumentation listar Bitbucket och självhostad git som giltiga backend-system för marknadsplatser; Anthropics nuvarande marknadsplatsdokumentation beskriver att en marknadsplats kan läggas till från en git-repositorie-URL, inte bara från GitHub. Microsoft svarade inte på The Registers begäran om kommentar, och AIR sade att man inte hade fått något svar från Microsoft sedan man rapporterade problemet i juni, med hänvisning till den stora mängd avslöjanden som företaget hanterar.

Detta är en oenighet om hur omfattande exponeringen är, inte om huruvida buggen finns. GitHubs åtgärd är en begränsning på värdnivå; AIR:s slutsats är att kontrollen måste ske inuti agenten, eftersom pinningen löses upp på klienten.

Vad som är fastställt, och vad som inte är det

• Fastställt: mekanismen. AIR:s redogörelse anger de exakta git-kommandona, regeln att ref går före objekt vid uppslagning, de två villkor som branch-tricket kräver och den separata FETCH_HEAD-varianten för Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld och The Next Web rapporterar alla om det på samma sätt.

• Fastställt: två patchade versioner. Anthropic bekräftade Claude Code 2.1.179 den 17 juni 2026 och OpenAI:s Codex 0.146.0 verifierades vara åtgärdad den 12 augusti 2026, enligt AIR:s tidslinje för offentliggörandet.

• Fastställt: två produkter hade ingen patch vid offentliggörandet. Google kommer inte att patcha Gemini CLI och lägger ned det; Microsoft har inte levererat någon Copilot-fix.

• Ej fastställt: oberoende reproduktion. Varje publicerad redogörelse går tillbaka till AIR:s eget blogginlägg, och Cloud Security Alliances forskningsnot beskriver uttryckligen inte någon tredjepartsteknisk validering eller oberoende reproduktion av exploiten. Av den anledningen sätter arkivet tillförlitlighetsgraden för denna post till B.

• Inte fastställt: hur många installationer som faktiskt exponerades. "Miljoner" är AIR:s beskrivning i rubriken, inte en uppmätt siffra.

• Ej fastställt:om en uppdatering av en påverkad agent tar bort ett plugin som redan har bytts ut, eller bara förhindrar nästa utbyte. Ingen publicerad källa ger svar på det.

• Inte fastställt: någon verklig användning. Ingen källa i materialet rapporterar utnyttjande, sondering eller angriparinfrastruktur, och arkivet registrerar verklig skada som falsk. Det är en avsaknad av rapportering, inte bevis för att ingenting hände.

En kontroll från tredje part snävar onekligen in den praktiska bilden. The Next Web, som sammanfattar kontroller från The Hacker News, rapporterar att plugins i Anthropics communitykatalog och i standardkatalogerna för Claude Code och Copilot pekar på GitHub-repositorier, och att automatisk uppdatering är på som standard främst för dessa inbyggda marknadsplatser. Eftersom GitHub avvisar grennamn som ser ut som SHA, är grennamnsvarianten svårare att nå för användare som stannar kvar på standardkatalogerna. Det resonemanget omfattar inte Gemini CLI:s FETCH_HEAD-variant, som inte beror på hur värden namnger grenar.

Hur en åtgärd måste se ut

AIR:s rekommenderade åtgärd är en enda assertion: efter utcheckning, lös upp den commit som faktiskt finns i arbetsträdet och avbryt om den inte motsvarar den pinnade SHA:n. Forskarna betonar att den måste kontrollera den upplösta HEAD i stället för den ref som efterfrågades, eftersom den skillnaden är precis det som Gemini CLI-varianten utnyttjar för att slinka igenom, och att den måste köras inuti agenten, eftersom pinnen löses upp på klienten och ingen marknadsplats kan upprätthålla den garanti som den annonserar.

Praktiska råd för team som kör dessa agenter, hämtade från AIR, Cybersecurity News och analytikerkommentarerna i InfoWorld:

• Uppdatera Claude Code till 2.1.179 eller senare och Codex till 0.146.0 eller senare. Uppdatering är den enda fullständiga åtgärden där en patch finns.

• Inaktivera automatiska pluginuppdateringar på alla agenter som saknar patch. Det minskar sårbarheten från zero-click till en manuell ominstallation, vilket är en minskning av exponeringen snarare än en åtgärd.

• Migrera bort från Gemini CLI i stället för att vänta på en patch som Google har sagt inte kommer.

• Granska plugin-inventeringen och begränsa marknadsplatskällor där det är möjligt. AIR noterar att en marknadsplats kan mildra branch-namnvarianten genom att endast tillåta värdar som avvisar SHA-formade namn, i praktiken endast GitHub, men att detta förbjuder värdar som agenterna officiellt stöder och inte gör något för Gemini-varianten.

• Betrakta arbetsstationen som exponeringsgränsen. Plugin-program ärver agentens behörigheter, så en lyckad exploatering når källkod, SSH-nycklar, molninloggningsuppgifter, CI/CD-token och interna repositories med utvecklarens egen behörighet. Pareekh Jain, chefsanalytiker på Pareekh Consulting, sade till InfoWorld att säkerhetsteam bör granska EDR-, git-, CI/CD-, moln-IAM- och autentiseringsloggar efter ovanliga processer, oväntade plugin-filer, ändrade repositories och misstänkt git-aktivitet – och tillade att dessa åtgärder minskar risken utan att åtgärda den underliggande bristen, som han tillskriver leverantörens kod. "Företag kan lägga kontroller runt användningen av plugin-program", sade han till InfoWorld, "men de kan inte åtgärda en brist i hur kodagenten validerar koden den checkar ut."

Varför en pinning-bugg är den som verkligen spelade roll

SHA-pinning var branschens svar på precis den typ av övertagande som AIR redan hade demonstrerat: om ett offentligt kodförråd komprometteras fortsätter agenten att köra den granskade hashen i stället för att hämta vad angriparen än har pushat. Plugin4Shell bryter inte hashen. Det visar att agenterna löste upp pinningen till ett grennamn som bara såg ut som hashen, och aldrig jämförde resultatet. Allt nedströms från det antagandet – granskningsprocesser, interna allowlistor, den tillit utvecklare fäster vid en pinnad version – ärver felet.

Det som underlaget inte stöder är påståendet att något skulle ha tagits. Det är en sårbarhet som hittades och, i två av fyra fall, åtgärdades; ingen källa i det rapporterar ett intrång, och produkterna som inte släppte en patch väntar fortfarande. Den öppna frågan är den minst tillfredsställande: för alla som körde ett plugin på en agent utan patch finns det inget offentliggjort sätt att avgöra om koden som kördes var koden de godkände.