Atak na łańcuch dostaw NPM w ekosystemie Mastra przypisany hakerom z Korei Północnej

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych zagrożeń dla zespołów deweloperskich i organizacji budujących aplikacje w oparciu o komponenty open source. Polegają one na skompromitowaniu zależności, kont maintainerów lub procesu publikacji pakietów w taki sposób, aby złośliwy kod został dostarczony ofiarom jako pozornie legalna aktualizacja.

Incydent w ekosystemie Mastra pokazuje, że pojedyncze przejęcie konta z uprawnieniami publikacyjnymi w rejestrze NPM może przełożyć się na realne ryzyko dla stacji roboczych programistów, środowisk testowych oraz pipeline’ów CI/CD.

W skrócie

• W czerwcu 2026 roku zaatakowano ekosystem open source Mastra, framework używany do budowy agentów AI, workflow i pipeline’ów RAG.
• Napastnicy opublikowali 141 skompromitowanych pakietów zawierających złośliwą zależność podszywającą się pod legalną bibliotekę dat.
• Złośliwy komponent uruchamiał się podczas instalacji i pobierał kolejny etap malware z infrastruktury atakującego.
• Atak został przypisany grupie Sapphire Sleet, powiązanej z Koreą Północną i znanej z operacji ukierunkowanych na kradzież aktywów kryptowalutowych.

Kontekst / historia

Mastra to framework rozwijany w ekosystemie JavaScript i TypeScript, wykorzystywany do integracji z dużymi modelami językowymi, serwerami MCP oraz wdrożeniami chmurowymi. Z uwagi na charakter projektu i jego zastosowania, kompromitacja pakietów w tym środowisku ma znaczenie wykraczające poza pojedyncze aplikacje.

Do incydentu doszło 17 czerwca 2026 roku. W trakcie około 45 minut atakujący opublikowali 141 zmodyfikowanych pakietów Mastra po wcześniejszym przejęciu konta maintainera NPM „ehindero”, które miało szerokie uprawnienia publikacyjne. Dzień wcześniej przygotowano grunt pod operację, publikując pozornie nieszkodliwą wersję pakietu „easy-day-js” z innego konta.

Ten schemat wpisuje się w rosnący trend kampanii supply chain łączących przejęcia kont deweloperskich, typosquatting oraz nadużywanie skryptów instalacyjnych. Tego rodzaju operacje są szczególnie niebezpieczne, ponieważ wykorzystują zaufanie do popularnych repozytoriów i rutynowych procesów aktualizacji zależności.

Analiza techniczna

Kluczowym elementem ataku było dodanie do pakietów Mastra zależności „easy-day-js”, będącej typosquatem legalnej biblioteki „dayjs”. Modyfikacja została przygotowana tak, aby instalowana była zawsze najnowsza wersja tej zależności. W praktyce oznaczało to, że użytkownicy pobierający skompromitowane wydania automatycznie otrzymywali złośliwy komponent.

Złośliwa zależność zawierała zaciemniony dropper uruchamiany przez mechanizm postinstall. Jego zadaniem było pobranie drugiego etapu malware z serwerów kontrolowanych przez atakującego, zapisanie ładunku w katalogu tymczasowym, uruchomienie go jako procesu działającego w tle oraz usunięcie części śladów po pierwszym etapie infekcji.

Istotne jest to, że wykonanie następowało już na etapie instalacji pakietu, niezależnie od tego, czy biblioteka była później rzeczywiście importowana w kodzie aplikacji. To znacząco poszerzało powierzchnię ataku, obejmując zarówno komputery programistów, jak i automatyczne buildy oraz środowiska wykonujące standardowe polecenia npm install lub npm update.

Według dostępnych analiz malware było przygotowane dla systemów Windows, macOS i Linux. Funkcje złośliwego oprogramowania obejmowały rozpoznanie środowiska oraz wyszukiwanie ponad 160 rozszerzeń przeglądarkowych powiązanych z kryptowalutami, co wskazuje na silną motywację finansową operacji.

Atrybucję przypisano grupie Sapphire Sleet, znanej również pod nazwami BlueNoroff, CageyChameleon, Copernicium i Stardust Chollima. To aktor powiązany z Koreą Północną, regularnie łączony z kampaniami wymierzonymi w portfele kryptowalutowe, zasoby cyfrowe i poświadczenia umożliwiające przejęcie środków.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją incydentu jest możliwość kompromitacji systemu już podczas instalacji zależności. W praktyce oznacza to, że nawet rutynowa aktualizacja pakietów mogła doprowadzić do wykonania obcego kodu na stacji roboczej dewelopera lub w środowisku CI/CD.

Ryzyko obejmuje kilka krytycznych obszarów:

• kradzież sekretów lokalnych i środowiskowych, w tym tokenów, kluczy API i danych chmurowych;
• przejęcie poświadczeń do rejestrów pakietów, repozytoriów kodu i narzędzi developerskich;
• kradzież aktywów cyfrowych poprzez analizę rozszerzeń i narzędzi związanych z kryptowalutami;
• dalsze skażenie pipeline’ów, artefaktów buildów i obrazów kontenerowych.

Dodatkowym czynnikiem ryzyka jest skala użycia ekosystemu Mastra. Nawet stosunkowo krótkie okno publikacji mogło wystarczyć, aby narazić organizacje korzystające z automatycznych aktualizacji zależności, cyklicznych buildów lub mechanizmów cachowania pakietów.

Rekomendacje

Organizacje, które instalowały pakiety Mastra 17 czerwca 2026 roku w czasie okna kompromitacji, powinny traktować swoje środowiska jako potencjalnie naruszone. Priorytetem jest identyfikacja wszystkich hostów, kontenerów i runnerów CI/CD, które mogły pobrać zainfekowane wersje.

Następnie należy przeprowadzić pełne dochodzenie powłamaniowe obejmujące analizę procesów uruchamianych podczas instalacji NPM, kontrolę plików tymczasowych, przegląd artefaktów buildów oraz weryfikację połączeń wychodzących do zewnętrznych serwerów. Warto również sprawdzić, czy na systemach nie pojawiły się nietypowe binaria lub narzędzia podszywające się pod komponenty środowiska Node.js.

Równolegle konieczna jest rotacja wszystkich sekretów, które mogły być dostępne z poziomu zagrożonych systemów. Dotyczy to haseł, tokenów NPM, kluczy do usług chmurowych, poświadczeń do repozytoriów kodu oraz sekretów używanych w pipeline’ach CI/CD. Użytkownicy korzystający z portfeli kryptowalutowych lub rozszerzeń Web3 powinni dodatkowo zabezpieczyć środki i rozważyć migrację aktywów.

W perspektywie długoterminowej warto wdrożyć następujące środki ochronne:

• ograniczanie lub blokowanie skryptów instalacyjnych w zewnętrznych zależnościach;
• pinowanie wersji pakietów i ścisłą kontrolę aktualizacji;
• wymuszanie MFA dla maintainerów i kont publikacyjnych;
• monitorowanie nowych, nietypowych i potencjalnie typosquattingowych zależności;
• detekcję anomalii w pipeline’ach buildowych;
• izolację środowisk deweloperskich i runnerów CI;
• wykorzystanie SBOM oraz narzędzi do analizy zachowania pakietów open source przed dopuszczeniem ich do produkcji.

Podsumowanie

Atak na Mastra potwierdza, że ekosystem NPM pozostaje atrakcyjnym celem dla zaawansowanych grup prowadzących operacje finansowe i wywiadowcze. Połączenie przejęcia konta maintainera, typosquattingu oraz uruchamiania złośliwego kodu w fazie postinstall sprawiło, że kompromitacja mogła nastąpić jeszcze zanim ofiara uruchomiła aplikację.

Dla organizacji korzystających z nowoczesnych łańcuchów dostaw oprogramowania to wyraźny sygnał, że bezpieczeństwo zależności musi obejmować nie tylko analizę kodu, lecz także kontrolę procesu instalacji, uprawnień publikacyjnych i zachowania pakietów w środowiskach buildowych.

Źródła

1. SecurityWeek — North Korean Hackers Blamed for Mastra NPM Supply Chain Attack — https://www.securityweek.com/north-korean-hackers-blamed-for-mastra-npm-supply-chain-attack/
2. Microsoft — Threat intelligence statement referenced in reporting on the Mastra supply chain attack — https://www.microsoft.com/
3. Aikido Security — Technical analysis of the Mastra package compromise — https://www.aikido.dev/
4. Socket — Research and indicators related to malicious NPM packages — https://socket.dev/
5. StepSecurity — Analysis and IoCs for the Mastra supply chain incident — https://www.stepsecurity.io/