← Volver al blog
#Ciberseguridad#Cadena de suministro#npm#Desarrollo de software#JavaScript

Secuestran un paquete npm de una plataforma de IA para robar credenciales: qué revisar hoy en tus proyectos JavaScript

Escritorio en penumbra con un monitor que muestra código JavaScript en Visual Studio Code, un teclado iluminado, una lámpara encendida y, a la izquierda, una laptop con la imagen de una figura encapuchada

El jueves 8 de octubre de 2026, a las 01:12 UTC (las 20:12 del miércoles en Ecuador), apareció en npm la versión 0.5.144 del paquete tensorlake, el SDK de TypeScript de Tensorlake, una plataforma para construir agentes de IA. No era una actualización normal: traía una variante del gusano Shai-Hulud, un malware que roba credenciales de desarrolladores y se copia solo a otros paquetes. Lo reportaron, con detalles que coinciden, Socket, Aikido y Endor Labs.

Si tu equipo no usa tensorlake, este caso igual te sirve: es el mismo tipo de ataque que ya golpeó a otros paquetes populares y que va a volver a pasar.

Qué pasó

Según Aikido y GBHackers, el 7 de octubre el atacante hizo commits en el repositorio de GitHub del proyecto con la identidad de un mantenedor. Al día siguiente, el propio flujo de publicación del proyecto subió la versión infectada a npm. Socket y Endor Labs coinciden en que la causa más probable es una cuenta de mantenedor comprometida: el atacante no tuvo que romper npm, le bastó con entrar por la puerta de alguien de confianza.

Socket dice que detectó el paquete 11 minutos después de su publicación. Aikido y Endor Labs informan que la versión ya fue retirada del registro de npm, y Endor Labs indica que la 0.5.143 y las anteriores no contienen el código malicioso.

Por qué es peligroso aunque no uses el paquete en tu código

El malware se activa con un script preinstall: corre en el momento de hacer npm install, antes de que alguien importe o ejecute nada. Basta con que la versión 0.5.144 se haya instalado en una laptop o en un servidor de integración continua (CI). Una vez dentro, según los análisis publicados:

  • Busca credenciales: tokens de npm y de GitHub, llaves SSH, credenciales de AWS, Google Cloud y Azure, configuración de Kubernetes y Docker, archivos .env y secretos de CI/CD. Socket añade que también busca la configuración de herramientas de IA para programar.
  • Roba criptomonedas: revisa extensiones de billeteras en el navegador.
  • Se propaga: con los tokens de npm robados, publica versiones infectadas de otros paquetes que mantiene la víctima. Así un solo desarrollador infectado puede contagiar a sus propios usuarios.
  • Tiene un "interruptor de hombre muerto": Aikido, Socket y GBHackers advierten que puede borrar datos del equipo infectado si detecta que se revocó el token que usa. Por eso el orden de la limpieza importa.

Cómo saber si te afectó

  1. Busca el paquete en tus proyectos: npm ls tensorlake en cada repositorio, y busca tensorlake y 0.5.144 en los archivos de bloqueo (package-lock.json, pnpm-lock.yaml, yarn.lock).
  2. Revisa tu CI: los registros de los trabajos que instalaron dependencias desde el 8 de octubre, sobre todo los que no usan archivo de bloqueo o que actualizan versiones solas.
  3. Revisa tus cuentas: versiones de tus paquetes de npm que nadie de tu equipo publicó y repositorios nuevos en tu cuenta u organización de GitHub que nadie creó.

Si lo instalaste: el orden importa

  1. Aísla el equipo o el runner y trátalo como comprometido, como recomiendan Socket, Aikido y GBHackers.
  2. Quita primero la persistencia del malware y después revoca los tokens. Socket lo marca como crítico: si revocas antes, el interruptor puede borrar los directorios del usuario. Si no tienes experiencia en esto, pide ayuda antes de tocar nada.
  3. Cambia todas las credenciales a las que tenía acceso ese equipo: npm, GitHub, llaves SSH, nube, bases de datos y todo lo que estuviera en archivos .env.
  4. Fija la versión limpia (0.5.143 o anterior, según Endor Labs) o espera una versión nueva verificada por el proyecto, y reconstruye desde un origen confiable.

Cómo prevenir el próximo

  • Usa siempre archivo de bloqueo e instala con npm ci en CI, para que nunca entre una versión que nadie revisó.
  • Desactiva los scripts de instalación donde puedas, con npm install --ignore-scripts o ignore-scripts=true en .npmrc, como sugiere Endor Labs, y habilítalos solo para los paquetes que de verdad los necesitan.
  • Tokens con el mínimo permiso y de corta duración, nunca guardados en texto plano en la laptop. Activa la verificación en dos pasos en npm y GitHub para todo el equipo.
  • Activa alertas de dependencias en tu repositorio para enterarte rápido cuando una versión se marca como maliciosa.

Qué significa para tu empresa

Si tu empresa encarga software, este tipo de ataque no le pega a tu sistema por una falla en tu código, sino a través de las herramientas de quien lo construye. Vale la pena hacerle tres preguntas a tu equipo o a tu proveedor de desarrollo: ¿usan archivos de bloqueo y revisan las actualizaciones de dependencias?, ¿dónde guardan las credenciales de producción y quién las tiene en su laptop?, y ¿qué harían en la primera hora si una dependencia sale infectada? Si las respuestas tardan, ahí tienes trabajo pendiente.

Cómo lo abordamos en SimCodec

En SimCodec hacemos desarrollo de software a medida con dependencias fijadas, CI que instala sin scripts innecesarios y credenciales fuera de las laptops del equipo. También revisamos proyectos existentes: inventario de dependencias, configuración de npm y de CI, y plan de respuesta si algo sale mal.

Si quieres revisar tus proyectos JavaScript o los de tu proveedor, escríbenos o llama a nuestra asistente de IA Cyntia al +593 99 726 6838.

← Volver al blog Cotiza tu proyecto →