ChainDrop: giltig proveniens i 400+ npm-paket, och Claude Code-hooks som inte kräver npm-installation

Den 4 augusti 2026 övertog angripare GitHub-kontot bakom keyv, ett cachelagringsbibliotek som Elastic Security Labs säger laddades ned mer än 600 miljoner gånger föregående månad. Både Wiz Research och Orca Security uppger att skadliga filer pushades direkt till keyv:s huvudgren, och att projektets eget GitHub Actions-arbetsflöde sedan byggde och publicerade den förgiftade utgåvan – så att den nådde npm med giltig proveniens, den attestering som verktygen för leveranskedjan använder för att avgöra att ett paket är pålitligt. En självförökande mask som forskare kallar ChainDrop använde sedan stulna npm-token för att upprepa tricket på andra underhållares paket: Elastic räknade mer än 400 unika paket senast den 6 augusti, Microsoft Threat Intelligence beskrev samma kampanj den 4 augusti, och Singapores Cyber Security Agency räknade över 1 300 komprometterade paketversioner med sammanlagt 2 miljarder nedladdningar per månad. Både Elastic och Microsoft beskriver hooks som körs igen när ett repository öppnas i Claude Code eller Visual Studio Code. Postens fullständiga källförteckning, allvarlighetsgrad och bedömning av tillförlitlighet finns i AI-incidentarkivet, tillsammans med de andra poster om leveranskedjor för npm och utvecklarverktyg som arkiverats i anslutning till den.

Hur en legitim utgivningspipeline signerade sin egen kompromiss

Wiz Research rekonstruerar de första minuterna: från 09:00 UTC den 4 augusti använde angriparen en komprometterad identitet för att införa IDE-persistensnyttolaster i keyv-repositoriet och publicerade sedan, strax därefter, en ny version av keyv som innehöll nyttolasten. Wiz namnger den komprometterade parten som ett GitHub-underhållarkonto och säger att flera paket i keyv- och cacheable-ekosystemet följde.

Orca Securitys snabba responsrapport är mer specifik om signeringsvägen. Angriparen, enligt den, skickade två skadliga filer — setup.mjs och Math_Symbol.js — direkt till huvudgrenen och skapade omedelbart nya utgåvor. Eftersom dessa utgåvor byggdes genom det komprometterade kontots GitHub Actions-arbetsflöden, publicerades de förgiftade versionerna till npm med giltiga härkomstsignaturer, vilket kringgick standardkontroller för integritet i leveranskedjan. Zscaler ThreatLabz, ett oberoende forskarlag som inte är bland postens citerade källor, når samma slutsats och anger en nivå för det: den skadliga keyv 6.0.0 hade giltig SLSA Build Level 3-härkomst eftersom angriparen kontrollerade källarkivet. BleepingComputer, som rapporterade kampanjen samma dag, noterar samma mekanism — skadliga filer skickades direkt till projektens huvudgrenar, nya utgåvor genererades, giltig härkomst eftersom byggena kördes genom legitima GitHub Actions-arbetsflöden.

Microsofts analys tillför en detalj som ser ut som en motsägelse men inte är det. Under maskens spridningsfas fann Microsoft Threat Intelligence att många skadliga versioner hade ingen motsvarande källkodskommit, pull request, tagg eller legitim release, vilket tydde på att angriparna ändrade och publicerade paket-tarballar direkt i stället för att kompromettera varje offentligt källkodsarkiv. Sammantaget beskriver källorna två signeringsregimer inom en och samma kampanj: de första keyv-utgivningarna gick genom offrets riktiga CI-pipeline och bär attesteringar som intygar detta, medan maskens senare utgåvor till stor del sattes samman och publicerades med stulna registertoken, vilket lämnade inget källspår alls. Microsofts egen observation är att mönstret med direktpublicerade tarballar förklarar varför skadliga utgåvor ofta dök upp som en vanlig ökning av patchversionen utan motsvarande källkodskommit eller pull requests.

Den obehagliga lärdomen formuleras rakt ut av Zscaler: proveniens validerar byggprocessen, inte identiteten hos kontot eller integriteten hos det CI-system som kör den. Man medger också en lucka som är viktig för den som ska rekonstruera incidenten – den exakta mekanism för kontokapning som angriparen använde var okänd vid tidpunkten för analysen.

Vad som körs vid npm install: preinstall, Bun 1.3.13 och en insamlare med 300 mönster

Elastic Security Labs beskriver utlösaren som en preinstall-hook i package.json, som missbrukar en legitim npm-funktion som kör godtyckliga kommandon innan ett paket slutför installationen, utan att kräva ytterligare interaktion från offret. Hooken startar setup.mjs, som kontrollerar om Bun JavaScript-körningsmiljön redan finns. Om den inte finns, identifierar droppern maskinens plattform och arkitektur, laddar ner Bun v1.3.13 från den officiella releasesidan, extraherar den, använder den för att köra nyttolasten och raderar sedan den tillfälliga katalogen för att täcka sina spår. Wiz identifierade oberoende användaragenten Bun/1.3.13 som utförde de skadliga anropen. Droppern är plattformsoberoende och riktar sig mot Linux, macOS och Windows.

Nyttolasten är kraftigt obfuskerad, och källorna skiljer sig något åt gällande dess storlek: Elastic anger den till 711 kilobyte, Orca Security anger den till 728 KB. Den använder kontrollflödesplattning och ett Base91-strängkodningsschema och innehåller Dune-tematiska strängar – laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator – vilka Elastic noterar har likheter med tidigare Shai-Hulud-kampanjer.

Microsofts beteendebeskrivning tillför två detaljer som är värda att känna till. Nyttolasten kontrollerar först sin miljö och avslutar sin körning på ryskspråkiga system, undviker dubbla instanser och startar en frikopplad bakgrundskopia på utvecklarnas arbetsstationer; i CI förblir den kopplad till det aktiva jobbet så att den kan nå arbetsflödeshemligheter, runner-autentiseringsuppgifter och publiceringsbehörigheter för OpenID Connect.

Insamlaren är där incidenten blir en historia om AI-verktyg snarare än en allmän historia om inloggningsuppgifter. Elastic säger att den skannar över 300 unika mönster i autentiseringslagringar på en utvecklarmaskin, och att den anmärkningsvärda målinriktningen är riktad mot autentiseringsuppgifter för AI-verktyg: Anthropic, Claude, Codex, Cursor, OpenAI och Gemini. Den samlar även in inloggningsuppgifter för AWS, GCP, Azure och Alibaba Cloud, personliga åtkomsttoken för GitHub, JWT- och sessionstoken, HashiCorp Vault-token, privata SSH-nycklar, Kubernetes-tjänstekontotoken och npm-token. Wiz rapporterar att mållistan hade utökats med nästan 70 % jämfört med den tidigare Mini Shai-Hulud-koden som den bygger på, med nya tillägg, bland annat autentiseringslagringar för AI-agenter för Claude, OpenAI, Codex, Cursor och Gemini, kryptovalutanyckelarkiv för Foundry, Solana och Monero, Jenkins master.key, Argo CD- och Harbor-hemligheter, Alibaba- och Tencent-CLI-konfigurationer, och /etc/shadow.

Både Microsoft och Elastic beskriver samma exfiltreringsdesign. Resultaten serialiseras som JSON, gzip-komprimeras och krypteras med en slumpmässigt genererad AES-256-GCM-nyckel, och den nyckeln lindas in med angriparens publika RSA-nyckel. Nyttolasten hårdkodar inte sin command-and-control-domän: Elastic uppger att den frågar ett Ethereum-smartkontrakt på 0xE1f2395ee43e45A1556EC6438a88c31B83493103 för att hämta den aktuella slutpunkten vid körning, så infrastrukturen kan roteras utan att röra malprogramvaran. Om det misslyckas letar den efter en kryptografiskt signerad markör – thebeautifulmarchoftime – i GitHubs commit-historik och validerar domänen mot en inbäddad RSA-nyckel. Om båda misslyckas exfiltrerar den via ett offentligt GitHub-repository som offrets eget konto skapar, beskrivet som "Shai-Hulud: Here We Go Again". Microsoft noterar att en reservväg kodar en stulen GitHub-token med dubbel Base64 i stället för att kryptera den.

Spridningen är villkorad av tokenkvaliteten. Elastic rapporterar att masken endast aktiveras när genomsökningen av autentiseringsuppgifter hittar en npm-token med skrivbehörighet för paket och möjligheten att publicera utan tvåfaktorsautentisering; den laddar sedan ned den senaste tarballen för varje skrivbart paket, injicerar sig själv, höjer patchversionen och publicerar på nytt. BleepingComputer tillägger att varje token valideras i realtid mot registrets whoami-endpoint innan den stjäls. Den rutinen är det som förvandlade en komprometterad identitet till hundratals utgivningar, och det är därför de skadliga versionerna ser ut som vanliga patchuppdateringar.

Infektionsvägen som inte kräver npm install

Det som skiljer den här kampanjen från tidigare npm-maskar är att installation inte längre är den enda vägen in. Elastic beskriver två ytterligare exekveringsvägar som riktar sig till användare av AI-kodverktyg. En SessionStart-hook i .claude/settings.json kör node .claude/setup.mjs när en ny Claude-session startar. För VS Code gäller att en folderOpen-uppgift i .vscode/tasks.json kör node .vscode/setup.mjs när ett infekterat repository öppnas. Microsofts analys listar samma fyra artefakter – .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json och .vscode/setup.mjs – och beskriver dem som en sekundär infektionsväg som kan starta nyttolasten igen efter att den ursprungliga npm-installationen har slutförts.

Villkoret som vidgar detta dramatiskt ligger i de stulna inloggningsuppgifterna. När en GitHub App-token finns bland dem, rapporterar Elastic att masken committar de skadliga hooks till upp till 50 grenar per tillgängligt repo, och injicerar .claude/settings.json och .vscode/tasks.json i var och en. Elastics slutsats är att en utvecklare som klonar en av dessa grenar och öppnar den kan bli infekterad genom att öppna projektet – ingen paketinstallation, och därför inget skydd mot installationsskript, finns i kedjan alls.

Zscalers bedömning är att persistenshakkarna överlever att paketet borttagits och körs igen helt enkelt genom att projektet öppnas i VS Code eller Claude Code, vilket kringgår --ignore-scripts-åtgärden som många team infört efter tidigare npm-maskar. Rekommendationen följer direkt: behandla konfigurationsfiler för IDE och AI-agenter – .claude/, .cursor/, .vscode/, .gemini/ – som körbar kod, granskad med samma noggrannhet som källkod.

Det finns ett fingeravtryck för repository-delen av attacken. Elastic rapporterar att maskgenererade commits kan identifieras genom författarnamnet claude och commit-meddelandet chore: update config, och Wiz registrerar samma meddelandesträng. Elastic tillägger att commit-meddelandet också innehöll den stulna GitHub-tokenen tillsammans med en skrämselsträng — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — vilket de tolkar som ett försök att skrämma utvecklare från att återkalla tokenen. Wiz registrerar samma sträng i de initiala commitsen, med det kortare meddelandet insatt i de commits som introducerar IDE-hookarna.

Antalen stämmer inte överens, och det är inte en motsägelse.

Varje publicerad siffra för påverkansradien är knuten till en annan enhet, och enheterna går inte att utbyta. Elastic Security Labs räknade i en text den 6 augusti över 400 unika npm-paket som komprometterade. Microsoft Threat Intelligence beskrev fler än 400 paket hos flera oberoende utgivare. Aikido, som citeras av BleepingComputer, angav den siffran till minst 868 paket över 1 381 versioner. Orca Security rapporterar 10 direkt förgiftade keyv- och cacheable-paket med över 619 miljoner månatliga nedladdningar, och därefter 868 ytterligare paket och 1 381 versioner som masken nådde, för mer än 2 miljarder månatliga installationer. Singapores CSA-rådgivning AD-2026-009, daterad den 6 augusti, redovisar över 1 300 komprometterade paketversioner som representerar sammanlagt 2 miljarder månatliga nedladdningar.

Det är tre olika nämnare – paket, paketversioner och månatlig nedladdningsvolym – hämtade vid tre olika tidpunkter i en kampanj som fortfarande pågick. Zscalers redogörelse för hastigheten förklarar varför de skiljer sig: den säger att masken spred sig själv till fler än 400 paket på under fyra timmar och som mest publicerade ungefär ett infekterat paket per sekund. Att betrakta en senare siffra som en rättelse av en tidigare skulle vara fel; var och en är en ögonblicksbild, och ingen av de citerade källorna hävdar någon slutlig totalsiffra.

Elastics exponeringssiffror på biblioteksnivå är de som oftast citeras och de minst tvetydiga. Man rapporterar att keyv ensamt hade över 600 miljoner nedladdningar föregående månad, med flat-cache nära 580 miljoner, cacheable-request över 137 miljoner, cacheable över 30 miljoner och cache-manager över 16 miljoner. CSA:s rådgivning listar de specifika komprometterade versionerna, bland dem keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 och ecto 5.0.1.

Återkallelsefällan

Incidentresponders som installerade en drabbad version står inför ett andra problem efter det första. Elastic rapporterar att nyttolasten i en villkorad reservväg i GitHub försöker installera en komponent för tokenövervakning som upprätthåller åtkomst till autentiseringsuppgifter och innehåller en destruktiv hanterare om den övervakade token återkallas. Zscaler beskriver mekanismen i operativ detalj och kallar den för en tokenåterkallningsfälla: masken installerar en bakgrundsprocess som var 60:e sekund pollar GitHub-API:et med den stulna token, och om token returnerar ett 4xx-fel – vilket innebär att offret har återkallat den – utlöses en sekundär destruktiv nyttolast, som beroende på variant kan omfatta fjärrkodkörning eller borttagning av användarens hemkatalog.

Wiz tillägger att dödmansbrytaren är selektivt aktiverad baserat på ett svar från kommando- och kontrollservern: operatören kan returnera ett värde som anger vilket kommando som ska aktiveras och vilken token brytaren ska övervaka för återkallelse. Wiz noterar också att övervakaren letar efter ett giltigt svar från användarens slutpunkt, så alla token-typer som är giltiga där kan fungera som utlösare.

Det praktiska utfallet dokumenteras av BleepingComputer och av Aikidos vägledning som den citerar: en utvecklararbetsstation eller CI/CD-runner som installerade en påverkad version bör betraktas som komprometterad även om paketet senare togs bort, eftersom körning i det andra steget kan ha exponerat tokens och underminerat byggintegriteten. Microsofts vägledning kommer fram till samma slutsats från byggsidan och varnar för att organisationer som installerade ett påverkat paket med livscykelskript aktiverade bör betrakta arbetsstationen eller byggrunnern som potentiellt komprometterad och bygga om påverkade system och nedströmsartefakter från betrodda källor.

Vad som är fastställt, vad som bedöms och vad ingen har visat

Primärhandlingen och fem oberoende analyser pekar samstämmigt på mekaniken, och de mekaniska påståendena är den starkaste delen av filen.

• GitHub-kontot för keyv-underhållaren komprometterades, och skadliga filer pushades direkt till main innan en version publicerades, den 4 augusti 2026 – vilket rapporterades samstämmigt av Wiz, Orca Security, BleepingComputer och CSA Singapore.

• Åtminstone keyv 6.0.0 nådde npm via offrets egen CI-pipeline med giltig provenance, där Zscaler anger en SLSA Build Level 3-attestering. Detta är påståendet som gör incidenten anmärkningsvärd, och det stöds av tre organisationer som inte var medförfattare till varandras arbete.

En preinstall-hook körde setup.mjs, som laddade ner Bun v1.3.13 och körde en obfuskerad nyttolast som skannade igenom över 300 autentiseringsmönster, inklusive autentiseringsuppgifter för AI-kodverktyg – Elastic och Wiz stämmer överens om både runtime-versionen och listan över AI-riktade autentiseringsuppgifter.

• Hooks som skrivs till .claude/settings.json och .vscode/tasks.json körs vid sessionsstart och när mappen öppnas, och en GitHub App-token utökade detta till upp till 50 grenar per tillgängligt repo – Elastics upptäckt, och grunden för dess påstående att en utvecklare kan bli infekterad genom att öppna ett repo.

• Mer än 400 unika paket komprometterades inom loppet av några dagar, och CSA Singapore, en nationell tillsynsmyndighet, publicerade rådgivningsmeddelandet AD-2026-009 den 6 augusti 2026 med en förteckning över drabbade versioner och indikatorer.

Det som källorna behandlar som bedömning snarare än faktum bör märkas. Wiz beskriver nyttolasten som en ättling till skadlig kodfamiljen "Mini" Shai-Hulud, byggd på offentliga Shai-Hulud-Open-Source-förråd som publicerats av TeamPCP, med några avgörande ändringar; Orca Security attribuerar attacken till TeamPCP; Zscaler kopplar ChainDrop till TeamPCP och placerar det i en härstamningslinje som löper från september 2025. Det är ett leverantörskonsensus om attribuering, inte något som ett citerat primärdokument bevisar om en namngiven individ eller grupp.

Tre saker som ingen citerad källa fastställer, och som den här artikeln inte fyller i. För det första, hur maintainer-kontot övertogs: Zscaler anger uttryckligen att den exakta mekanismen var okänd vid tiden för analysen. För det andra, en enda slutlig summa: siffrorna 400, 868 och 1 300 räknar paket, paket-och-versioner respektive versioner vid olika tidpunkter, och ingen källa hävdar att kampanjen är avslutad. För det tredje, och viktigast för det AI-specifika påståendet i den här posten, rapporterar ingen citerad källa en bekräftad förekomst av att en stulen autentiseringsuppgift för Anthropic, Codex, Cursor, Gemini eller OpenAI har återuppspelats mot ett leverantörskonto. Det som är dokumenterat är avsikt och förmåga – en uttrycklig mållista och en insamlare byggd för att nå den – inte ett påvisat nedströmsintrång i en AI-leverantörs system.

Vad som förändrades efter — och vad en förstainsatsare måste göra

Det mest konkreta botemedlet i protokollet är en plattformsändring. Elastic rekommenderar att uppgradera till npm 12 eller senare, vilket blockerar preinstall-krokar som standard; Microsofts vägledning rekommenderar oberoende av detta npm CLI v12 och funktionen min-release-age, som håller tillbaka nya versioner länge nog för att communityn ska hinna upptäcka en kompromiss innan den når en byggnad.

Utöver det överlappar de åtgärdssteg som källorna publicerar varandra i hög grad.

• Elastic: återkalla alla GitHub-token, inklusive sessionstoken, på drabbade maskiner; återkalla och återskapa npm-token, särskilt automationstoken med skrivbehörighet och tvåfaktorsbypass; sök igenom repositorier efter obehöriga commits med meddelandet chore: update config from claude@users.noreply.github.com; rotera hemligheter för moln, Kubernetes, Vault, AI-verktyg och CI/CD; aktivera tvåfaktorsautentisering på npm-konton.

• Microsoft: rensa npm- och yarn-cachar på drabbade slutpunkter och byggvärdar, lås till kända fungerande versioner, granska låsningsfiler och artefakter för de komprometterade versionerna inklusive transitiva referenser, bygg om delade basavbildningar och golden build-runners, och granska tokenomfång, godkännanden av arbetsflöden och härkomst för releaser eftersom incidenten stämmer överens med missbruk av CI/CD-pipeline via OIDC-publicering.

• CSA Singapore: ta bort påverkade versioner från utvecklings-, bygg- och CI/CD-miljöer, behandla påverkade system som komprometterade och bygg om dem, rotera autentiseringsuppgifter, granska moln- och källkodsmiljöer för obehörig åtkomst, övervaka publicerade indikatorer och förstärk tillåtelselistor, integritetsverifiering och provenienskontroller.

• Zscaler: behandla .claude/, .cursor/, .vscode/ och .gemini/ som körbar kod, och sluta behandla SLSA- eller Sigstore-proveniens som bevis på säkerhet — kombinera det i stället med avvikelsedetektering av publiceringsbeteende, såsom publicering utanför kontorstid, masspublicering av versioner och förstagångspublicerare.

Underlaget innehåller inget åtgärdsutfall. Ingen av de citerade källorna rapporterar att de skadliga versionerna helt avlägsnats, någon återställning av konton, ett gripande eller en tillsynsåtgärd; CSAs rådgivning är ett meddelande till försvarare, inte ett konstaterande riktat mot en part.

Det incidenten förändrar är en klassificering. En konfigurationsfil för utvecklarverktyg är en exekveringsväg, och en editor som öppnar en mapp är en exekveringshändelse. Och en provenance-attestering är ett påstående om vilken pipeline som producerade ett paket — inte om vem som höll nycklarna när pipelinen kördes, vilket är precis den lucka som den första keyv-utgåvan föll igenom.