TL; DR
Złośliwe pakiety npm nie zdarzają się sporadycznie. Są one przedmiotem ciągłej operacji publikowania, a lista potwierdzonych przypadków jest aktualizowana co tydzień. W siedmiu kolejnych edycjach naszego Malicious Code Digest, które już po raz 87. minęły, firma Xygeni potwierdziła 635 XNUMX złośliwych pakietówOd 13 w spokojnym tygodniu do 206 w pracowitym. Kluczowy jest zakres tygodniowy: to rytm, a nie incydent.
- Problemem jest rytm. Jeden pakiet rozrósł się od zera do ponad 55 wersji w ciągu tygodnia. Inny klaster opublikował prawie 30 nazw pakietów w niecałe trzy godziny. Tygodniowy audyt to niewłaściwa jednostka czasu.
- Nie są one dostarczane jako CVE. Złośliwy pakiet nie jest wadą w legalnym kodzie, więc nie ma żadnego ostrzeżenia, oceny i zazwyczaj żadnego identyfikatora. Program oparty na lukach w zabezpieczeniach jest strukturalnie ślepy na te kwestie.
- Zdemontowanie nie oznacza ochrony. Pakiety są zazwyczaj dostępne przez minuty lub godziny. Instalacja albo miała miejsce w tym czasie, albo nie.
- Wykrycie musi nastąpić w momencie publikacji, a egzekwowanie przy instalacji. Wszystko, co czeka na podpis, CVE lub cotygodniowe skanowanie, jest dostarczane po kompilacji, która to pobrała.
Lista istnieje. To nie to samo, co bycie obserwowanym.
Nie ma tajemnicy w złośliwych pakietach npm. Potwierdzone przypadki są publikowane, nazywane i dokumentowane co tydzień, m.in. w Streszczenie złośliwego kodu firmy Xygeni, którego osiemdziesiąte siódme wydanie już się ukazało.
Luka nie polega na informacjach. Chodzi o uwagę i rytm. Lista aktualizowana co tydzień, czytana co miesiąc i podejmowana kwartalnie to lista dokumentująca to, co już komuś się przydarzyło.
Oto jak wyglądało siedem tygodni, obliczone na podstawie naszych własnych potwierdzonych ustaleń, a nie ankiety przeprowadzonej wśród dostawców.
| Digest | Potwierdzone pakiety | Co się wyróżniało |
|---|---|---|
| Streszczenie 87 | 13 | Pierwszy klaster Composera. @umschool/platform opublikowano w 999.0.0 przewyższyć rangę pakietu wewnętrznego |
| Streszczenie 86 | 35 | Kampania Baileysa zmienia pseudonimy. Cztery @stellarshift pakiety opublikowane w identycznej wersji |
| Streszczenie 85 | 53 | [potwierdź wyróżnienie] |
| Streszczenie 84 | 34 | Podszywanie się pod Baileysa w czterech nazwiskach i sześciu dniach. cloud-baileys ponownie publikowane cztery razy |
| Streszczenie 83 | 114 | wormgpt-cli:dziewięć wersji w ciągu jednego dnia, nazwanych na cześć prawdziwego narzędzia dark-LLM |
| Streszczenie 82 | 206 | [potwierdź wyróżnienie] |
| Streszczenie 81 | 180 | 17 paczek podszywających się pod wewnętrzne nazwy PayPal 28.0.0. zevairouter ostatnich 55 wersji |
Wzorzec nie jest najważniejszy, ale tempo w każdym tygodniu.
Prędkość to cały atak
Trzy wnioski z tych tygodni, każdy z nich to inny sposób na ucieczkę przed recenzją.
- Zalewanie wersji. Pojedynczy pakiet npm,
zevairouter, osiągnął ponad 55 potwierdzonych wersji w ciągu jednego tygodnia, do których dołączyło dziesięć kolejnych z pakietu towarzyszącego. Na PyPI,bingo-aiwyprodukował prawie 80 wersji w około 30 minut. Żaden ręczny proces recenzji nie działa z taką prędkością, ani praca wykonywana codziennie. - Zsynchronizowane klastry. Siedemnaście pakietów podszywających się pod wewnętrzne nazwy usług PayPal zostało opublikowanych w ciągu tych samych kilku minut, wszystkie w wersji 28.0.0. To nie kwestia ilości, to wyścig: istnieje zawyżony numer wersji, aby przewyższyć rangę wewnętrznego pakietu stworzonego przez własne zespoły. Ten sam trik pojawił się ponownie kilka tygodni później, wraz z…
@umschool/platformopublikowano pod adresem 999.0.0. - Wytrwałość w obliczu obalenia. Kampania podszywania się pod Baileysa trwa od tygodni. Nazwiska zmieniają się, wersje rosną, a publikacje wciąż trwają po wykryciu. Operator, który traktuje usuwanie treści jako koszt prowadzenia działalności, a nie powód do zaprzestania, to operator, którego kwartalna kontrola nigdy nie dogoni.
Czas przebywania jest krótki, co jest zamierzone. W jednym z ostatnich przypadków pakiety były aktywne przez okres od 17 minut do 13 godzin przed usunięciem.
| Pakiet | Opublikowano (UTC) | Pozostawiony stojący |
|---|---|---|
moidev | 2026-08-16 16:31 | 5h 58m |
moidevx | 2026-08-17 03:24 | 13h 23m |
moidevz | 2026-08-26 03:38 | 12h 56m |
moideva | 2026-08-26 18:58 | 1h 33m |
amicat | 2026-08-28 20:48 | 17m |
bmcat | 2026-08-28 21:17 | 47m |
eyevox | 2026-08-28 21:44 | 21m |
moidevh | 2026-08-31 03:22 | 47m |
Odczytaj to jako okno ekspozycji, a nie wskaźnik wydajności rejestru. Jeśli kompilacja była w tym czasie uruchomiona, usunięcie niczego nie zmieniło.
Dlaczego Twój program wykrywania podatności tego nie widzi
To jest ten punkt strukturalny, którego większość zespołów ds. bezpieczeństwa nie przyswoiła.
| Urazliwość | Złośliwy pakiet | |
|---|---|---|
| Origin | Błąd w kodzie napisanym w dobrej wierze | Artefakt zbudowany i opublikowany w celu wyrządzenia krzywdy |
| identyfikator | CVE z ostrzeżeniem i oceną | Zwykle brak. Brak CVE, brak ostrzeżenia |
| Oś czasu | Ujawnione, a następnie łatane w ciągu dni lub tygodni | Żyją przez minuty lub godziny, a następnie zostają usunięte |
| Jak się uczysz | Kanał, skaner, doradztwo | Tylko jeśli coś obserwowało rejestr w momencie publikacji |
| Poprawka | Zaktualizuj do wersji z poprawkami | Nie ma poprawionej wersji. Nigdy nie była legalna. |
| Co robi Twój program | Pobieranie, wyniki, harmonogramy | Nic, chyba że zostało to do tego zbudowane |
Luka w zabezpieczeniach to wada kodu, który ktoś napisał w dobrej wierze. Złośliwy pakiet to celowo publikowany przez atakującego artefakt, zazwyczaj bez identyfikatora, ostrzeżenia i z czasem życia mierzonym w godzinach. Każdy proces oparty na pobieraniu luk CVE, ocenie ważności i oknach łatek został zaprojektowany z myślą o tym pierwszym i domyślnie zastosowany do drugiego.
Brak identyfikatora nie jest niedopatrzeniem w systemie CVE. To kategoria działająca zgodnie z założeniami: nikt nie zgłasza problemu dotyczącego artefaktu, którego cały cel był złośliwy, a zanim ktokolwiek zdąży to zrobić, pakiet znika. Co oznacza pytanie: „Czy to ma CVE?” zwraca tę samą odpowiedź dla czystego pakietu i dla złodzieja poświadczeń opublikowanego godzinę temu.
Co ładunki faktycznie teraz robią
Naiwnie wyobrażamy sobie złośliwe pakiety npm jako koparki kryptowalut. Obecna rzeczywistość to kradzież danych uwierzytelniających, której celem są programiści, a coraz częściej także dane uwierzytelniające sztucznej inteligencji na ich komputerach.
PhantomSync Klaster, osiem pakietów npm opublikowanych na jednym koncie, działał dokładnie tak, jak reklamowano, jednocześnie ukrywając samoczynnie wywołującego droppera, który uruchamiał się około 37 sekund po imporcie, dekodował ładunek przygotowany jako fałszywa instalacja testowa, instalował międzyplatformową trwałość i uruchamiał program do kradzieży portfela i sekretów. Opóźniaj, maskuj, utrwalaj, eksfiltruj.
W większej skali fala CHAINDROP Robak Shai-Hulud Na początku sierpnia 2026 roku do sieci trafiło ponad 400 pakietów i 1,700 wersji, a łączna liczba pobrań wynosiła 1.3 miliarda miesięcznie. Jego kolektor skanował ponad 300 wzorców uwierzytelniania, w tym klucze OpenAI, Anthropic i Cursor. Maszyny deweloperskie stały się cennym narzędziem.cistylko ze względu na modelowe referencje, które na nich widnieją.
Konwencje nazewnictwa poszły w ślady pieniędzy. Najnowsze klastry podszywają się pod pakiety SDK kryptowalut i DeFi, moduły płatności, biblioteki API WhatsApp, narzędzia AWS, a w jednym przypadku, pakiet otwarcie nazwany na cześć narzędzia atakującego dark-LLM.
Co tak naprawdę powstrzymuje złośliwe pakiety npm
Cztery kontrole w kolejności, w jakiej się opłacają.
1. Wykrycie w momencie publikacji, a nie ujawnienia. Wczesne ostrzeganie przed złośliwym oprogramowaniem firmy Xygeni Analizuje nowo opublikowane pakiety w npm, PyPI, Maven i innych rejestrach w momencie ich pojawienia się, wykorzystując analizę behawioralną i analizę anomalii, zamiast czekać na podpis lub raport. To jedyny punkt na osi czasu, który wyprzedza kompilację.
2. Egzekwowanie przepisów w miejscu instalacji. Wykrycie informuje, że pakiet jest złośliwy. Polityka blokująca instalację uniemożliwia uruchomienie skryptu poinstalacyjnego. Ma to teraz większe znaczenie, ponieważ agenci instalują zależności bez konieczności ich wyboru przez człowieka.
3. Pliki blokady i przypinanie haszu. Zastosowanie npm ci w CI, a nie npm install, więc budowane jest dokładne drzewo zależności w pliku blokady. Zamyka ono ścieżkę podstawiania, na której opierają się typosquaty i wersje z nadwyżką.
4. Wyniki w jednym miejscu. Wyniki dotyczące złośliwego oprogramowania znajdują się w tej samej priorytetowej kolejce co Twoje SCA i wyniki wyszukiwania kodu, a nie w osobnym kanale, który ktoś przegląda. Potwierdzona szkodliwa zależność powinna mieć wyższą rangę niż luka bezpieczeństwa o średnim stopniu ważności, a takie porównanie jest możliwe tylko dzięki współdzielonemu modelowi ryzyka.
Obejrzyj listę lub zautomatyzuj ją
Nikt nie ma czasu, żeby co tydzień czytać rejestr. Właśnie po to jest ta automatyzacja.
Platforma Xygeni analizuje nowo opublikowane pakiety w rejestrach npm i innych w momencie publikacji, oznacza potwierdzone złośliwe oprogramowanie przed jego kompilacją i umieszcza odkrycie w tej samej priorytetowej kolejce, co wszystkie inne elementy, z którymi pracują już Twoje zespoły. Wykrywanie złośliwego oprogramowania jest uwzględniony w bezpłatnym planie Developer, co nie jest prawdą w przypadku większości bezpłatnych planów w tej kategorii.
Zacznij za darmolub przeczytaj Tygodniowy przegląd złośliwego kodu pierwszy.
FAQ
Czym są złośliwe pakiety npm?
Pakiety opublikowane w rejestrze npm, które zostały celowo stworzone w celu wyrządzenia szkód: programy kradnące dane uwierzytelniające i portfele, tylne furtki, programy typu dropper oraz artefakty powodujące pomyłki w zależnościach, podszywające się pod wewnętrzne lub popularne nazwy pakietów.
Jak powszechne są złośliwe pakiety npm?
Ciągły. W siedmiu ostatnich edycjach naszego Malicious Code Digest, Xygeni potwierdziło 635 złośliwych pakietów, od około tuzina w spokojnym tygodniu do ponad 200 podczas aktywnych kampanii. Za zdecydowaną większość odpowiada npm.
Jak długo złośliwe pakiety npm pozostają dostępne?
Często trwa to od minut do godzin. To okno czasowe ma znaczenie, ponieważ kompilacja uruchomiona w jego trakcie jest już zagrożona, niezależnie od tego, jak szybko pakiet zostanie później usunięty.
Czy złośliwe pakiety npm otrzymują kody CVE?
Zazwyczaj nie. Są to artefakty opublikowane przez atakującego, a nie błędy w legalnym kodzie, a śledzone kampanie z 2026 roku nie otrzymały żadnych zgłoszeń CVE podczas aktywnej eksploatacji.
Jak sprawdzić, czy pakiet jest złośliwy przed instalacją?
Użyj narzędzia, które analizuje pakiety w momencie publikacji, a nie takiego, które sprawdza listę znanych złych pakietów, zweryfikuj wydawcę i historię wersji, bądź podejrzliwy w przypadku nietypowo wysokich numerów wersji i zupełnie nowych kont oraz egzekwuj zasady w momencie instalacji, zamiast polegać na przeglądzie.
Czym jest pomieszanie zależności?
Publikowanie pakietu publicznego o tej samej nazwie co pakiet wewnętrzny, zazwyczaj w wersji rozszerzonej, tak aby resolver preferował kopię atakującego. Klaster PayPal-name w wersji 28.0.0 jest podręcznikowym przykładem.







