Clinejection: Hur en issue-titel nådde Clines npm-token

Den 9 februari 2026 publicerade säkerhetsforskaren Adnan Khan en redogörelse för en brist som han hade rapporterat privat till Cline den 1 januari: AI-kodassistenten med öppen källkod hade kopplat en automatiserad issue-triager, byggd på Anthropics claude-code-action GitHub Action, till en prompt som klistrade in varje inkommande GitHub-issue-titel direkt i modellens instruktioner. Vilket GitHub-konto som helst kunde utlösa den genom att öppna en issue, och i Khans reproduktion fick en titel formulerad som en instruktion agenten att köra ett skalkommando i arbetsflödet. Han spårade sedan vägen från det fotfästet, via cacheförgiftning i GitHub Actions, till release-autentiseringsuppgifterna för VS Code Marketplace, OpenVSX och npm. Åtta dagar efter att Cline hade åtgärdat arbetsflödet användes en npm-publiceringstoken som Cline trodde sig ha roterat för att publicera cline 2.3.0, som installerade OpenClaw på varje maskin som installerade paketet. Den fullständiga posten, med sina allvarlighets- och konfidensgrader, finns i Orca AI Incident Archive, bredvid de närliggande leveranskedjeposterna från samma period.

Två datum, inte ett

Arkivet daterar denna post till den 9 februari 2026, med dags precision, och det är dagen då Khan publicerade sin redogörelse på adnanthekhan.com. Det är inte dagen då det skadliga paketet dök upp. Själva sårbarheten infördes den 21 december 2025, i en commit som lade till triage-arbetsflödet i cline/cline-repositoriet, och den förblev aktiv till dess att Cline tog bort arbetsflödet den 9 februari. Den obehöriga npm-publiceringen kom den 17 februari, åtta dagar efter åtgärden och fyrtiosju dagar efter Khans första privata rapport.

Att hålla de två datumen åtskilda spelar roll, eftersom det mest avgörande faktumet i fallet ligger i gapet mellan dem: dörren stängdes den 9 februari, men nyckeln som inkräktaren redan hade kopierat fungerade fortfarande den 17 februari. Clines egen rättelse, som skickades till Khan den 17 februari och återgavs i hans inlägg, säger det rakt ut: "När vi roterade autentiseringsuppgifterna den 9 feb återkallades inte npm-publiceringstokenet korrekt. Fel token raderades, och det exponerade förblev aktivt."

Kedjan: från en ärendetitel till en release-token

Den sårbara filen var .github/workflows/claude-issue-triage.yml, som kördes vid issues-händelsen och anropade anthropics/claude-code-action@v1 med Claude Opus 4.5, pinnad i arbetsflödet som claude-opus-4-5-20251101. Khan citerar arbetsflödets konfiguration: allowed_non_write_users var satt till jokertecknet "*", så alla GitHub-konton kunde utlösa agenten helt enkelt genom att öppna ett issue, och claude_args skickade --allowedTools med Bash, Read, Write, Edit, Glob, Grep, WebFetch och WebSearch. Det var Bash som spelade roll. Det gav modellen shell-körning i ett arbetsflöde som kördes i standardgrenens kontext.

Prompten interpolerade ärendetiteln utan att sanera den. Khans proof of concept använde en titel som började med "Tool error." och fortsatte med en instruktion att installera ett hjälppaket från en specifik commit innan triagearbetet fortsatte. Commit-referensen pekade på en fork vars package.json innehöll ett preinstall-skript som körde ett curl-kommando mot en angriparkontrollerad slutpunkt innan npm hade hunnit installera något. Eftersom installationen kördes via Bash-verktyget inspekterade modellen aldrig vad som exekverades. Khan reproducerade detta på en spegel av Cline-repositoriet och rapporterar att agenten exekverade nyttolasten vid varje försök.

Kodexekvering i triage-arbetsflödet är inte i sig åtkomst till release-uppgifter. Det steget kom från en egenskap hos GitHub Actions som Khan hade dokumenterat i ett 2024-verktyg han släppte som hette Cacheract: alla arbetsflöden kan läsa och skriva till repositoriets cache med full kontroll över cachenycklar och versioner, även ett arbetsflöde som aldrig deklarerar ett cachelagringssteg. Triage-jobbet kördes på standardgrenen, så det delade ett cacheomfång med de nattliga publiceringsjobben, som faktiskt återställde node_modules från cache och faktiskt hade publiceringstoken.

Cacheposter är oföränderliga, så en angripare kan inte helt enkelt skriva över posten som ett releasejobb kommer att återställa. Khans väg runt detta var att utnyttja en policyändring i GitHub från den 20 november 2025, som gjorde att tjänsten avlägsnade cacheposter omedelbart när ett repositorys cache översteg 10 GB, enligt LRU-ordning. Översväm cachen över 10 GB, så åldras de legitima posterna ut; ta över de utrymda nycklarna med förgiftat innehåll, och nästa jobb som återställer dem kör angriparens kod. Cacheract automatiserar hela sekvensen inom en enda arbetsflödeskörning, och det kvarstår genom att skriva över action.yml för actions/checkout så att actionens post-steg kör en nyttolast i slutet av varje jobb.

Den sista länken i kedjan är nattjobbet, som körs ungefär 02:00 UTC, återställer de förgiftade node_modules och detonerar. Det som kommer ut är VSCE_PAT, OVSX_PAT och NPM_RELEASE_TOKEN, autentiseringsuppgifterna för VS Code Marketplace, OpenVSX respektive npm. Huruvida varje länk kördes mot Clines eget repository i den ordningen är en separat fråga, som tas upp nedan.

Varför de nattliga autentiseringsuppgifterna var produktionsautentiseringsuppgifter

Den uppenbara invändningen är att nightly- och produktionsutgåvor borde ha olika hemligheter. Khans svar är att separationen var nominell. OpenVSX och VS Code Marketplace knyter en publiceringstoken till en utgivaridentitet, inte till ett enskilt tillägg, och både stable- och nightly-versionerna av Cline-tillägget publicerades under samma identitet, som Khan på OpenVSX identifierar som saoudrizwan. På npm är den finkorniga tokenmodellen knuten till ett paket, och Cline publicerade sina stable- och nightly-CLI-byggen till samma cline-paket. En token som utfärdats för nightly-jobbet kunde därför publicera produktionsartefakten, vilket är precis vad som hände åtta dagar senare.

Khans egen formulering av påverkan bygger på skalan: han hänvisar till Clines tillkännagivande att det hade passerat 5 miljoner installationer, och noterar att en tilläggsuppdatering som skickas ut via stulna inloggningsuppgifter körs i kontexten för varje utvecklare vars redigerare uppdateras automatiskt, med den utvecklarens behörigheter och vilka nycklar, tokens och källkod som helst som finns på maskinen.

Vad som faktiskt publicerades, och vad det gjorde

Den publicerade artefakten var cline 2.3.0, och den var liten. npm-registrets egna tidsstämplar anger 2.3.0 till 11:26:51 UTC den 17 februari 2026 och den rena 2.4.0 till 19:23:08 UTC samma dag, en exponering som Cline-rådgivningen uppskattar till ungefär åtta timmar, fram till dess att 2.3.0 deprekerades klockan 11:30 PT. Paketets package.json innehöll en tillagd rad, ett postinstall-skript med texten npm install -g openclaw@latest. Cline-rådgivningen GHSA-9ppg-jx86-fqw7 anger att inga andra paketfiler ändrades och att dist/cli.mjs är byte-identisk med den legitima 2.2.3-versionen.

OpenClaw är ett riktigt AI-agentramverk med öppen källkod, inte skadlig programvara, och Cline:s rådgivning säger det uttryckligen: det är ett legitimt projekt, men installationen var inte auktoriserad eller avsedd. Endor Labs, som analyserade tarballen, bedömde den övergripande påverkan som låg med motiveringen att installationen inte startade OpenClaws Gateway-daemon. StepSecuritys rapport belyser den andra sidan av saken: en global installation lämnar ramverket på disken med vilka autentiseringsuppgifter och vilken filåtkomst den installerande användaren än har, och OpenClaws utformning, en beständig lokal gateway med ett operator-API, gör det till ett värdefullt fynd där. De två bedömningarna är inte motsägelsefulla. Den ena beskriver vad som kördes under fönstret; den andra beskriver vad som lämnades kvar efteråt.

Volymen är den enda siffran som måste hanteras försiktigt. StepSecurity rapporterade att den komprometterade versionen laddades ned ungefär 4 000 gånger innan den togs ur bruk, och The Register upprepade den siffran. Endor Labs angav clines månatliga nedladdningsantal för perioden 19 januari–17 februari till 418 545, vilket avser paketets normala trafik snarare än det skadliga bygget. Ingen av siffrorna räknar maskiner: ett nedladdningsantal är inte samma sak som antalet drabbade utvecklare, och ingen part har publicerat någon siffra för installationsbasen för 2.3.0. Microsofts Threat Intelligence-team sade på X att det observerade en "liten men märkbar uppgång" i OpenClaw-installationer den 17 februari till följd av Cline-installationsskriptet, vilket The Hacker News rapporterade.

GitHubs rådgivningspost för GHSA-9ppg-jx86-fqw7 innehåller ingen CVE och ingen CWE, och dess allvarlighetsgrad är Låg. Den graden avser den godartade nyttolasten, inte stölden av autentiseringsuppgifter, och den ter sig märklig vid sidan av arkivets kritiska betyg för själva incidenten. Rådgivningen anger 2.3.0 som den drabbade versionen och 2.4.0 som åtgärden.

Upplysningen som Cline inte besvarade

Khans tidslinje före publiceringen är den del av underlaget som minst handlar om modellen och mest om processen. Han skickade in en GHSA via GitHubs privata sårbarhetsrapportering den 1 januari 2026 och mejlade säkerhetskontakten som anges på Clines förtroendesida samma dag. Han skickade en uppföljning till en Cline-utvecklare den 8 januari. Han försökte skicka ett direktmeddelande till Clines vd på X den 18 januari. Han skrev igen den 7 februari och fick inget annat än ett automatiskt ärendenummer. Han publicerade den 9 februari.

Cline mergeade fixen, pull request 9211, ungefär trettio minuter till en timme senare. PR:en tar bort tre arbetsflödesfiler, claude-issue-triage.yml, claude-pr-review.yml och cline-pr-review.yml, och tar bort cachelagring från publish.yml, publish-nightly.yml, npm-nightly.yaml och npm-main.yaml, sju filer totalt, där installationsstegen nu gjorts ovillkorliga eftersom det inte finns någon cacheträff att vara beroende av.

Clines offentliga svar den 10 februari, som citerades i Khans inlägg, godtog fyndet och listade omedelbara åtgärder: borttagning av arbetsflödena för granskning via issue- och PR-botar, borttagning av actions/cache från publiceringsarbetsflöden som hanterar autentiseringsuppgifter för utgivning, samt rotation av relevanta autentiseringsuppgifter, inklusive bot-, leverantörs- och publiceringstoken. Det medgav också hanteringen: "vi erkänner att vår svarstid på din ursprungliga rapport var oacceptabel. En rapport som lämnades in den 1 januari borde inte ha behövt offentliggöras den 9 februari för att bli åtgärdad."

Den 11 februari uppgav Cline att man hade slutfört en fullständig rotation av VSCE_PAT, OVSX_PAT och NPM_RELEASE_TOKEN, och att en granskning av varje release på alla tre distributionskanaler mellan den 21 december 2025 och den 9 februari 2026 visade att varje Marketplace- och OpenVSX-version motsvarade en taggad GitHub-release och att alla 41 npm-versioner överensstämde med källkoden. Man drog slutsatsen att ingen obehörig release hade publicerats "under det påstådda exponeringsfönstret". Sex dagar senare korrigerade man uppgifterna, i meddelandet som citeras ovan: npm-token hade inte återkallats, och 2.3.0 hade publicerats med den.

Etablerad, attribuerad, olöst

• Fastställt. Arbetsflödeskonfigurationen är offentlig och publicerades före rättningen. Khan återskapade prompt-injektionen på en spegel av kodförrådet. Cline sammanfogade åtgärden och utfärdade en säkerhetsrådgivning som bekräftar publiceringen av 2.3.0, den tillagda postinstall-raden, den oförändrade CLI-binärfilen, åttatimmarsfönstret och tokenfelet. npm-registrets tidsstämplar för 2.3.0 och 2.4.0 matchar rådgivningens tider. Arkivet bedömer posten som kritisk, med konfidens A, med dokumenterad verklig skada och ingen tvistflagga.

• Tillskrivet, inte fastställt. Vem som publicerade 2.3.0 är fortfarande en öppen tillskrivning. Den forensiska rapport som publicerades av Michael Bargury och ett automatiskt utredningsverktyg som heter Raptor den 19 februari namnger ett GitHub-konto, glthub-actions, och rapporterar med hög tillförlitlighet att detta konto skapade en fork av cline/cline, öppnade issue 8904 den 28 januari 2026 kl. 03:51 UTC med den injicerade titeln och använde en commit från en fork för att köra en payload från en gist. Khan bekräftade att kontona gcbrun och Dev11940518 är hans egna och att glthub-actions inte är det. Kontot var redan raderat eller avstängt när rapporten publicerades, och Cline har inte namngett någon. Behandla identiteten som ett tredjepartsfynd.

• Omstritt till sin karaktär, inte i sak. Bargury bedömer att episoden stämmer överens med en säkerhetsforskningsdemonstration snarare än en illvillig kampanj, och hänvisar till den godartade nyttolasten och aktörens historik mot ett automatiseringsarkiv för New Relic. Cline kallar det en obehörig publicering, och Khan skriver att aktören som publicerade 2.3.0 "förmodligen" är densamma som förgiftade cacharna. Ingen har visat uppsåt att orsaka skada, och ingen har visat att det inte fanns något.

• Ouppklarat. Khans egen notering före publicering är noggrann kring en punkt som senare rapportering ibland förenklar: mellan 31 januari och 3 februari 2026 misslyckades flera nattliga körningar med ett Post Checkout-steg som inte gav någon utdata, vilket är Cacheracts kompromissindikator, och triage-arbetsflödet är den mest uppenbara vägen men det är inte bevisat att det var ingångspunkten för den aktiviteten. Inte heller har någon part publicerat bevis för att Marketplace- eller OpenVSX-token användes; den enda artefakt någon har lagt fram är npm-bygget.

Vad förändrades efteråt

Åtgärderna landade på flera lager samtidigt, och det är värt att namnge vart och ett eftersom de svarar mot olika delar av felet. Det arbetsflöde som en utomstående kunde nå raderades i stället för att begränsas. Cachning togs bort från de fyra releasearbetsflöden som innehåller publiceringshemligheter, i stället för från hela arkivet, vilket är ändringen som bryter pivoten. Autentiseringsuppgifter roterades, och efter korrigeringen den 17 februari återkallades den korrekta npm-tokenen. Cline:s säkerhetsrådgivning anger att npm-publicering nu använder OIDC-proveniens via GitHub Actions, och StepSecuritys metadataanalys visar varför det spelade roll: de legitima utgåvorna hade redan proveniensattesteringar, och 2.3.0 var avvikelsen som publicerats av ett mänskligt konto. Luckan var att sökvägen med långlivad token förblev öppen vid sidan av trusted publishing, vilket är just det som Endor Labs hävdar att underhållare bör stänga. Cline publicerade GHSA-9ppg-jx86-fqw7, deprekerade 2.3.0 med meddelandet att den inte bör installeras och hänvisade användare till 2.4.0 eller senare.

Khans strukturella rekommendationer går längre än vad som implementerades, och är värda att dokumentera som hans, inte som Clines: ta bort Bash, Write och Edit från alla triage-arbetsflöden och lämna kvar endast filäsningar och de specifika GitHub CLI-anrop som det behöver; återställ aldrig en cache i ett jobb som innehåller hemligheter för produktionspublicering; och ge nattliga releaser sin egen registry-namnrymd och en dedikerad publiceringsidentitet för icke-produktion, så att en stulen nattlig token inte alls kan publicera en stabil release.

Glappet på åtta dagar mellan rättningen och den skadliga publiceringen är detaljen som gör att det här ärendet är värt att bevara. Varje steg i kedjan var en känd teknik; Khan hade publicerat cache-förgiftningsverktyget, och Aikido Securitys PromptPwnd-forskning från december 2025 dokumenterade samma mönster för triagefelkonfiguration. Det som fogade samman dem till en incident i leveranskedjan var ett arbetsflöde som lät en utomståendes text nå ett skal, en cache som delades med jobb som hade release-nycklar, och en tokenrotation som missade en autentiseringsuppgift. Var och en av de tre rättningarna skulle ha brutit kedjan på egen hand; den tredje kom åtta dagar för sent.