ChainDrop: Malware napadl stovky npm balíčků a kradl vývojářské přístupy

Bezpečnostní výzkumníci odhalili 4. srpna rozsáhlý útok na softwarový dodavatelský řetězec. Malware označovaný jako ChainDrop se podle analýzy společnosti StepSecurity objevil nejméně ve 444 npm balíčcích napříč 2 212 verzemi.

Tento údaj odpovídá stavu vyšetřování k 4. srpnu 2026 v 18:10 UTC. Microsoft ve své samostatné analýze potvrdil kompromitaci více než 400 balíčků od několika vzájemně nesouvisejících vydavatelů.

Mezi první zasažené projekty patřily velmi rozšířené knihovny keyv, flat-cache, file-entry-cache, cacheable-request, cacheable nebo cache-manager. Jen tři nejstahovanější kompromitované balíčky podle StepSecurity dohromady dosahovaly přibližně 450 milionů stažení týdně.

Poznámka: Tento údaj neznamená 450 milionů potvrzených infekcí. Popisuje běžnou popularitu dotčených knihoven a jejich statistiky se mohou překrývat.

První škodlivá verze měla platné potvrzení původu

Jednou z prvních významných kompromitovaných verzí se stal balíček keyv@6.0.0, publikovaný 4. srpna přibližně v 09:35 UTC. Keyv nabízí jednotné rozhraní pro ukládání dat do různých databází a dalších úložišť a v době incidentu vykazoval více než 150 milionů stažení týdně.

Podle analýzy společnosti StepSecurity vznikla škodlivá verze prostřednictvím skutečného publikačního workflow projektu v GitHub Actions. Balíček proto získal také platné potvrzení původu vytvořené pomocí npm Trusted Publishing.

Potvrzení správně dokazovalo, že vydání pochází z konkrétního repozitáře a automatizovaného workflow. Nedokázalo ale určit, zda změny v repozitáři nebo spuštění publikačního procesu skutečně provedl oprávněný správce.

Microsoft uvádí, že dostupné důkazy obecně ukazují na zneužití odcizených přístupových údajů vydavatelů. U pozdějších škodlivých vydání ale často neexistoval odpovídající commit, pull request ani release tag. To naznačuje, že útočníci v mnoha případech stáhli existující npm balíček, upravili jeho archiv a novou verzi publikovali přímo pomocí odcizeného oprávnění.

Malware se spustil ještě před dokončením instalace

Kompromitované balíčky obsahovaly soubor setup.mjs a rozsáhlý obfuskovaný JavaScriptový payload. Ten se podle konkrétní varianty objevoval například pod názvy Math_Symbol.js, math_init.js nebo jinými podobnými názvy.

Do souboru package.json útočníci přidali příkaz:

"preinstall": "node setup.mjs"

Takzvaný preinstall skript se v npm spouští automaticky před dokončením instalace balíčku. Uživatel proto nemusel škodlivou knihovnu ve své aplikaci přímo použít. Pokud instalace povolovala npm lifecycle skripty, payload se mohl spustit už během příkazu npm install nebo automatizovaného sestavení projektu.

První fáze ověřila, zda je v systému dostupný JavaScriptový runtime Bun. Pokud nebyl nainstalovaný, stáhla jeho legitimní verzi z oficiálního repozitáře projektu na GitHubu. Prostřednictvím Bunu následně spustila hlavní škodlivý kód.

Použití legitimního nástroje pomáhalo útoku splynout s běžnou komunikací vývojářského prostředí. Samotné stažení Bunu z GitHubu proto nemuselo v bezpečnostních nástrojích působit jako jednoznačný indikátor útoku.

Cílem byly npm tokeny, cloudové klíče i CI/CD secrety

ChainDrop byl navržen především pro krádeže přístupových údajů z vývojářských stanic a automatizovaných buildovacích prostředí.

Microsoft Threat Intelligence uvádí, že malware hledal přihlašovací údaje v lokálních souborech, proměnných prostředí, historii příkazové řádky, konfiguracích cloudových nástrojů i paměti GitHub Actions runnerů.

Mezi jeho cíle patřily například:

• npm publikační tokeny,
• GitHub tokeny,
• SSH klíče,
• přístupové údaje ke cloudovým službám,
• Kubernetes konfigurace a tokeny,
• hodnoty dostupné prostřednictvím AWS,
• přístupy k HashiCorp Vaultu,
• workflow secrety a proměnné prostředí,
• další soubory s citlivými údaji ve vývojářském systému.

Malware se s nalezenými identitami pokoušel přihlašovat k npm, GitHubu, Amazon Web Services, Kubernetes a HashiCorp Vaultu. Následně zjišťoval, k jakým balíčkům, repozitářům, cloudovým parametrům nebo uloženým tajným hodnotám má kompromitovaná identita přístup.

Shromážděná data šifroval a odesílal na HTTPS infrastrukturu ovládanou útočníkem. Jako záložní exfiltrační kanál mohl využít také nově vytvořené repozitáře na GitHubu.

Ethereum pomáhalo malwaru hledat řídicí server

StepSecurity při analýze zaznamenal, že payload komunikoval s veřejnými Ethereum RPC službami. Prostřednictvím chytrého kontraktu získával aktuální seznam řídicích serverů.

Tato technika bývá označována jako EtherHiding. Útočník díky ní nemusí mít adresu řídicí infrastruktury pevně zapsanou ve škodlivém kódu. Informaci může změnit v blockchainovém kontraktu, zatímco již publikované balíčky začnou automaticky používat nový server.

Mezi potvrzené indikátory kompromitace patří například:

• npm-cache[.]com
• pypi-get[.]com
• js-mirror[.]com

Samotná komunikace s veřejnými Ethereum RPC službami ale není důkazem kompromitace. Jde o legitimní infrastrukturu, kterou mohou používat také běžné aplikace.

Ukradené oprávnění vytvořilo další škodlivé verze

Nejnebezpečnější schopností kampaně bylo automatické šíření.

Pokud malware získal npm token s právem publikovat nové verze, zjistil, ke kterým balíčkům má kompromitovaná identita přístup. Poté stáhl jejich nejnovější archivy, přidal vlastní payload, loader a preinstall skript, zvýšil číslo opravné verze a upravené balíčky znovu publikoval.

K útoku tak nebylo nutné samostatně prolomit každý projekt. Jedna kompromitovaná identita mohla umožnit publikování škodlivých aktualizací do všech balíčků, ke kterým měla oprávnění.

Nově infikované balíčky následně mohli stáhnout další vývojáři nebo buildovací systémy. Pokud i jejich prostředí obsahovala použitelné npm tokeny, mohl se celý proces zopakovat.

Právě tento mechanismus umožnil rozšíření ze známých knihoven Keyv a Cacheable do stovek balíčků od dalších vydavatelů.

Útok se dokázal vrátit přes VS Code a Claude Code

ChainDrop se nespoléhal pouze na instalaci prostřednictvím npm. Pomocí odcizených GitHub přístupů mohl do repozitářů vkládat také konfigurace pro Visual Studio Code a Claude Code.

Mezi pozorované soubory patřily například:

• .vscode/tasks.json
• .vscode/setup.mjs
• .claude/settings.json
• .claude/setup.mjs

Konfigurace mohly spustit škodlivý kód při otevření projektu ve Visual Studio Code nebo při zahájení relace v Claude Code. V takovém případě už nemusel být potřeba další příkaz npm install.

Repozitář se tím mohl změnit v další zdroj nákazy. Vývojář mohl stáhnout zdrojový kód, otevřít ho v podporovaném prostředí a nevědomky znovu spustit payload.

Microsoft zároveň upozorňuje na podmíněný mechanismus, který se pokoušel sledovat platnost některých tokenů a obsahoval destruktivní reakci na jejich zneplatnění. Rotace přístupů proto musí být součástí širšího vyčištění napadeného prostředí, nikoliv jediným krokem reakce.

Stovky balíčků, nikoliv 1 300

Rozsah kampaně se během prvních hodin rychle měnil. Jednotlivé bezpečnostní společnosti proto zveřejňovaly rozdílná čísla podle času své analýzy a způsobu počítání.

StepSecurity k 4. srpnu 2026 v 18:10 UTC uváděl:

• 444 unikátních npm balíčků
• 2 212 kompromitovaných verzí
• více než tucet zasažených organizací nebo vydavatelských účtů

Microsoft nezveřejnil přesný součet, ale potvrdil kompromitaci více než 400 balíčků.

Tvrzení, že útok zasáhl přes 1 300 unikátních balíčků, proto dostupné primární zdroje v době publikace nepotvrzují. Vyšší čísla pravděpodobně vznikla záměnou za počet kompromitovaných verzí.

Stejně opatrně je nutné pracovat se statistikami stažení. Ty popisují popularitu knihoven, nikoliv počet skutečně napadených počítačů nebo organizací.

Lockfile pomáhá, ale nemusí zachytit každý build

Organizace používající Node.js by měly prověřit především instalace, aktualizace a buildy uskutečněné 4. srpna 2026.

Kontrola se musí týkat nejen přímo uvedených závislostí, ale také tranzitivních knihoven, které do projektu přidávají jiné balíčky.

Doporučený postup:

1. Zkontrolovat dependency stromy a lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) proti aktuálním seznamům kompromitovaných kombinací balíčku a verze.
2. Prověřit historii CI/CD běhů a vývojářských instalací provedených během incidentu.
3. Vyhledat soubory setup.mjs, Math_Symbol.js, math_init.js a další neočekávané preinstall skripty.
4. Prověřit změny ve složkách .claude, .vscode a .github, včetně workflow souborů.
5. Zkontrolovat síťovou komunikaci s publikovanými indikátory kompromitace.
6. Prověřit auditní logy npm, GitHubu i cloudových služeb kvůli neautorizovaným přístupům.
7. Vyčistit npm a Yarn cache na potenciálně zasažených stanicích a buildovacích systémech.
8. Prověřit také sdílené CI cache, základní obrazy a předpřipravené build runnery.

Lockfile výrazně snižuje riziko nečekaného stažení nové verze. Není ale absolutní ochranou.

StepSecurity například zaznamenal skutečné spuštění malwaru v CI projektu Backstage. Jeho end-to-end testy vytvářely novou aplikaci a instalovaly čerstvé verze závislostí mimo hlavní lockfile repozitáře. Škodlivá tranzitivní závislost se proto mohla stáhnout, aniž by se změnil uložený lockfile projektu.

Downgrade odstraní balíček, ale nevrátí odcizené přístupy

Pokud byla některá kompromitovaná verze nainstalována se zapnutými lifecycle skripty, doporučuje Microsoft považovat příslušnou vývojářskou stanici nebo CI/CD runner za potenciálně kompromitovaný.

Pouhé odstranění balíčku nebo návrat ke starší verzi nestačí. Malware mohl před odinstalováním získat tokeny, klíče a další přístupy nebo změnit konfiguraci repozitářů a vývojářských nástrojů.

Z bezpečného a prověřeného systému je proto potřeba:

• zneplatnit a vyměnit npm publikační oprávnění,
• rotovat GitHub tokeny a podle situace také SSH klíče,
• vyměnit cloudové a Kubernetes přístupy,
• rotovat CI/CD secrety a citlivé proměnné prostředí,
• prověřit přístupy k HashiCorp Vaultu a dalším úložištím tajných hodnot,
• obnovit nebo znovu sestavit potenciálně napadené pracovní stanice a build runnery,
• znovu vytvořit artefakty sestavené v nedůvěryhodném prostředí,
• ověřit, že škodlivé archivy nezůstaly ve sdílených cache nebo interních repozitářích.

Rotace přístupových údajů by měla proběhnout až z důvěryhodného systému. Jinak může malware nově vytvořené hodnoty znovu odcizit.

Českých týmů se kampaň týká i bez přímého zacílení

Dosavadní analýzy neuvádějí, že by ChainDrop cíleně útočil na české organizace. Riziko ale není omezené na konkrétní stát ani odvětví.

npm je běžnou součástí vývoje webových aplikací, e-shopů, SaaS služeb i interních podnikových systémů. Ohrožené proto mohou být také české firmy, které některou ze škodlivých verzí stáhly přímo nebo prostřednictvím tranzitivní závislosti.

Nejvyšší riziko představují prostředí, ve kterých instalace probíhala současně s dostupnými publikačními, cloudovými nebo CI/CD oprávněními.

V takovém případě se incident nemusí omezovat na jedno zařízení. Odcizené přístupy mohly útočníkům umožnit zasáhnout další balíčky, repozitáře, buildovací procesy i cloudová prostředí.

Zdroje

• StepSecurity – ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2
• Microsoft Threat Intelligence – ChainDrop Supply Chain Compromise
• Aikido Security – Keyv and Friends Compromised in npm Supply Chain Attack
• Wiz Research – Keyv and Cacheable npm Supply Chain Attack