Trzynaście pakietów npm, 48 sekund, jedno fałszywe SDK portfela

Skoordynowany atak na rejestr npm wprowadził 13 podrobionych pakietów SDK portfela w stylu Coinbase w zaledwie 48 sekund, pokazując, jak szybko złośliwy kod może podszywać się pod zaufane narzędzia. Programiści, którzy instalują pakiet wyłącznie na podstawie znajomej nazwy, mogą nieświadomie wprowadzić fałszywe SDK do swoich aplikacji.

Pakiety pojawiły się między 04:54:59 a 04:55:48 UTC dnia 7 września 2026 r. Nazwy takie jak cb-wallet-http i scw-core naśladują oficjalną przestrzeń nazw @coinbase/wallet-sdk. Zamiast stosować typo-squatting, atakujący dodali do nazw znane ciągi znaków, licząc na to, że rekomendacja współpracownika lub post na forum przekona użytkowników o ich autentyczności.

Wszystkie 13 wydań miało tę samą szkieletową konfigurację: wersję 0.0.1-security, pustą listę opiekunów oraz domyślne metadane npm wyświetlane natychmiast po publikacji. Identyczna konfiguracja wskazuje na pojedynczy skrypt, który wygenerował te pakiety, co jest znakiem rozpoznawczym automatyzacji, a nie pracy ręcznej.

Otwarty model publikacji npm pozwala każdemu na przesłanie pakietu bez wcześniejszej weryfikacji, co umożliwia tego typu ataki. Poprzednie incydenty związane z łańcuchem dostaw pokazały, że gdy złośliwy kod trafi do drzewa zależności, uruchamia się na każdej maszynie, która go zainstaluje.

NPM nie zidentyfikował sprawców ani nie wyjaśnił, w jaki sposób kod rozprzestrzenił się poza początkowe przesyłki. Nie jest również jasne, czy atakujący celowali konkretnie w użytkowników Coinbase, czy po prostu zalali rejestr nazwami, które wyglądają wiarygodnie, licząc na to, że niektóre z nich zostaną przyjęte.

Co programiści mogą zrobić teraz

  • Sprawdź wydawcę pakietu przed jego dodaniem; oficjalne SDK znajdują się w zweryfikowanych zakresach organizacji (organization scopes).
  • Używaj narzędzi skanujących zależności pod kątem znanych sygnatur złośliwego oprogramowania.
  • Przypinaj dokładne wersje w plikach lock i unikaj pobierania nowo opublikowanych pakietów bez weryfikacji.
  • Wybieraj rejestry, które wymagają uwierzytelniania dwuskładnikowego dla opiekunów.

Na co zwrócić uwagę

  • Czy npm zaostrzy proces weryfikacji pakietów podszywających się pod znane marki.
  • Listy czarne tworzone przez społeczność, które oznaczają nazwy podszywające się pod inne.
  • Aktualizacje od badaczy bezpieczeństwa dotyczące ewentualnego aktywnego wykorzystywania 13 fałszywych SDK.

Ten incydent dowodzi, że znajomo brzmiąca nazwa nie daje żadnej gwarancji bezpieczeństwa. Czujność i weryfikacja pozostają najsilniejszą obroną przed atakami na łańcuch dostaw w ekosystemie open-source.