Ataques
Ataque a NPM: Se vieron comprometidos paquetes con más de 2.000 millones de descargas semanales

Escritor y editor
Actualizado
8 sept 2025
7 min
En un ciberataque sin precedentes, la cuenta de un prominente mantenedor de npm fue hackeada a través de un esquema de phishing, lo que llevó a la afectación de 18 paquetes ampliamente utilizados con más de 2 mil millones de descargas semanales combinadas. El ataque, que comenzó el 8 de septiembre de 2025, involucró la inyección de código malicioso diseñado para secuestrar transacciones de criptomonedas directamente desde los navegadores de los usuarios. Este incidente, considerado por algunas personas como uno de los ataques a la cadena de suministro más grandes de la historia, subraya los riesgos constantes y crecientes que enfrentan los desarrolladores y los usuarios finales.
El esquema de phishing y el compromiso de la cuenta
El ataque a la cadena de suministro fue iniciado por un correo electrónico de phishing meticulosamente elaborado, enviado a Josh Junon, un prolífico y confiable mantenedor de npm conocido como Qix. El correo, que provenía del dominio engañoso support[at]npmjs[dot]help —muy similar al legítimo npmjs.com—, era parte de una intimidadora táctica. Falsamente, se afirmaba que la cuenta de Junon sería bloqueada el 10 de septiembre de 2025 si no actualizaba sus credenciales de autenticación de dos factores (2FA), las cuales, según el correo, tenían más de 12 meses de antigüedad.

(Imagen tomada de GitHub.)
El sitio de phishing presentaba un formulario de inicio de sesión que, al ser enviado, exfiltraría las credenciales del usuario a una URL controlada por los atacantes. A pesar de su cautela habitual, Junon, quien estaba usando su dispositivo móvil y había tenido una semana larga y ocupada, cometió el error de hacer clic en el enlace e ingresar sus credenciales. Esta única acción otorgó a los atacantes el control total de su cuenta de npm, permitiéndoles publicar versiones maliciosas de los paquetes que mantenía. Los atacantes registraron el dominio de phishing solo tres días antes del ataque, lo que demuestra un asalto calculado y bien preparado.
Un ataque sigiloso y de amplio alcance
El compromiso fue inicialmente detectado por Aikido Security el 8 de septiembre a las 13:16 UTC. Su sistema de inteligencia señaló una serie de actualizaciones de paquetes sospechosas desde la cuenta de Junon. Al confirmar el compromiso, Aikido le notificó a Junon a través de Bluesky (quien ya estaba al tanto de la situación), y él comenzó el proceso de limpieza poco más de una hora y media después, a las 15:15 UTC. La rápida respuesta tanto de los investigadores de seguridad como del mantenedor ayudó a mitigar el daño potencial.
Los atacantes aprovecharon su acceso para inyectar código malicioso en las últimas versiones de 18 paquetes de npm muy populares. El número de descargas semanales combinadas de estos paquetes es de alrededor de 2,6 mil millones, lo que convierte a este en un ataque verdaderamente masivo.
_____
Nota: Node Package Manager (npm) es el gestor de paquetes predeterminado para Node.js, un entorno de ejecución que permite que el código JavaScript se ejecute fuera de un navegador. NPM sirve como un vasto registro público para paquetes de software y como una herramienta de línea de comandos que los desarrolladores utilizan para instalarlos y administrarlos, lo que lo convierte en la columna vertebral del ecosistema moderno de JavaScript.
_____
Los paquetes comprometidos más descargados incluyeron (el número de descargas semanales se muestra entre paréntesis):
ansi-styles (371,4 millones)
debug (357,6 millones)
chalk (300,0 millones)
supports-color (287,1 millones)
strip-ansi (261,2 millones)
ansi-regex (243,6 millones)
wrap-ansi (198,0 millones)
color-convert (193,5 millones)
color-name (191,7 millones)
is-arrayish (73,8 millones)
slice-ansi (59,8 millones)
error-ex (47,2 millones)
color-string (27,5 millones)
simple-swizzle (26,3 millones)
supports-hyperlinks (19,2 millones)
has-ansi (12,1 millones)
chalk-template (3,9 millones)
backslash (0,3 millones)
Muchos de estos son dependencias fundamentales, mantenidas conjuntamente con Sindre Sorhus, uno de los mantenedores más populares en npm. Esta profunda integración dentro del ecosistema de JavaScript magnificó el "radio de impacto" del ataque. Al comprometer una cuenta de alto perfil, los atacantes pudieron llegar a un gran número de aplicaciones y librerías que dependían indirectamente de estos paquetes.
Cómo operaba el malware
El código malicioso, el cual parece ser consistente en todos los paquetes comprometidos, fue diseñado para actuar como un interceptor basado en el navegador, apuntando a la actividad de criptomonedas y Web3. Era altamente intrusivo y sigiloso, operando en múltiples capas para evadir la detección.
La funcionalidad principal del malware implicaba un proceso de varios pasos:
Inyección y enganche: El código se inyectaba en las funciones principales de JavaScript del navegador, como fetch y XMLHttpRequest, y en APIs comunes de billeteras, específicamente en el objeto window.ethereum para billeteras compatibles con Ethereum como MetaMask, así como en las APIs utilizadas por billeteras compatibles con Solana como Phantom. Esto le permitía interceptar tanto el tráfico web como la actividad de la billetera.
Vigilancia de datos: Escaneaba las respuestas de la red y las cargas útiles de las transacciones en busca de cualquier cosa que se asemejara a una dirección o transferencia de criptomonedas. El malware era capaz de reconocer múltiples formatos en las principales cadenas, incluyendo Ethereum, Bitcoin, Litecoin, Solana y Tron.
Reemplazo de direcciones: Utilizando lógica de coincidencia de cadenas (string-matching) y listas predefinidas de direcciones controladas por los atacantes, el malware reemplazaba la dirección del receptor legítimo por una dirección "similar" de la lista de los atacantes. Esto hacía que la transacción fraudulenta fuera más difícil de detectar.
Secuestro de transacciones: Antes de que un usuario pudiera firmar una transacción, el malware alteraba los parámetros de la misma (p. ej., receptores, aprobaciones, permisos). Incluso si la interfaz de usuario mostraba el destino correcto, los datos de la transacción subyacente ya habían sido modificados para desviar los fondos a los atacantes.
Sigilo y engaño: El código estaba fuertemente ofuscado para ocultar su propósito. Usaba variables con prefijos
_0x
y un enorme arreglo de cadenas ofuscadas que se decodificaban en tiempo de ejecución. Para evitar levantar sospechas, a veces evitaba cambios obvios en la interfaz de usuario mientras secuestraba silenciosamente la transacción en segundo plano. El malware incluso devolvía una respuesta de "éxito" falsa a la aplicación, haciendo que pareciera que la transacción se había completado correctamente.
El código malicioso apuntaba específicamente a interacciones relacionadas con criptomonedas, lo que significa que no todas las aplicaciones que utilizaban los paquetes comprometidos se vieron afectadas. Según Andrew MacPherson, ingeniero principal de seguridad en Privy, se debían cumplir criterios específicos para que una aplicación fuera vulnerable, incluyendo una instalación reciente o un archivo package-lock.json creado durante el breve período en que las versiones maliciosas estuvieron activas.
Implicaciones más amplias y recomendaciones para desarrolladores
El ataque a Qix es un duro recordatorio de la creciente amenaza de los ataques a la cadena de suministro. Como lo demostraron incidentes recientes dirigidos a eslint-config-prettier y otras librerías de npm, los atacantes se están enfocando cada vez más en la cadena de suministro de software para obtener un punto de apoyo en miles de aplicaciones simultáneamente. El navegador web, con su amplia superficie de API, se ha convertido en un objetivo principal para este tipo de ataques.
Por ahora, se recomienda encarecidamente a los desarrolladores que tomen las siguientes medidas para protegerse a sí mismos y a sus usuarios:
Revertir: Retrocedan inmediatamente a una versión segura conocida de cualquier paquete comprometido. Las versiones maliciosas han sido eliminadas por el equipo de npm, pero es crucial asegurarse de que sus proyectos estén utilizando versiones seguras y previamente verificadas.
Auditar dependencias: Realicen una auditoría exhaustiva de sus archivos package.json y package-lock.json para verificar si hubo actualizaciones recientes de los paquetes afectados que pudieran haber ocurrido durante la ventana del ataque.
Monitorear transacciones: Si sus aplicaciones interactúan con billeteras de criptomonedas o APIs de Web3, monitoreen las transacciones de cerca en busca de cualquier actividad inusual.
Habilitar 2FA: Fortalezcan la seguridad de sus propias cuentas habilitando la autenticación de dos factores y usando una clave de hardware si es posible. Desconfíen extremadamente de cualquier correo electrónico, incluso aquellos que parezcan legítimos, que les pidan actualizar credenciales o hacer clic en enlaces. En su lugar, naveguen directamente al sitio web oficial.
Si bien la rápida detección y respuesta limitaron el daño general, este incidente resalta una debilidad significativa. Un solo ataque de phishing exitoso contra un mantenedor de alto perfil puede tener un efecto en cascada en todo el ecosistema de software, exponiendo potencialmente a millones de usuarios finales a pérdidas financieras. Este evento subraya la necesidad de una vigilancia continua, protocolos de seguridad mejorados y esfuerzos de colaboración entre los investigadores de seguridad, los proveedores de plataformas y la comunidad de desarrolladores para asegurar la cadena de suministro digital.
Aunque del lado de Qix el problema pareció haberse "resuelto" horas después, vale la pena mencionar que otros mantenedores de npm también se vieron afectados, como se indica aquí:

En Fluid Attacks, elogiamos la transparencia y la rápida reacción de la comunidad de desarrolladores e investigadores de seguridad al responder a este incidente. Es un testimonio del espíritu de colaboración que sustenta el mundo del software de código abierto, del cual, lo sepamos o no, dependemos casi todos en gran medida.
Aunque en este caso el ataque fue exitoso debido a un error humano en lugar de una vulnerabilidad de software, el incidente aún resalta la importancia crítica de tener una defensa sólida. En Fluid Attacks, como parte de nuestra completa solución de Hacking Continuo, además de AST automatizado y PTaaS, ofrecemos análisis de composición de software (SCA), incluyendo listas de materiales de software (SBOM), para ayudar a las empresas a rastrear y gestionar continuamente sus dependencias, identificar vulnerabilidades y proteger de manera proactiva su cadena de suministro de software.
Te invitamos a iniciar nuestra prueba gratuita de 21 días ahora mismo.
Empieza ya con el PTaaS de Fluid Attacks
Suscríbete a nuestro boletín
Mantente al día sobre nuestros próximos eventos y los últimos blog posts, advisories y otros recursos interesantes.
Otros posts