TL; DR
Los paquetes npm maliciosos no son un hecho aislado. Se trata de una operación de publicación continua, y la lista de casos confirmados se actualiza cada semana. A lo largo de siete ediciones consecutivas de nuestro Resumen de Código Malicioso, que ya supera la 87.ª, Xygeni confirmó 635 paquetes maliciososDesde 13 en una semana tranquila hasta 206 en una semana ajetreada. La clave está en el rango semanal: se trata de una cadencia, no de un incidente aislado.
- El problema es el ritmo. Un paquete pasó de cero a más de 55 versiones en una semana. Otro grupo publicó casi 30 nombres de paquetes en menos de tres horas. Una auditoría semanal no es la unidad de tiempo adecuada.
- No llegan como CVE. Un paquete malicioso no es una vulnerabilidad en el código legítimo, por lo que no hay avisos, ni puntuación, y generalmente ni siquiera un identificador. Un programa basado en vulnerabilidades es inherentemente ajeno a esto.
- La eliminación no es protección. Los paquetes suelen estar disponibles durante minutos u horas. La instalación se realizó dentro de ese lapso o no.
- La detección debe realizarse en el momento de la publicación, y la aplicación en el momento de la instalación. Todo aquello que requiere una firma, una vulnerabilidad CVE o un análisis semanal llega después de la compilación que lo descargó.
La lista existe. Eso no es lo mismo que estar siendo vigilado.
No hay misterio alguno sobre los paquetes npm maliciosos. Los casos confirmados se publican, se nombran y se documentan cada semana, incluso en El propio resumen de código malicioso de Xygeni, que ya ha superado su octogésima séptima edición.
La brecha no radica en la información, sino en la atención y la frecuencia. Una lista actualizada semanalmente, leída mensualmente y revisada trimestralmente documenta lo que ya le sucedió a alguien.
Así transcurrieron siete semanas, según nuestros propios hallazgos confirmados y no a partir de una encuesta a un proveedor.
Lo que importa no son los totales, sino la velocidad que se mantiene cada semana.
La velocidad es todo el ataque.
Tres hallazgos de esas semanas, cada uno una forma diferente de eludir la revisión.
- Inundación de versiones. Un único paquete npm,
zevairouter, alcanzó más de 55 versiones confirmadas en una semana, a las que se unieron diez más de un paquete complementario. En PyPI,bingo-aiProdujo casi 80 versiones en aproximadamente 30 minutos. Ningún proceso de revisión manual funciona a esa velocidad, ni siquiera un trabajo nocturno. - Clústeres sincronizados. Diecisiete paquetes que suplantaban nombres de servicios internos de PayPal se publicaron en los mismos minutos, todos en la versión 28.0.0. Eso no es volumen, es una carrera: existe un número de versión inflado para superar en prioridad al paquete interno que escribieron sus propios equipos. El mismo truco reapareció semanas después con
@umschool/platformPublicado en 999.0.0. - Persistencia a través del derribo. La campaña de suplantación de identidad de Baileys lleva semanas en marcha. Los nombres cambian, las versiones se multiplican y la republicación continúa tras su detección. Un operador que considera las retiradas de contenido como un coste más de su actividad, en lugar de un motivo para detenerse, es un operador que su revisión trimestral jamás podrá detectar.
Además, el tiempo de permanencia es corto por diseño. En un grupo reciente, los paquetes estuvieron activos entre 17 minutos y 13 horas antes de ser eliminados.
Interpreta eso como un período de exposición, más que como una métrica de rendimiento para el registro. Si se ejecutaba una compilación durante ese período, la eliminación no cambiaba nada.
Por qué su programa de vulnerabilidad no ve esto
Este es el punto estructural, y es el que la mayoría de los equipos de seguridad no han interiorizado.
Una vulnerabilidad es un fallo en el código que alguien escribió de buena fe. Un paquete malicioso es un artefacto publicado deliberadamente por un atacante, generalmente sin identificador, sin aviso previo y con una vida útil de solo unas horas. Todos los procesos basados en la recopilación de CVE, la puntuación de gravedad y los plazos de aplicación de parches se diseñaron para lo primero y se aplicaron a lo segundo por defecto.
La ausencia de un identificador no es un descuido en el sistema CVE. Es la categoría funcionando como está diseñada: nadie presenta un aviso contra un artefacto cuyo propósito completo era malicioso, y para cuando alguien podría hacerlo, el paquete ya no existe. Lo que significa que la pregunta “¿Tiene esto un CVE?” devuelve la misma respuesta tanto para un paquete limpio como para un programa de robo de credenciales publicado hace una hora.
¿Qué hacen realmente las cargas útiles ahora?
La imagen simplista que se tiene de los paquetes npm maliciosos es la de un minero de criptomonedas. La realidad actual es el robo de credenciales dirigido a desarrolladores, y cada vez más a las credenciales de IA en sus máquinas.
El Sincronización fantasma El clúster, compuesto por ocho paquetes npm publicados bajo una misma cuenta, funcionó exactamente como se anunciaba, ocultando un dropper auto-invocable que se ejecutaba aproximadamente 37 segundos después de la importación, decodificaba una carga útil simulada como un entorno de prueba, instalaba persistencia multiplataforma y lanzaba un programa para robar carteras y Secretos. Retraso, disfraz, persistencia, exfiltración.
A mayor escala, la ola CHAINDROP de la Gusano Shai-Hulud A principios de agosto de 2026, alcanzó más de 400 paquetes y 1,700 versiones, con un total de 1.3 millones de descargas mensuales. Su recolector escaneó más de 300 patrones de credenciales, incluyendo OpenAI, Anthropic y teclas de cursor. Las máquinas de los desarrolladores se volvieron valiosas antescisdebido a las credenciales de modelo que llevan consigo.
Las convenciones de nomenclatura han seguido la estela del dinero. Los clústeres recientes imitan SDK de criptomonedas y DeFi, módulos de pago, bibliotecas de API de WhatsApp, utilidades de AWS y, en un caso, un paquete abiertamente identificado con el nombre de una herramienta de ataque de LLM oscura.
¿Qué es lo que realmente detiene los paquetes npm maliciosos?
Cuatro controles, en el orden en que resultan rentables.
1. Detección en el momento de la publicación, no en el de la divulgación. Alerta temprana de malware de Xygeni Analiza los paquetes recién publicados en npm, PyPI, Maven y otros registros en el momento en que aparecen, utilizando análisis de comportamiento y de anomalías en lugar de esperar una firma o un informe. Ese es el único punto en la línea de tiempo que se adelanta a tu compilación.
2. Aplicación de la normativa en el lugar donde se realiza la instalación. La detección indica que un paquete es malicioso. Una política que bloquea la instalación impide que se ejecute el script posterior a la instalación. Esto cobra mayor importancia ahora que los agentes instalan dependencias sin la intervención humana.
3. Archivos de bloqueo y fijación de hash. Usar npm ci en CI en lugar de npm installPor lo tanto, se construye el árbol de dependencias exacto en el archivo de bloqueo. Esto cierra la ruta de sustitución en la que se basan las versiones con errores tipográficos y las versiones infladas.
4. Todos los resultados en un solo lugar. Los hallazgos de malware pertenecen a la misma cola priorizada que su SCA y los hallazgos de código, no en un feed aparte que alguien hojea. Una dependencia maliciosa confirmada debería tener mayor prioridad que una CVE de gravedad media, y solo un modelo de riesgo compartido permite esa comparación.
Vigila la lista o automatízala.
Nadie tiene la paciencia para leer un registro público cada semana. Ese es precisamente el objetivo de automatizarlo.
Xygeni analiza los paquetes recién publicados en npm y otros registros en el momento de su publicación, detecta el malware confirmado antes de que llegue a una compilación y coloca el hallazgo en la misma cola de prioridad que todo lo demás con lo que sus equipos ya trabajan. Detección de malware Está incluido en el plan gratuito para desarrolladores, lo cual no ocurre con la mayoría de los planes gratuitos de esta categoría.
Empieza gratiso leer Resumen de código malicioso de esta semana de antemano.
Preguntas Frecuentes
¿Qué son los paquetes npm maliciosos?
Paquetes publicados en el registro npm que se crean deliberadamente para causar daño: ladrones de credenciales y monederos, puertas traseras, programas de descarga y artefactos que generan confusión de dependencias y que suplantan nombres de paquetes internos o populares.
¿Con qué frecuencia se encuentran paquetes npm maliciosos?
De forma continua. En siete ediciones recientes de nuestro Resumen de Código Malicioso, Xygeni confirmó 635 paquetes maliciosos, que van desde aproximadamente una docena en una semana tranquila hasta más de 200 durante campañas activas. npm representa la gran mayoría.
¿Cuánto tiempo permanecen disponibles los paquetes npm maliciosos?
A menudo, de minutos a horas. Ese lapso de tiempo es lo que importa, porque una compilación que se ejecuta dentro de ese lapso ya se ve afectada, independientemente de la rapidez con que se elimine el paquete posteriormente.
¿Los paquetes npm maliciosos tienen vulnerabilidades CVE?
Por lo general, no. Se trata de artefactos publicados por el atacante, no de fallos en código legítimo, y las campañas de 2026 rastreadas no recibieron ninguna asignación de CVE durante la explotación activa.
¿Cómo puedo comprobar si un paquete es malicioso antes de instalarlo?
Utilice una herramienta que analice los paquetes en el momento de su publicación en lugar de una que consulte una lista de paquetes defectuosos conocidos, verifique el editor y el historial de versiones, desconfíe de los números de versión inusualmente altos y de las cuentas completamente nuevas, y aplique una política en el momento de la instalación en lugar de depender de una revisión.
¿Qué es la confusión de dependencias?
Publicar un paquete público con el mismo nombre que uno interno, generalmente en una versión inflada, de modo que el resolvedor prefiera la copia del atacante. El clúster con el nombre PayPal en la versión 28.0.0 es un ejemplo clásico.
