Sapphire Sleet przejęła 145 pakietów Mastra. Tak wyglądał atak na łańcuch dostaw npm

Zaatakowane pakiety miały łącznie ponad 1,1 mln pobrań tygodniowo . Kampania pokazała, że do poważnego naruszenia bezpieczeństwa całego ekosystemu nie zawsze potrzeba włamania do infrastruktury projektu. Wystarczy przejęcie zaufanego konta publikującego pakiety.

Jak przebiegał atak na Mastra

1. Inżynieria społeczna i przejęcie konta

Napastnicy najpierw zaatakowali jednego z legalnych opiekunów projektu Mastra, stosując inżynierię społeczną. W ten sposób uzyskali dane dostępowe do jego konta npm . Przejęte konto, identyfikowane jako ehindero, miało uprawnienia do publikowania w całej przestrzeni nazw @mastra .

2. Masowa publikacja w kilka minut

Korzystając z przejętych uprawnień, atakujący opublikowali zmodyfikowane wersje wszystkich pakietów @mastra/* w ciągu około 88 minut. Niektóre raporty wskazują, że zasadniczy etap publikacji trwał zaledwie 19 minut . Takie tempo sugeruje wykorzystanie zautomatyzowanego skryptu, a nie ręczne przesyłanie pakietów.

3. Podszywająca się zależność

Do każdej zainfekowanej wersji dodano złośliwą zależność o nazwie easy-day-js. Jej nazwa miała przypominać popularną, legalną bibliotekę dayjs, wykorzystywaną do obsługi dat w projektach JavaScript . Badacze określili kampanię mianem „easy-day-js” .

4. Uruchomienie kodu podczas instalacji

Ładunek został zaprojektowany tak, by uruchamiał się automatycznie za pośrednictwem skryptu npm postinstall. Oznaczało to, że samo wykonanie npm install z użyciem podatnej wersji mogło uruchomić złośliwy kod — bez potrzeby uruchamiania aplikacji ani agenta AI .

5. Kradzież danych uwierzytelniających i kryptowalut

Po uruchomieniu ładunek przeszukiwał stacje robocze deweloperów oraz systemy budowania pod kątem kluczy do portfeli kryptowalut, poświadczeń chmurowych i sekretów używanych w potokach CI/CD . Kod wyłączał również weryfikację TLS i pobierał drugą fazę narzędzia kradnącego dane z infrastruktury kontrolowanej przez napastników .

Microsoft wskazuje na Sapphire Sleet

19 czerwca 2026 r. Microsoft ocenił z wysokim poziomem pewności, że za operacją stoi Sapphire Sleet — północnokoreański aktor państwowy, który koncentruje się przede wszystkim na sektorze finansowym i kryptowalutach . Microsoft oparł przypisanie kampanii m.in. na wykorzystanej infrastrukturze oraz zgodności obserwowanych metod, technik i procedur (TTP) z wcześniejszymi działaniami tej grupy .

Amazon Threat Intelligence powiązał Sapphire Sleet także z wcześniejszymi kampaniami wymierzonymi w pakiety npm, w tym axios, debug, chalk i typo-crypto .

Odpowiedź Microsoftu: krótsze życie kluczy i Trusted Publishing

Atak na Mastra przyspieszył zmiany, które Microsoft przygotowywał w celu ograniczenia ryzyka związanego z długotrwałymi poświadczeniami publikującymi pakiety.

Nowe klucze NuGet będą ważne maksymalnie 30 dni

Od 17 sierpnia 2026 r. maksymalny czas ważności nowo tworzonych kluczy API NuGet.org zostanie skrócony z 365 do 30 dni . Wszystkie klucze utworzone przed tą datą mają zostać unieważnione 1 listopada 2026 r. .

Powód jest praktyczny: długowieczne klucze API mogą zostać zgubione, wykradzione lub pozostać aktywne długo po tym, gdy przestaną być potrzebne. Przejęty klucz daje napastnikowi czas na publikowanie złośliwych wersji pakietów pod nazwą zaufanego projektu — dokładnie tak, jak stało się w przypadku Mastra oraz niedawnego incydentu dotyczącego NX Console .

Trusted Publishing jako preferowany model publikacji

Microsoft zdecydowanie rekomenduje przejście na Trusted Publishing — model uruchomiony we wrześniu 2025 r., który zastępuje długoterminowe klucze uwierzytelnianiem OpenID Connect (OIDC) .

Najważniejsze zalety tego rozwiązania to :

• brak długoterminowych sekretów przechowywanych w repozytoriach i systemach CI/CD;
• krótkotrwałe poświadczenia wydawane dla pojedynczej publikacji, zwykle ważne około godziny;
• weryfikacja tożsamości procesu budowania na podstawie repozytorium, workflow oraz — opcjonalnie — skonfigurowanego środowiska;
• brak konieczności ręcznej rotacji sekretów;
• znacznie mniejszy zakres potencjalnych szkód w razie ujawnienia poświadczeń.

W praktyce workflow CI/CD korzystający z Trusted Publishing pobiera od dostawcy, takiego jak GitHub Actions, kryptograficznie podpisany token OIDC. NuGet.org porównuje zawarte w nim informacje z zarejestrowaną polityką wydawcy, a następnie wystawia tymczasowy, jednorazowy klucz API ważny tylko podczas danej publikacji .

Zmiany w całym ekosystemie npm

Działania Microsoftu wpisują się w szerszy trend odchodzenia od długowiecznych tokenów:

• Klasyczne tokeny npm zostały wycofane. W grudniu 2025 r. npm trwale unieważnił wszystkie klasyczne tokeny. Polecenie npm login wydaje obecnie wyłącznie tokeny sesyjne ważne przez dwie godziny .
• Granularne tokeny z prawem zapisu mają krótszy czas życia. Ich domyślna ważność wynosi siedem dni, a maksymalna — 90 dni .
• Staged publishing wymaga dodatkowego potwierdzenia. Funkcja, ogólnie dostępna od maja 2026 r., wymaga od opiekuna przejścia przez wyzwanie 2FA i jawnego zatwierdzenia wydania, zanim pakiet będzie można publicznie zainstalować .

Wspólny cel tych mechanizmów jest jasny: ograniczyć ryzyko wynikające z pojedynczego, długo ważnego tokenu opiekuna, który ma uprawnienia do publikowania całej grupy pakietów.

Co powinni zrobić deweloperzy i opiekunowie pakietów

• Sprawdź i wymień klucze NuGet. Klucze utworzone przed 17 sierpnia 2026 r. wygasną 1 listopada 2026 r. Przed tym terminem należy wygenerować nowe klucze albo przejść na Trusted Publishing .
• Włącz Trusted Publishing możliwie szybko. Uwierzytelnianie OIDC pozwala zrezygnować z przechowywania długoterminowych sekretów w potokach CI/CD. Rozwiązanie jest obsługiwane przez NuGet.org, npm i PyPI .
• Przejrzyj proces publikowania w npm. Sprawdź, czy workflow korzysta z krótkotrwałych tokenów sesyjnych, ograniczonych czasowo tokenów granularnych albo Trusted Publishing .
• Przypinaj sprawdzone wersje zależności. W przypadku krytycznych projektów warto unikać automatycznych aktualizacji, dopóki nowe wersje nie zostaną zweryfikowane .
• Rozważ wyłączenie skryptów instalacyjnych. npm install --ignore-scripts lub ustawienie ignore-scripts = true może uniemożliwić automatyczne wykonanie złośliwych skryptów postinstall .

Atak na Mastra przypomina, że bezpieczeństwo zależności zaczyna się nie tylko od kodu biblioteki, lecz także od ochrony kont publikujących i sposobu, w jaki pakiety trafiają do rejestru.