tensorlake@0.5.144: el gusano Shai-Hulud toma de rehén el token de GitHub

El gusano Shai-Hulud tiene un nuevo anfitrión. tensorlake@0.5.144, el SDK de npm de la infraestructura de agentes de IA y procesamiento de documentos de Tensorlake, se publicó con una carga útil que roba credenciales y se republica a sí misma, y esta variante añade algo que las oleadas anteriores no tenían: un interruptor de hombre muerto que borra tu directorio personal si revocas el token que robó.

Es un incidente en desarrollo y todavía se está reconstruyendo la imagen completa, así que mantendremos la disciplina habitual: qué está confirmado, qué está informado o es preliminar y, después, qué debería hacer de verdad un responsable de seguridad, en el orden correcto, porque esta vez el orden importa.

Lo que está confirmado

• Se publicó una versión maliciosa. tensorlake@0.5.144 lleva un gusano de la familia Shai-Hulud / ChainDrop, señalado por Socket y StepSecurity el 8 de octubre de 2026. StepSecurity indica la 0.5.143 como versión segura que fijar.
• Cómo se ejecuta. Un hook preinstall ejecuta setup.mjs. El script detecta la CI y se salta a sí mismo allí: este apunta a los portátiles de los desarrolladores, no a los runners. Descarga el runtime Bun y lo usa para ejecutar una carga útil ofuscada de unos 856 KB colocada en typescript/lib/.
• Qué se lleva. Tokens de GitHub y npm, claves de nube, secretos de Kubernetes y Vault, claves SSH, inicios de sesión guardados en el navegador y los archivos de configuración de herramientas de programación con IA (Claude, Cursor y Windsurf), que cada vez guardan más claves de API propias.
• Cómo se propaga. Con un token de npm robado, descarga los propios paquetes de la víctima, se inyecta, sube la versión y los republica. Es la firma de Shai-Hulud: cada mantenedor infectado se convierte en un nuevo publicador.
• El token como rehén. Instala un servicio persistente «gh-token-monitor». Si se revoca el token de GitHub robado, el servicio ejecuta rm -rf contra el directorio personal. Lo primero que hace la mayoría tras un robo de credenciales es ahora lo que destruye la máquina.
• Parecía legítimo. Socket informa de que la release salió por el propio flujo de releases del repositorio y por eso lleva una atestación de procedencia de npm válida. La procedencia demuestra dónde se compiló un paquete, no que el código del que se compiló estuviera limpio.

Lo que está informado o aún es preliminar

• Acceso inicial. La información describe que el atacante obtuvo acceso al repositorio de GitHub de tensorlake e introdujo el código mediante commits verificados de mantenedores y una subida directa de un archivo, y que la publicación en npm llegó unas 20 horas después. Trata la cronología como informada, no como forense definitiva.
• Mando y control. La dirección de C2 se resuelve a través de una cartera de Ethereum controlada por el atacante, una técnica vista en oleadas anteriores; la transacción más reciente apuntaba a iseekaigogo[.]com. Cuenta con que cambie.
• Indicadores de detección temprana. El archivo preinstall setup.mjs es el marcador más claro. El triaje inicial también ha señalado un archivo Math_Symbol.js dentro del paquete; aún no hemos visto ese nombre de archivo confirmado de forma independiente en un análisis publicado, así que trátalo como una pista que comprobar en la lista de archivos del paquete y no como un IOC asentado.
• Radio de impacto. Aún no se sabe en cuántos paquetes posteriores se ha republicado el gusano. La respuesta honesta hoy es «en más que tensorlake».

El detalle que debería cambiar tu runbook: el orden de las operaciones

Todo playbook de incidentes dice revoca primero. Esta variante está hecha para castigar eso. El servicio gh-token-monitor es persistencia más una trampa: consulta el token de GitHub robado y, en cuanto deja de funcionar, borra ~/. Así que la secuencia tiene que ser: encontrar el implante → eliminar la persistencia (y conservar las evidencias si las necesitas) → después revocar y rotar. La advertencia de Socket es tajante: quitar la dependencia de npm no elimina el implante.

La idea de fondo es la misma que planteamos con @subql hace dos días y con keyv antes: ya no es un problema de secretos filtrados, es un problema de confianza y radio de impacto. Una atestación de procedencia válida en una release maliciosa es la prueba.

El playbook del defensor

• ☐ Encuéntralo. npm ls tensorlake en cada repositorio y cada máquina de desarrollo; busca 0.5.144 en package-lock.json, pnpm-lock.yaml y yarn.lock. No olvides las dependencias transitivas ni lo que haya instalado en tu nombre un agente de programación con IA.
• ☐ Elimina la persistencia antes de revocar. Localiza y detén el servicio gh-token-monitor en cualquier host que ejecutara la instalación, y después rota las credenciales de GitHub, npm, nube, Kubernetes, Vault, SSH y las guardadas en el navegador. En ese orden.
• ☐ Fija y bloquea. Fija la 0.5.143 (o elimina la dependencia) y ejecuta las instalaciones con --ignore-scripts por defecto (existen los equivalentes de pnpm y yarn), permitiendo solo los pocos paquetes que de verdad necesitan hooks del ciclo de vida. Un hook preinstall que nunca se ejecuta no roba nada.
• ☐ Revisa lo que publicas tú. Si algún mantenedor de tu organización ejecutó la versión maliciosa, busca en tus propios paquetes de npm versiones que no hayas publicado tú. El gusano se republica a través de tokens robados.
• ☐ Audita las configuraciones de las herramientas de IA. Los archivos de configuración de Claude, Cursor y Windsurf estaban en la lista de objetivos. Rota las claves de API guardadas en ellos y en cualquier configuración de servidores MCP de las máquinas afectadas.
• ☐ Analiza de forma continua. Apunta el NPM Scanner → y el Package Scanner → de PlayCISO a tus manifiestos y el AI Dependency Scanner → a tu stack de IA, para que la próxima versión maliciosa se detecte al instalarla y no en la auditoría. Mantén una AIBOM → viva para que «¿estamos expuestos?» se responda en minutos.
• ☐ Ensaya el escenario del borrado. «Un portátil de desarrollo tiene un interruptor de hombre muerto sobre un token robado: ¿quién lo toca primero y en qué orden?» es un ejercicio de mesa que vale la pena hacer en la Cyber War Room → antes de que sea un martes real.

La conclusión

tensorlake@0.5.144 es el mismo gusano con un filo más afilado: se salta la CI para llegar a las personas, lleva un sello de procedencia válido y ha convertido el primer paso de tu playbook de incidentes en una trampa. Deniega por defecto los scripts de instalación, fija lo que consumes, acota lo que publicas y actualiza el runbook para que eliminar la persistencia vaya antes que revocar. Seguimos el análisis completo y actualizaremos este artículo a medida que se confirmen los detalles.

Analiza tus dependencias con el NPM Scanner y el Package Scanner, y ensaya la respuesta en la Cyber War Room. Antes en esta serie: @subql y ChainDrop, keyv y el problema de la procedencia.