TL; DR
Ondsinnede npm-pakker er ikke en sporadisk hendelse. De er en kontinuerlig publiseringsoperasjon, og listen over bekreftede tilfeller oppdateres hver uke. I løpet av syv påfølgende utgaver av vår Malicious Code Digest, som nå har passert sin 87. utgave, bekreftet Xygeni 635 XNUMX ondsinnede pakker, fra 13 i en rolig uke til 206 i en travel uke. Det ukentlige intervallet er poenget: dette er en kadens, ikke en hendelse.
- Kadensen er problemet. Én pakke gikk fra null til mer enn 55 versjoner på en uke. En annen klynge publiserte nesten 30 pakkenavn på under tre timer. En ukentlig revisjon er feil tidsenhet.
- De ankommer ikke som CVE-er. En ondsinnet pakke er ikke en feil i legitim kode, så det finnes ingen veiledning, ingen poengsum og vanligvis ingen identifikator i det hele tatt. Et sårbarhetsdrevet program er strukturelt blindt for dette.
- Nedtakelse er ikke beskyttelse. Pakker er vanligvis aktive i minutter til timer. Installasjonen din skjedde enten i det vinduet, eller så skjedde den ikke.
- Deteksjon må skje ved publisering, og håndheving ved installasjon. Alt som venter på en signatur, en CVE eller en ukentlig skanning kommer etter byggingen som hentet det.
Listen finnes. Det er ikke det samme som å bli sett på.
Det er ingen mystikk rundt ondsinnede npm-pakker. Bekreftede tilfeller publiseres, navngis og dokumenteres hver uke, inkludert i Xygenis egen oversikt over ondsinnet kode, nå passert sin åttisyvende utgave.
Gapet er ikke informasjon. Det er oppmerksomhet og tempo. En liste som oppdateres ukentlig, leses månedlig og som behandles kvartalsvis, er en liste som dokumenterer hva som allerede har skjedd med noen.
Slik så sju uker ut, hentet fra våre egne bekreftede funn i stedet for fra en leverandørundersøkelse.
Det er ikke totalene som teller. Det er hastigheten inni hver uke.
Hastighet er hele angrepet
Tre funn fra disse ukene, hvert av dem en ulik måte å overgå gjennomgang på.
- Versjonsoversvømmelse. En enkelt npm-pakke,
zevairouter, nådde mer enn 55 bekreftede versjoner på én uke, og fikk selskap av ti til fra en tilhørende pakke. På PyPI,bingo-aiproduserte nesten 80 versjoner på omtrent 30 minutter. Ingen manuell gjennomgangsprosess fungerer med den hastigheten, og det gjør heller ikke en nattlig jobb. - Synkroniserte klynger. Sytten pakker som utga seg for å være interne PayPal-tjenestenavn ble publisert i løpet av de samme minuttene, alle i versjon 28.0.0. Det er ikke volum, det er et kappløp: et oppblåst versjonsnummer eksisterer for å rangere høyere enn den interne pakken dine egne team skrev. Det samme trikset dukket opp igjen uker senere med
@umschool/platformpublisert på 999.0.0. - Persistens gjennom fjerning. Baileys' etterligningskampanje har pågått i flere uker. Navnene roterer, versjoner øker, og ny publisering fortsetter etter at de er oppdaget. En operatør som behandler fjerninger som en kostnad ved å drive virksomheten snarere enn en grunn til å stoppe, er en operatør du aldri vil ta igjen i kvartalsgjennomgangen din.
Og oppholdstiden er kort per design. I en nylig klynge var pakkene aktive i mellom 17 minutter og 13 timer før de ble fjernet.
Les det som et eksponeringsvindu snarere enn en ytelsesmåling for registeret. Hvis en build kjørte underveis, endret ikke fjerningen noe.
Hvorfor sårbarhetsprogrammet ditt ikke ser dette
Dette er det strukturelle punktet, og det er det de fleste sikkerhetsteam ikke har internalisert.
En sårbarhet er en feil i koden noen har skrevet i god tro. En ondsinnet pakke er en bevisst artefakt publisert av en angriper, vanligvis uten identifikator, uten veiledning og en levetid målt i timer. Hver prosess bygget rundt CVE-inntak, alvorlighetsgrad og oppdateringsvinduer ble designet for det første og brukt på det andre som standard.
Fraværet av en identifikator er ikke en forglemmelse i CVE-systemet. Det er kategorien som fungerer som tiltenkt: ingen sender inn en advarsel mot en artefakt hvis hele formål var ondsinnet, og når noen kunne gjøre det, er pakken borte. Noe som betyr spørsmålet «har dette en CVE«returnerer det samme svaret for en ren pakke og for en legitimasjonstyver publisert for en time siden.»
Hva nyttelastene faktisk gjør nå
Det naive bildet av ondsinnede npm-pakker er en kryptominer. Den nåværende virkeligheten er legitimasjonstyveri rettet mot utviklere, og i økende grad mot AI-legitimasjonen på maskinene deres.
Ocuco PhantomSync cluster, åtte npm-pakker publisert under én konto, fungerte nøyaktig som annonsert mens de skjulte en selvkallende dropper som avfyrte omtrent 37 sekunder etter import, dekodet en nyttelast iscenesatt som en falsk testfixtur, installerte persistens på tvers av plattformer og lanserte en lommebok- og hemmelighetstyver. Forsinke, skjule, persistere, eksfiltrere.
I større skala, CHAINDROP-bølgen til Shai-Hulud-ormen traff mer enn 400 pakker og 1,700 versjoner tidlig i august 2026, med til sammen 1.3 milliarder månedlige nedlastinger. Samleren skannet etter mer enn 300 legitimasjonsmønstre, inkludert OpenAI, Anthropic og Cursor-nøkler. Utviklermaskiner ble verdifulle førcisely på grunn av modelllegitimasjonene som står på dem.
Navnekonvensjoner har fulgt pengene. Nyere klynger imiterer krypto- og DeFi-SDK-er, betalingsmoduler, WhatsApp API-biblioteker, AWS-verktøy og, i ett tilfelle, en pakke åpenlyst merket etter et dark-LLM-angrepsverktøy.
Hva som faktisk stopper ondsinnede npm-pakker
Fire kontroller, i den rekkefølgen de gir resultater.
1. Oppdagelse ved publisering, ikke ved avsløring. Xygenis tidlige advarsel om skadelig programvare analyserer nylig publiserte pakker på tvers av npm, PyPI, Maven og andre registre i det øyeblikket de dukker opp, ved hjelp av atferds- og anomalianalyse i stedet for å vente på en signatur eller en rapport. Det er det eneste punktet i tidslinjen som er foran byggingen din.
2. Håndheving der installasjonen skjer. Deteksjon forteller deg at en pakke er skadelig. En policy som blokkerer installasjonen er det som hindrer at etterinstallasjonsskriptet kjører. Dette er enda viktigere nå som agenter installerer avhengigheter uten at et menneske velger dem.
3. Låsefiler og hash-pinning. Bruk npm ci i CI heller enn npm install, så det er det nøyaktige avhengighetstreet i låsefilen som bygges. Det lukker substitusjonsruten som typosquats og oppblåste versjoner er avhengige av.
4. Funn på ett sted. Funn av skadelig programvare hører hjemme i samme prioriterte kø som din SCA og kodefunn, ikke i en separat feed noen skumleser. En bekreftet ondsinnet avhengighet bør rangere høyere en CVE med middels alvorlighetsgrad, og bare en delt risikomodell gjør den sammenligningen mulig.
Se på listen, eller automatiser den
Ingen har oppmerksomhet nok til å lese en registerfeed hver uke. Det er poenget med å automatisere det.
Xygeni analyserer nylig publiserte pakker på tvers av npm og andre registre i publiseringsøyeblikket, flagger bekreftet skadelig programvare før den når en versjon, og plasserer funnet i samme prioriterte kø som alt annet teamene dine allerede jobber med. Oppdagelse av skadelig programvare er inkludert i den gratis utviklerplanen, noe som ikke gjelder for de fleste gratisnivåene i denne kategorien.
Start gratis, eller les denne ukens sammendrag av skadelig kode først.
FAQ
Hva er ondsinnede npm-pakker?
Pakker publisert i npm-registeret som bevisst er bygget for å forårsake skade: påloggings- og lommeboktyveri, bakdører, droppere og avhengighetsforvirrende artefakter som utgir seg for å være interne eller populære pakkenavn.
Hvor vanlige er ondsinnede npm-pakker?
Kontinuerlig. I løpet av syv nylige utgaver av vår Malicious Code Digest bekreftet Xygeni 635 ondsinnede pakker, alt fra omtrent et dusin i en rolig uke til over 200 under aktive kampanjer. npm står for det overveldende flertallet.
Hvor lenge forblir ondsinnede npm-pakker tilgjengelige?
Ofte minutter til timer. Det er det vinduet som betyr noe, fordi en build som kjører inni det allerede er påvirket uavhengig av hvor raskt pakken fjernes etterpå.
Får ondsinnede npm-pakker CVE-er?
Vanligvis ikke. De er angriperpubliserte artefakter snarere enn feil i legitim kode, og sporede kampanjer i 2026 mottok ingen CVE-tildelinger under aktiv utnyttelse.
Hvordan sjekker jeg om en pakke er skadelig før jeg installerer den?
Bruk et verktøy som analyserer pakker ved publisering i stedet for et som sjekker en liste over kjente feil, bekreft utgiver og versjonshistorikk, vær mistenksom overfor uvanlig høye versjonsnumre og helt nye kontoer, og håndhev en policy ved installasjon i stedet for å stole på gjennomgang.
Hva er avhengighetsforvirring?
Publisering av en offentlig pakke med samme navn som en intern pakke, vanligvis i en oppblåst versjon, slik at resolveren foretrekker angriperens kopi. PayPal-navneklyngen i versjon 28.0.0 er et lærebokeksempel.
