ChainDrop: prawidłowe pochodzenie w ponad 400 pakietach npm oraz hooki Claude Code, które nie wymagają npm install

Dnia 4 sierpnia 2026 r. atakujący przejęli konto GitHub stojące za keyv, biblioteką do cachowania, która według Elastic Security Labs została pobrana ponad 600 milionów razy w poprzednim miesiącu. Wiz Research i Orca Security odnotowują, że złośliwe pliki wypchnięto wprost do głównej gałęzi keyv, a własny workflow GitHub Actions projektu zbudował następnie i opublikował zatrutą wersję — trafiła więc do npm z prawidłowym poświadczeniem pochodzenia, poświadczeniem, którego narzędzia łańcucha dostaw używają, aby uznać pakiet za zaufany. Samoreplikujący się robak, który badacze nazywają ChainDrop, użył następnie skradzionych tokenów npm, by powtórzyć ten chwyt na pakietach innych opiekunów: Elastic naliczył ponad 400 różnych pakietów do 6 sierpnia, Microsoft Threat Intelligence opisał tę samą kampanię 4 sierpnia, a Singapurska Agencja Cyberbezpieczeństwa naliczyła ponad 1 300 skompromitowanych wersji pakietów o łącznej liczbie 2 miliardów pobrań miesięcznie. Elastic i Microsoft opisują hooki, które uruchamiają się ponownie, gdy repozytorium zostanie otwarte w Claude Code lub Visual Studio Code. Pełna lista źródeł wpisu, ocena dotkliwości i ocena pewności znajdują się w archiwum incydentów AI, obok innych wpisów dotyczących łańcucha dostaw npm i narzędzi deweloperskich zarejestrowanych w tym samym okresie.

Jak legalny potok wydania podpisał własne skompromitowanie

Wiz Research odtwarza pierwsze minuty: od 09:00 UTC 4 sierpnia atakujący wykorzystał przejętą tożsamość, aby wprowadzić do repozytorium keyv ładunki trwałości w IDE, a następnie wkrótce potem opublikował nową wersję keyv zawierającą ładunek. Wiz podaje, że przejętą stroną jest konto opiekuna GitHub, i twierdzi, że w ślad za tym w ekosystemie keyv i cacheable pojawiło się wiele pakietów.

Analiza Orca Security przygotowana w trybie szybkiego reagowania jest bardziej szczegółowa w kwestii ścieżki podpisywania. Atakujący, jak się twierdzi, wypchnął dwa złośliwe pliki — setup.mjs i Math_Symbol.js — bezpośrednio do gałęzi main i natychmiast wydał nowe wersje. Ponieważ wersje te zbudowano przez workflows GitHub Actions przejętego konta, zatrute wersje opublikowano w npm z ważnymi podpisami poświadczającymi pochodzenie, omijając standardowe kontrole integralności łańcucha dostaw. Zscaler ThreatLabz, niezależny zespół badawczy, którego nie ma wśród źródeł cytowanych w tym opracowaniu, dochodzi do tego samego wniosku i określa jego poziom: złośliwy keyv 6.0.0 miał ważne SLSA Build Level 3 poświadczenie pochodzenia, ponieważ atakujący kontrolował repozytorium źródłowe. BleepingComputer, który relacjonował tę kampanię tego samego dnia, odnotowuje ten sam mechanizm — złośliwe pliki wypchnięte bezpośrednio do gałęzi main projektów, wygenerowane nowe wersje, ważne poświadczenie pochodzenia, ponieważ kompilacje przebiegały przez legalne workflows GitHub Actions.

Analiza Microsoftu dodaje szczegół, który wygląda na sprzeczność, ale nią nie jest. Na etapie rozprzestrzeniania się robaka Microsoft Threat Intelligence ustalił, że wiele złośliwych wersji charakteryzowało się brakiem odpowiadającego commita w kodzie źródłowym, pull requesta, taga lub prawdziwego wydania, co wskazywało, że atakujący modyfikowali i publikowali tarballe pakietów bezpośrednio, zamiast przejmować każde publiczne repozytorium źródłowe. Źródła czytane razem opisują dwa schematy podpisywania w ramach jednej kampanii: pierwsze wydania keyv przeszły przez rzeczywisty potok CI ofiary i niosą poświadczenia, które je potwierdzają, natomiast późniejsze wydania robaka były w dużej mierze składane i publikowane za pomocą skradzionych tokenów rejestru, nie pozostawiając żadnego śladu źródłowego. Obserwacja samego Microsoftu jest taka, że wzorzec bezpośredniego publikowania tarballi wyjaśnia, dlaczego złośliwe wydania często pojawiały się jako zwykłe podbicie wersji poprawkowej bez odpowiadających commitów źródłowych lub pull requestów.

Ta niewygodna lekcja została wprost przedstawiona przez Zscaler: proweniencja potwierdza proces budowania, a nie tożsamość konta ani integralność systemu CI, który go uruchamia. Przyznaje również lukę istotną dla każdego, kto odtwarza incydent — dokładny mechanizm przejęcia konta, którego użył atakujący, był nieznany w chwili przeprowadzania analizy.

Co uruchamia się podczas npm install: preinstall, Bun 1.3.13 i kolektor 300 wzorców

Elastic Security Labs opisuje ten mechanizm wyzwalający jako preinstall hook w pliku package.json, który wykorzystuje legalną funkcję npm polegającą na uruchamianiu dowolnych poleceń przed zakończeniem instalacji pakietu, bez potrzeby dalszej interakcji ze strony ofiary. Ten hook uruchamia setup.mjs, który sprawdza, czy środowisko uruchomieniowe JavaScript Bun jest już obecne. Jeśli nie, dropper wykrywa platformę i architekturę maszyny, pobiera Bun v1.3.13 z oficjalnej strony wydania, rozpakowuje go, używa go do wykonania ładunku, a następnie usuwa katalog tymczasowy, aby zatrzeć ślady. Wiz niezależnie zidentyfikował agenta użytkownika Bun/1.3.13 wykonującego złośliwe wywołania. Dropper jest wieloplatformowy i przeznaczony dla systemów Linux, macOS i Windows.

Payload jest silnie zaciemniony, a źródła nieznacznie różnią się co do jego rozmiaru: Elastic podaje 711 kilobajtów, a Orca Security — 728 KB. Wykorzystuje on spłaszczanie przepływu sterowania oraz schemat kodowania ciągów znaków Base91 i zawiera ciągi o tematyce Dune — laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator — co, jak zauważa Elastic, wykazuje podobieństwa do wcześniejszych kampanii Shai-Hulud.

Analiza behawioralna Microsoftu wnosi dwa szczegóły warte uwagi. Ładunek najpierw sprawdza swoje środowisko i kończy działanie na systemach rosyjskojęzycznych, unika tworzenia zduplikowanych instancji i uruchamia oderwaną kopię działającą w tle na stacjach roboczych deweloperów; w środowisku CI pozostaje dołączony do aktywnego zadania, dzięki czemu może uzyskać dostęp do sekretów przepływu pracy, poświadczeń runnera i uprawnień do publikowania w OpenID Connect.

Kolektor to miejsce, w którym incydent staje się opowieścią o narzędziach AI, a nie ogólną historią o poświadczeniach. Elastic twierdzi, że skanuje ponad 300 unikalnych wzorców w magazynach poświadczeń na maszynie dewelopera, a godne uwagi ukierunkowanie dotyczy poświadczeń narzędzi AI: Anthropic, Claude, Codex, Cursor, OpenAI i Gemini. Pobiera również poświadczenia AWS, GCP, Azure i Alibaba Cloud, osobiste tokeny dostępu GitHub, tokeny JWT i sesji, tokeny HashiCorp Vault, prywatne klucze SSH, tokeny kont usług Kubernetes i tokeny npm. Wiz podaje, że lista celów została rozszerzona o prawie 70% w porównaniu z wcześniejszym kodem Mini Shai-Hulud, na którym się opiera, a nowe dodatki obejmują magazyny poświadczeń agentów AI dla Claude, OpenAI, Codex, Cursor i Gemini, magazyny kluczy kryptowalut dla Foundry, Solana i Monero, master.key Jenkinsa, sekrety Argo CD i Harbor, konfiguracje CLI Alibaba i Tencent oraz /etc/shadow.

Zarówno Microsoft, jak i Elastic opisują ten sam schemat eksfiltracji. Wyniki są serializowane jako JSON, kompresowane gzipem i szyfrowane losowo wygenerowanym kluczem AES-256-GCM, a ten klucz jest opakowany kluczem publicznym RSA atakującego. Ładunek nie zaszywa na stałe swojej domeny dowodzenia i kontroli: Elastic podaje, że odpytuje smart kontrakt Ethereum pod adresem 0xE1f2395ee43e45A1556EC6438a88c31B83493103, aby w czasie działania pobrać bieżący endpoint, dzięki czemu infrastrukturę można rotować bez modyfikowania złośliwego oprogramowania. Jeśli to się nie powiedzie, szuka w historii commitów GitHub kryptograficznie podpisanego znacznika — thebeautifulmarchoftime — i weryfikuje domenę względem wbudowanego klucza RSA. Jeśli oba zawiodą, eksfiltruje dane przez publiczne repozytorium GitHub utworzone przez konto samej ofiary, opisane jako "Shai-Hulud: Here We Go Again". Microsoft zauważa, że jedna ze ścieżek awaryjnych koduje skradziony token GitHub za pomocą podwójnego Base64, zamiast go szyfrować.

Rozprzestrzenianie jest uzależnione od jakości tokenu. Elastic donosi, że robak aktywuje się tylko wtedy, gdy skan poświadczeń znajdzie token npm z uprawnieniem do zapisu pakietów i możliwością publikowania bez uwierzytelniania dwuskładnikowego; następnie pobiera najnowszy tarball każdego pakietu z prawem zapisu, wstrzykuje się do niego, podbija wersję patch i publikuje ponownie. BleepingComputer dodaje, że każdy token jest weryfikowany w czasie rzeczywistym względem punktu końcowego whoami rejestru, zanim zostanie skradziony. Ta procedura sprawiła, że jedna przejęta tożsamość zamieniła się w setki wydań, i dlatego złośliwe wersje wyglądają jak zwykłe podbicia wersji patch.

Ścieżka infekcji, która nie wymaga npm install

Odkrycie, które odróżnia tę kampanię od wcześniejszych robaków npm, polega na tym, że instalacja nie jest już jedyną drogą wejścia. Elastic opisuje dwie dodatkowe ścieżki wykonania skierowane do użytkowników narzędzi AI do kodowania. SessionStart hook w .claude/settings.json uruchamia node .claude/setup.mjs, gdy rozpoczyna się nowa sesja Claude. W przypadku VS Code, folderOpen — zadanie w .vscode/tasks.json uruchamia node .vscode/setup.mjs, gdy otwierane jest zainfekowane repozytorium. Analiza Microsoftu wymienia te same cztery artefakty — .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json i .vscode/setup.mjs — i opisuje je jako wtórną drogę infekcji, która może ponownie uruchomić payload po zakończeniu pierwotnej instalacji npm.

Warunek, który drastycznie poszerza ten zasięg, tkwi w skradzionych poświadczeniach. Gdy token aplikacji GitHub znajduje się wśród nich, Elastic podaje, że robak zatwierdza złośliwe hooki w do 50 gałęziach na każdym dostępnym repozytorium, wstrzykując .claude/settings.json i .vscode/tasks.json do każdej z nich. Wniosek Elastic jest taki, że deweloper, który sklonuje jedną z tych gałęzi i otworzy ją, może zostać zainfekowany przez otwarcie projektu — na tej ścieżce nie ma w ogóle instalacji pakietów, a zatem i zabezpieczenia przed skryptami instalacyjnymi.

Ocena Zscaler jest taka, że hooki utrzymujące trwałość przetrwają usunięcie pakietu i uruchomią się ponownie po prostu przez otwarcie projektu w VS Code lub Claude Code, co omija --ignore-scripts — środek łagodzący, który wiele zespołów przyjęło po wcześniejszych robakach npm. Jego zalecenie wynika bezpośrednio: traktować pliki konfiguracyjne IDE i agentów AI — .claude/, .cursor/, .vscode/, .gemini/ — jako kod wykonywalny, przeglądany z taką samą rygorystycznością jak kod źródłowy.

Istnieje odcisk palca dla repozytoryjnej części ataku. Elastic podaje, że commity wygenerowane przez robaka można zidentyfikować po nazwie autora claude i komunikacie commita chore: update config, a Wiz odnotowuje ten sam ciąg komunikatu. Elastic dodaje, że komunikat commita zawierał także skradziony token GitHub wraz z ciągiem zastraszającym — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — co interpretuje jako próbę zastraszenia deweloperów, by nie odwoływali tokena. Wiz odnotowuje ten sam ciąg w commitach początkowych, a krótszy komunikat jest podstawiany w commitach, które wprowadzają hooki IDE.

Liczby się nie zgadzają, a to nie jest sprzeczność.

Każda opublikowana liczba dotycząca promienia rażenia została wyrażona w innej jednostce, a jednostek nie można stosować wymiennie. Elastic Security Labs w publikacji z 6 sierpnia naliczyło ponad 400 unikalnych pakietów npm, które uległy kompromitacji. Microsoft Threat Intelligence opisał ponad 400 pakietów od wielu niepowiązanych wydawców. Aikido, cytowane przez BleepingComputer, podało co najmniej 868 pakietów w 1 381 wersjach. Orca Security podaje 10 bezpośrednio zatrutych pakietów keyv i cacheable z ponad 619 mln pobrań miesięcznie, a następnie 868 dodatkowych pakietów i 1 381 wersji objętych przez robaka, co daje ponad 2 mld instalacji miesięcznie. Komunikat doradczy CSA Singapuru AD-2026-009 z 6 sierpnia odnotowuje ponad 1 300 skompromitowanych wersji pakietów co łącznie daje2 mld pobrań miesięcznie.

To trzy różne mianowniki — pakiety, wersje pakietów i miesięczny wolumen pobrań — ujęte w trzech różnych momentach kampanii, która wciąż trwała. Relacja Zscaler dotycząca szybkości wyjaśnia, dlaczego się różnią: mówi, że robak rozprzestrzenił się samoczynnie na ponad 400 pakietów w ciągu niespełna czterech godzin i w szczycie publikował około jednego zainfekowanego pakietu na sekundę. Traktowanie późniejszej liczby jako korekty wcześniejszej byłoby błędem; każda jest migawką, a żadne z cytowanych źródeł nie twierdzi, że podaje ostateczną sumę.

Liczby dotyczące zasięgu podane przez Elastic na poziomie bibliotek są tymi najczęściej przytaczanymi i najmniej niejednoznacznymi. Firma podaje, że sam keyv odnotował ponad 600 milionów pobrań w poprzednim miesiącu, flat-cache blisko 580 milionów, cacheable-request ponad 137 milionów, cacheable ponad 30 milionów, a cache-manager ponad 16 milionów. Doradczy komunikat CSA wymienia konkretne skompromitowane wersje, wśród nich 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 oraz ecto 5.0.1.

Pułapka odwołania

Respondenci, którzy zainstalowali podatną wersję, po pierwszym problemie stają przed drugim. Elastic informuje, że na warunkowej ścieżce awaryjnej GitHub payload próbuje zainstalować komponent monitorujący tokeny, który utrzymuje dostęp do danych uwierzytelniających i zawiera niszczycielski moduł obsługi w przypadku unieważnienia monitorowanego tokenu. Zscaler opisuje ten mechanizm szczegółowo pod kątem operacyjnym i nazywa go pułapką unieważnienia tokenu: robak instaluje proces działający w tle, który co 60 sekund odpytuje interfejs API GitHuba przy użyciu skradzionego tokenu, a jeśli token zwróci błąd 4xx — co oznacza, że ofiara go unieważniła — uruchamiany jest dodatkowy niszczycielski payload, który w zależności od wariantu może obejmować zdalne wykonanie kodu lub usunięcie katalogu domowego użytkownika.

Wiz dodaje, że przełącznik dead-man's switch jest selektywnie uzbrajany na podstawie odpowiedzi z serwera dowodzenia i kontroli: operator może zwrócić wartość określającą, które polecenie uzbroić i który token przełącznik powinien obserwować pod kątem unieważnienia. Wiz zauważa również, że monitor oczekuje prawidłowej odpowiedzi z punktu końcowego użytkownika, więc każdy prawidłowy tam typ tokena może służyć jako wyzwalacz.

Praktyczną konsekwencję odnotowuje BleepingComputer oraz cytowane przez niego wytyczne Aikido: stację roboczą dewelopera lub runner CI/CD, na których zainstalowano podatną wersję, należy traktować jako skompromitowane nawet jeśli pakiet został później usunięty, ponieważ wykonanie drugiego etapu mogło ujawnić tokeny i podważyć integralność kompilacji. Wytyczne Microsoftu dochodzą do tego samego wniosku od strony kompilacji, ostrzegając, że organizacje, które zainstalowały podatny pakiet z włączonymi skryptami cyklu życia, powinny traktować stację roboczą lub runner kompilacji jako potencjalnie skompromitowane i odbudować dotknięte systemy oraz artefakty pochodne z zaufanych źródeł.

Co jest ustalone, co jest oceniane, a czego nikt nie wykazał

Podstawowy zapis i pięć niezależnych analiz są zgodne co do mechaniki, a twierdzenia dotyczące mechaniki stanowią najmocniejszą część tego dokumentu.

• Konto GitHub opiekuna keyv zostało przejęte, a złośliwe pliki wypchnięto bezpośrednio do gałęzi main przed publikacją wydania, 4 sierpnia 2026 — zgodnie podają Wiz, Orca Security, BleepingComputer i CSA Singapore.

• Co najmniej keyv 6.0.0 trafiło do npm za pośrednictwem własnego potoku CI ofiary, niosąc ważne provenance, przy czym Zscaler wskazuje na atestację SLSA Build Level 3. To właśnie ta teza czyni ten incydent godnym uwagi, a potwierdzają ją trzy organizacje, które nie współtworzyły nawzajem swoich prac.

• Hook preinstalacji uruchomił setup.mjs, który pobrał Bun v1.3.13 i uruchomił zaciemniony ładunek, który przeskanował ponad 300 wzorców poświadczeń, w tym poświadczenia narzędzi AI do kodowania — Elastic i Wiz są zgodne zarówno co do wersji środowiska uruchomieniowego, jak i listy poświadczeń będących celem ataku AI.

Hooks zapisane w .claude/settings.json i .vscode/tasks.json wykonują się przy starcie sesji i przy otwarciu folderu, a token GitHub App rozszerzył to na maksymalnie 50 gałęzi w każdym dostępnym repozytorium — odkrycie Elastic i podstawa jego stwierdzenia, że deweloper może zostać zainfekowany poprzez otwarcie repozytorium.

• W ciągu kilku dni naruszono ponad 400 unikalnych pakietów, a CSA Singapore, krajowy regulator, opublikował 6 sierpnia 2026 r. ostrzeżenie AD-2026-009 zawierające wykaz podatnych wersji i wskaźników.

To, co źródła traktują jako ocenę, a nie fakt, powinno zostać odpowiednio oznaczone. Wiz opisuje payload jako produkt pochodny rodziny złośliwego oprogramowania „Mini” Shai-Hulud, zbudowany na publicznych repozytoriach Shai-Hulud-Open-Source opublikowanych przez TeamPCP, z kilkoma kluczowymi zmianami; Orca Security przypisuje atak TeamPCP; Zscaler łączy ChainDrop z TeamPCP i umieszcza go w linii rozwoju sięgającej września 2025 r. To konsensus dostawców co do atrybucji, a nie coś, co cytowany dokument pierwotny dowodzi na temat wskazanej osoby lub grupy.

Trzy rzeczy, których nie ustala żadne cytowane źródło i których ten tekst nie uzupełnia. Po pierwsze, jak przejęto konto opiekuna: Zscaler wprost stwierdza, że dokładny mechanizm był nieznany w momencie przeprowadzania swojej analizy. Po drugie, jedna ostateczna suma: liczby 400, 868 i 1 300 zliczają pakiety, kombinacje pakietów i wersji oraz wersje w różnych momentach, a żadne źródło nie twierdzi, że kampania została zakończona. Po trzecie, i co najważniejsze dla twierdzenia w tym zapisie dotyczącego konkretnie AI, żadne cytowane źródło nie podaje potwierdzonego przypadku ponownego użycia skradzionego poświadczenia Anthropic, Codex, Cursor, Gemini lub OpenAI wobec konta dostawcy. Udokumentowane są zamiar i zdolność — wyraźna lista celów oraz kolektor zbudowany, by do niej dotrzeć — a nie wykazane dalsze naruszenie systemów dostawcy AI.

Co się zmieniło później — i co musi zrobić osoba reagująca

Najbardziej konkretnym rozwiązaniem w tym zapisie jest zmiana platformy. Elastic zaleca aktualizację do npm 12 lub nowszego, który domyślnie blokuje hooki preinstall; wytyczne Microsoftu niezależnie zalecają npm CLI v12 oraz funkcję min-release-age, która wstrzymuje nowe wersje na tyle długo, aby społeczność mogła wykryć przejęcie, zanim trafi ono do kompilacji.

Poza tym etapy reakcji publikowane przez źródła w dużym stopniu się pokrywają.

• Elastic: unieważnij wszystkie tokeny GitHub, w tym tokeny sesji na maszynach, których dotyczy problem; unieważnij i wygeneruj ponownie tokeny npm, zwłaszcza tokeny automatyzacji z uprawnieniami zapisu i obejściem uwierzytelniania dwuskładnikowego; przeszukaj repozytoria pod kątem nieautoryzowanych commitów z komunikatem chore: update config from claude@users.noreply.github.com; rotuj sekrety chmury, Kubernetes, Vault, narzędzi AI i CI/CD; włącz uwierzytelnianie dwuskładnikowe na kontach npm.

• Microsoft: wyczyść pamięć podręczną npm i yarn na zagrożonych punktach końcowych i hostach kompilacji, przypnij (pin) znane dobre wersje, przejrzyj pliki lockfile i artefakty pod kątem skompromitowanych wersji, w tym odwołań przechodnich, odbuduj współdzielone obrazy bazowe i wzorcowe runner'y kompilacji oraz przejrzyj zakresy tokenów, zatwierdzenia przepływów pracy i pochodzenie wydań, ponieważ incydent jest spójny z nadużyciem potoku CI/CD poprzez publikowanie za pośrednictwem OIDC.

• CSA Singapore: usunąć wersje, których dotyczy problem, ze środowisk programistycznych, kompilacji oraz CI/CD, traktować systemy, których dotyczy problem, jako skompromitowane i odbudować je, rotować poświadczenia, przejrzeć środowiska chmurowe i kodu źródłowego pod kątem nieuprawnionego dostępu, monitorować pod kątem opublikowanych wskaźników oraz wzmocnić mechanizmy listy dozwolonych, weryfikacji integralności i kontroli pochodzenia.

• Zscaler: traktuj .claude/, .cursor/, .vscode/ i .gemini/ jako kod wykonywalny i przestań traktować proweniencję SLSA lub Sigstore jako dowód bezpieczeństwa — zamiast tego łącz ją z wykrywaniem anomalii w zachowaniu podczas publikowania, takich jak publikowanie po godzinach, masowe publikowanie wersji i publikowanie przez wydawców po raz pierwszy.

Materiał nie zawiera rozstrzygnięcia w sprawie remediacji. Żadne cytowane źródło nie podaje, że złośliwe wersje zostały całkowicie usunięte, że odzyskano konto, że doszło do aresztowania lub do działania organu regulacyjnego; ostrzeżenie CSA jest komunikatem skierowanym do obrońców, a nie ustaleniem przeciwko którejkolwiek stronie.

To, co zmienia ten incydent, to klasyfikacja. Plik konfiguracyjny narzędzia deweloperskiego jest ścieżką wykonania, a otwarcie folderu w edytorze jest zdarzeniem wykonania. Poświadczenie pochodzenia jest zaś stwierdzeniem, który potok wytworzył pakiet — a nie tego, kto trzymał klucze, gdy ten potok działał; i właśnie w tę lukę wpadło pierwsze wydanie keyv.