Tres vegades en vuit mesos, el mateix manual de cucs npm ha funcionat. Diferents atacants, diferents paquets, la mateixa mecànica i el mateix interval de temps entre la publicació i la detecció que han fet possible cadascun d'ells. Si us pregunteu què és realment un cuc npm i per què el patró es repeteix en comptes de solucionar-se, aquesta és la resposta honesta: incidents, mecàniques i l'únic buit que fins i tot un marc defensiu sòlid deixa obert.
Què és un cuc npm?
Un cuc npm és un fragment de codi maliciós publicat al registre npm que es propaga automàticament a altres paquets un cop s'executa, normalment robant les credencials de publicació d'un mantenidor i utilitzant-les per injectar la mateixa càrrega útil a tots els paquets que controla el mantenidor. És un "cuc" en el sentit clàssic: no espera que algú l'instal·li deliberadament, es propaga pel seu compte, paquet a paquet, compte a compte, a la velocitat de la màquina.
Aquesta autopropagació és el que separa un incident de cuc npm d'un paquet maliciós ordinari. Un sol paquet defectuós és una agulla en un paller. Un cuc npm converteix cada mantenidor compromès en un nou punt de distribució, i el paller comença a generar les seves pròpies agulles.
Els incidents de cucs npm més grans fins ara
L'any passat va donar al patró de cuc npm tres proves del món real, cadascuna més eficient que l'anterior:
- Shai-Hulud (setembre de 2025). El primer cuc npm autopropagant documentat. Comprometia les credencials del mantenidor i després les utilitzava per publicar versions malicioses de cada paquet sota el control d'aquest mantenidor, convertint els mateixos desenvolupadors en el mecanisme de lliurament per a la següent etapa del cuc.
- axios (març de 2026). El programari maliciós d'estat-nació amagat dins d'un paquet s'extreia aproximadament 100 milions de vegades per setmana. No és un cuc en el sentit estricte de propagació, sinó una prova que el mateix model de confiança d'ecosistema npm que Shai-Hulud va explotar podria transportar una càrrega útil a una escala realment massiva.
- SAP npm (abril de 2026). Descrit en aquell moment com un mini Shai-Hulud: el mateix patró de cuc, repetit a escala, menys d'un any després de l'incident original. El mecanisme no havia canviat. Les defenses en general tampoc.
Tres incidents amb cucs npm, un patró repetitiu: comprometre un editor de confiança, utilitzar les seves credencials per propagar-se automàticament i comptar amb la bretxa entre la publicació i la detecció de la comunitat per fer la resta.
El patró que es repeteix
Si eliminem els detalls específics, cada incident amb cucs npm segueix els mateixos quatre ritmes:
- Compromís del compte. El token de publicació d'un mantenidor, npm login, o les credencials de CI són robades, normalment a través de phishing, un secret filtrat o una dependència compromesa més amunt de la seva pròpia cadena.
- Injecció silenciosa. L'atacant envia una nova versió d'un paquet legítim i de confiança amb codi maliciós afegit, sovint dins d'un script de postinstal·lació o un altre script del cicle de vida que s'executa automàticament en el moment en què algú l'instal·la.
- Propagació automàtica. Si el mantenidor compromès controla altres paquets, o si el mateix script maliciós recopila més credencials, el cuc es propaga al següent paquet i al següent mantenidor sense que l'atacant faci més coses.
- El retard de detecció. El paquet es troba actiu al registre, qualsevol persona el pot instal·lar, fins que algú ho nota, ho informa i s'extreu. Aquest retard, hores per a alguns incidents, dies per a altres, és tota la finestra que necessita el cuc.
Reconèixer aquest quart cop és el que realment importa per a la defensa. Cada estratègia de mitigació per a un incident de cuc npm és, en essència, un intent de reduir o evitar aquest retard de detecció.
Un marc de treball que val la pena citar: la resposta de SIP al problema del temps de refredament
No totes les respostes a aquest patró provenen d'un proveïdor. Una de les més clares és SIP, Pla de seguretat immediata de Mohammad-Ali A'râbi, un marc d'emergència de cinc controls per al risc de la cadena de subministrament de programari que va sorgir d'una pregunta molt pràctica formulada al final d'una sessió de SafeDev: "Si només podem fer unes poques coses, què hauríem de fer primer?"
El segon control de SIP està dirigit directament al problema del cuc npm: congelar les dependències no verificades amb un període de refredament de cinc dies i desactivar els scripts del cicle de vida perquè una postinstal·lació maliciosa no es pugui executar automàticament durant la instal·lació. A la pràctica, això és... min-release-age=5 i ignore-scripts=true en un projecte .npmrc, aplicat a CI perquè un fitxer de bloqueig no pugui resoldre discretament un paquet publicat ahir. És un control realment sòlid i de baix esforç, i ataca directament el mateix retard de detecció del qual depèn cada incident de cuc npm. Submergeix-te en:
On la finestra de refredament encara deixa un buit
Un període de refredament és una aposta: que la comunitat notarà i informarà d'un paquet maliciós abans que acabi el període d'espera. La majoria de les vegades, aquesta aposta té èxit. Una part significativa dels paquets compromesos es marquen durant els primers dies de la publicació, i és precisament per això que una finestra de cinc dies és un valor predeterminat raonable.
Però un cuc npm no es comporta com un paquet maliciós típic, i això canvia el que un temps de reutilització fix pot i no pot fer per tu.
Estar precise sobre la velocitat: Un cuc que es propaga ràpidament no anul·la realment el temps de recàrrega. Si imposes una edat mínima de llançament estricta, els paquets publicats durant aquesta onada inicial encara són massa nous per entrar en una compilació, independentment de quants paquets comprometi el cuc mentrestant. La velocitat importa, però importa per a tots els que segueixen endavant i no estan executant un temps de recàrrega, no per superar-ne un que ja està aplicat.
La veritable limitació és la paciència. Una càrrega útil més acurada pot romandre inactiva després del període de refredament, activant-se només un cop passats els dies i el paquet hagi envellit a la zona de "confiança", prèviament.cissimplement perquè sap que un temps de reutilització està vigilant. Aquest és l'escenari en què un temps de reutilització fix per si sol no és suficient, i exactament on alguna cosa com la detecció basada en proves de MEW ha d'anar al seu costat, no en lloc d'ella.
Cap dels dos modes de fallada és una falla en el pensament de SIP. Un temps de refredament és una aposta de detecció comunitària, i la detecció comunitària té un límit: no pot detectar allò que ningú ha informat encara. Aquesta no és una bretxa exclusiva de SIP, és un límit estructural de qualsevol defensa que espera que existeixi una signatura, un avís o un informe públic abans d'actuar.
Com MEW tanca la bretxa de la finestra de temps de reutilització
Això és previcisEly la bretxa Alerta precoç de programari maliciós (MEW) de Xygeni està dissenyat per tancar-se. En lloc d'esperar informes de la comunitat o una signatura publicada, MEW escaneja contínuament NPM, PyPI i Maven a mesura que es publiquen nous paquets i versions, analitzant el comportament en lloc de comparar-lo amb les amenaces conegudes. Quan alguna cosa sembla maliciosa, es posa en quarantena i els investigadors de seguretat confirmen la troballa abans de la divulgació pública, no després.
Aquesta distinció és important per als dos modes de fallada del cuc npm esmentats anteriorment. Contra un cuc de propagació ràpida, la detecció prèvia a la signatura no necessita els cinc dies que suposa un temps de recàrrega. Contra una càrrega útil pacient i inactiva, l'anàlisi del comportament de MEW no busca l'edat ni la reputació, sinó què fa realment el codi, de manera que esperar un període de recàrrega no li compra res a un atacant.
El tallafocs de dependències de MEW estén això fins al punt de la instal·lació mateixa, bloquejant un paquet maliciós en temps real fins i tot si ha passat per alt les comprovacions anteriors, i la mateixa capa de detecció cobreix el CI/CD costat d'un incident de cuc npm: el patró unlock-branch, inject, re-lock que permet a un atacant impulsar un fitxer maliciós commit i cobrir discretament les seves petjades, amb una pista d'auditoria completa si passa de totes maneres.
SIP i MEW responen a la mateixa pregunta, en capes diferents
Res d'això fa que el control del temps de recàrrega de SIP sigui incorrecte, i val la pena dir-ho clarament: un temps de recàrrega de cinc dies amb els scripts del cicle de vida desactivats continua sent una de les defenses més ràpides i econòmiques que un equip pot implementar contra un incident ordinari de cuc npm, i pertany a qualsevol pla seriós d'enduriment de la cadena de subministrament. El que no pot fer, per disseny, és detectar el que la comunitat encara no ha trobat. Aquesta és una feina per a la detecció contínua basada en el comportament que s'executa per sota del temps de recàrrega, no en lloc d'ell.
En capes, els dos enfocaments cobreixen els dos extrems del mateix problema: SIP endureix la construcció pipeline, la congelació de dependències i la imatge del contenidor al voltant d'un panorama d'amenaces conegut i revelat, mentre que la detecció prèvia a la signatura de MEW cobreix els incidents de cucs npm que encara no s'han revelat, aquells que una finestra de refredament, per la seva pròpia lògica, no pot preveure.
FAQ
Què és un cuc npm, en una frase?
Codi maliciós publicat a npm que es propaga automàticament a altres paquets, normalment robant les credencials d'un mantenidor i utilitzant-les per injectar la mateixa càrrega útil en un altre lloc, sense cap altra acció per part de l'atacant.
És cada paquet npm maliciós un cuc npm?
No. Un paquet maliciós que no es propaga pel seu compte és un atac a la cadena de subministrament, però no un cuc. El que defineix específicament un incident de cuc npm és el pas d'autopropagació: un compromís condueix automàticament al següent.
Un període de refredament de dependències atura un cuc npm?
Redueix significativament el risc, ja que la majoria de paquets maliciosos es registren durant els primers dies de publicació. Però un temps de recàrrega és una aposta per la velocitat de detecció de la comunitat, i es pot construir un cuc npm de propagació ràpida o deliberadament inactiu específicament per superar aquesta finestra.
Què és el que realment atrapa un cuc npm abans d'un període de refredament?
Escaneig continu basat en el comportament que no depèn d'una signatura o d'un informe públic que ja existeixi. Aquesta és la bretxa específica que les eines de detecció de presignatures com el MEW de Xygeni estan dissenyades per tancar.
