Más de mil paquetes NPM maliciosos propagan RAT y roban datos

Una campaña a gran escala convirtió el registro de npm en una cinta de correr de distribución de malware para Windows, macOS y Linux. El caso empezó a llamar la atención el 5 de agosto de 2026, cuando los investigadores identificaron cientos de componentes vinculados al mismo cargador. El recuento inicial de casi 800 paquetes creció y alcanzó1.033 componentes confirmados, según la actualización más reciente de la investigación.

El número da miedo, pero el aspecto más importante está en el modo de activación. Parte de los paquetes no dependía de los scripts bien conocidospreinstallopostinstall. El código malicioso podía empezar a funcionar cuando el desarrollador seguía la guía del README e importaba la biblioteca conrequire(). En la práctica, una dependencia aparentemente común obtenía acceso al mismo entorno que el proyecto, incluyendo archivos, variables y credenciales disponibles en ese proceso.

Esto cambia la cuestión de seguridad. No te limites a comprobar si un paquete ejecuta algo durante la instalación. También necesitas saberloQué hace cuando introduce el código.

Cómo se descubrió la campaña

El 5 de agosto, Sonatype comenzó a acompañar al grupo bajo el nombreGotero de inundación. Al día siguiente, OpenSourceMalware publicó un análisis de la misma operación, que sus investigadores denominanWEL1DROPPER. En ese momento, se habrían publicado más de 700 paquetes en unas 48 horas.

La escala aumentó rápidamente. Sonatype relacionó 846 componentes con la campaña, mientras que Socket contó 865 artefactos, correspondientes a 789 paquetes únicos. El 11 de agosto, una actualización citada por The Hacker News elevó el total confirmado a 1.033.

Estos números no son necesariamente contradictorios. Cada empresa puede contar versiones únicas, artefactos o paquetes de forma diferente, y la eliminación de publicaciones maliciosas ocurre al mismo tiempo que se descubren nuevas muestras. Lo que queda claro es que no se trataba de un paquete aislado, sino de una operación automatizada distribuida entre varias cuentas desechables.

La estafa empezó con el nombre y el README

Los nombres mezclaban términos técnicos, comerciales y palabras recurrentes en combinaciones que parecían plausibles a primera vista. Los investigadores describen parte de este patrón comoSentadillas de IA, una variante del typosquatting en la que se pueden registrar nombres extraños o sugeridos por herramientas de IA antes de que el desarrollador se dé cuenta de que la biblioteca nunca existió realmente.

El README completó la trampa. En lugar de presentar una función claramente sospechosa, enseñó cómo importar el módulo como cualquier SDK. La llamada cargó un archivo auxiliar y comenzó la cadena de infección inmediatamente.

Así que desactivar los scripts de instalación sigue siendo una buena capa de protección, peroNo bloquearía este ataque solo. El paquete podría estar en silencio durante elnpm instally actuar durante una prueba, un arranque local, una compilación o la ejecución del servidor.

Qué ocurrió después de la importación

Una vez cargado, la primera etapa identificaba el sistema operativo y la arquitectura del procesador. Luego intentaba descargar un ejecutable compatible con Windows, macOS o Linux desde diferentes direcciones HTTPS.

Si la conexión directa fallaba, había una segunda ruta: consultas DNS del tipo TXT. Se recuperaban, recogían y escribían fragmentos codificados del archivo en una carpeta temporal. El proceso entonces comenzaba en segundo plano, separado del Node.js que había hecho la importación.

Esta separación es importante. Cierra el terminal, detén elnpm installo terminar la aplicación no garantiza que el binario descargado se haya detenido. Puede permanecer activo, establecer persistencia y buscar nuevas etapas.

Las reseñas públicas describen diferentes comportamientos según la plataforma:

en Windows, el malware busca dificultar la inspección, escanea entornos de análisis e intenta mantener la persistencia mediante registros y tareas programadas;
en macOS, hay comprobaciones contra la depuración y el uso de LaunchAgent para persistencia;
en Linux, los investigadores observaron un ejecutable empaquetado que ofrece un despliegue del framework Sliver.

El posible resultado coincideAcceso remotoejecución de nuevas cargas útiles y robo de información. Esto pone en riesgo tokens npm y GitHub, claves de servicios en la nube, secretos CI/CD y otros datos que a menudo están disponibles en máquinas de desarrollo.

Por qué importa el número de paquetes

La campaña diluyó las publicaciones en varias cuentas, muchas de ellas responsables de algunos paquetes. El código también recibió cambios menores en los nombres de funciones y variables, aunque mantuvo el mismo comportamiento.

Esta estrategia aumenta el trabajo de moderación. Eliminar una cuenta o bloquear una firma exacta no pone fin a la operación. Cuando aparecen cientos de variaciones casi al mismo tiempo, las listas de nombres conocidos envejecen rápidamente.

El caso también expone un riesgo creciente de desarrollo asistido por IA. Un modelo podría sugerir un nombre convincente que no coincide con una biblioteca real. Si alguien registra ese nombre con antelación, una recomendación inventada pasa de producir solo un error a señalar código hostil.

Esto no significa que todas las sugerencias de IA sean peligrosas. Significa queLa recomendación no sustituye la verificación del envase, su autor y su origen.

Qué hacer si el paquete ha llegado al proyecto

Eliminar la dependencia depackage.jsonno es una respuesta suficiente si ha sido importado o ejecutado. La recomendación de Sonatype es tratar el equipo afectado como comprometido.

Una respuesta prudente sigue este orden:

aislar la estación, el runner de CI o el servidor sospechoso de la red;
Consulta los archivos de bloqueo, cachés, imágenes de contenedores y espejos internos con la lista actualizada de indicadores proporcionada por los investigadores;
buscar procesos derivados de Node.js, ejecutables en directorios temporales, persistencia y consultas DNS inusuales;
Reconstruir el entorno desde una base de confianza cuando haya confirmación o fuerte sospecha de ejecución;
solo después de borrar, revocar sesiones e intercambiar tokens desde npm, GitHub, cloud, claves CI/CD, SSH y otros secretos expuestos;
Revisa los registros para averiguar si se han utilizado credenciales comprometidas en otra máquina o servicio.

El intercambio de credenciales debe realizarse desde un dispositivo limpio. Hacer esto antes de eliminar el malware puede simplemente entregar los nuevos secretos al atacante.

Cómo reducir el riesgo antes de la próxima instalación

Ninguna herramienta por sí sola resuelve un ataque a la cadena de software, pero algunas prácticas reducen bastante la superficie:

Confirma la ortografía, el mantenedor, el repositorio e historial del paquete antes de añadirlo;
ten cuidado con las bibliotecas recién publicadas con nombres extraños o documentación que no coincida con el código;
añadir nuevas dependencias mediante revisión de código, en lugar de instalar directamente por sugerencia de una IA;
Conserva el archivo de bloqueo y usanpm cien automatizaciones para evitar cambios inesperados en el árbol ya aprobado;
mantener a los runners de CI efímeros y con el menor número posible de secretos y permisos;
Monitorizar procesos hijos, accesos a la red y consultas DNS iniciadas por herramientas de compilación;
Verifica firmas y atestigos de procedencia connpm audit signaturescuando esté disponible;
Usonpm auditpara vulnerabilidades conocidas, sin tratarlo como un detector de malware recién publicado en toda regla.

La procedencia ayuda a confirmar dónde y cómo se generó una liberación. Es una prueba valiosa, pero no demuestra por sí sola que el comportamiento del paquete sea seguro. El código, los permisos y la necesidad real de la dependencia aún deben revisarse.

Lo que enseña este caso

El WEL1DROPPER muestra que la confianza en una dependencia comienza antes de la instalación y continúa durante la ejecución. Los controles de script, listas de bloqueo y escáneres son importantes, pero pierden fuerza cuando la trampa usa nombres nuevos, demasiadas cuentas y código que solo se despierta al principiorequire().

Para equipos pequeños, la medida más eficaz puede ser también la más sencilla:Añadir menos dependencias y comprender cada nueva biblioteca antes de incorporarla. Para las empresas, la misma idea debe convertirse en un proceso, con aprobación, observabilidad, entornos desechables y una respuesta preparada para el compromiso de credenciales.

El registro npm elimina paquetes maliciosos cuando se identifican, pero la magnitud de esta campaña deja una lección incómoda. El código abierto sigue siendo esencial para el desarrollo moderno, pero importar una biblioteca garantiza la ejecución dentro de tu proyecto. Esta decisión merece la misma atención que se presta a cualquier otro software instalado en la máquina.

Fuentes consultadas

El recuento se completó el 23 de agosto de 2026. Los totales pueden cambiar a medida que se identifiquen o eliminen nuevas muestras del registro.