El SDK de npm de Tensorlake fue envenenado para robar credenciales de agentes de IA — y para borrar tu directorio personal si revocabas el token

El 8 de octubre de 2026, una versión envenenada de tensorlake — el SDK de npm para la plataforma de Tensorlake, que ejecuta código no confiable generado por LLM dentro de entornos aislados — llegó al registro de npm. La versión 0.5.144 se publicó a las 01:12:07 UTC; los investigadores de Socket dicen que la señalaron unos once minutos después. No fue una versión autorizada. Tensorlake afirma que el atacante subió código directamente al repositorio de GitHub de la empresa y lo publicó mediante el propio flujo de trabajo de publicación del proyecto, por lo que el paquete llevaba procedencia válida de npm — una atestación firmada que muestra dónde se compiló, para un código fuente que ya había sido envenenado. La empresa dice que la versión estuvo disponible durante aproximadamente 1 hora y 40 minutos, desde las 01:12 hasta las 02:54 UTC, antes de que npm la eliminara.

El payload no necesitaba importación ni un agente en ejecución. Un preinstall hook del manifiesto del paquete ejecutaba node lib/setup.mjs, un cargador ofuscado que instalaba el runtime de Bun en la máquina y lo usaba para ejecutar lib/Math_Symbol.js, un ladrón de credenciales y gusano autorreplicante de 856.501 bytes. Cualquiera que hiciera una instalación normal de esa única versión lo ejecutaba. Como era la etiqueta latest del paquete, esa versión era a la que resolvía una instalación predeterminada mientras estuvo activa.

Lo que hace que este registro valga la pena conservar no es el tamaño del payload — la familia Shai-Hulud ya ha sido documentada antes. Es la lista de objetivos. Junto con tokens de npm y GitHub, credenciales de AWS, secretos de Kubernetes y Vault, claves SSH, .env archivos, contraseñas de navegador y carteras de criptomonedas, esta compilación recopiló específicamente configuración de herramientas de desarrollo de IA y archivos MCP — los asociados con Claude Code, Cursor, Kiro, Windsurf y Zed, según Socket. También escribió sus propios .claude/settings.json y .vscode/tasks.json en los repositorios a los que podía acceder, para que el código se ejecutara de nuevo la próxima vez que un desarrollador abriera ese proyecto en Claude Code o VS Code. Es un ataque a la cadena de suministro dirigido directamente a las máquinas en las que la gente construye agentes.

Cómo la publicación salió de la cuenta de un mantenedor

Socket, SafeDep y Aikido publicaron cada uno su propio análisis el 8 de octubre, y sus descripciones del mecanismo coinciden. La calificación de confianza del archivo para este registro es A, no está marcado como disputado, y nada de lo encontrado en las fuentes contradice a ninguno de ellos.

El informe de SafeDep rastrea ocho commits en la rama main del repositorio entre las 01:20 y las 03:57 UTC del 7 de octubre, atribuidos a una cuenta de administrador del repositorio y realizados a través de la interfaz web de GitHub. El commit que el archivo cita como el primero malicioso es 41b38f0, una revisión de cuatro archivos de las 03:44:48 UTC del 7 de octubre cuyo mensaje es "Add files via upload" y que lleva la firma verified de GitHub —GitHub firma los commits realizados en su propio editor web, de modo que "verified" registra la superficie de edición, no a la persona. Ese commit no tocó ningún archivo más allá de typescript/lib/Math_Symbol.js y typescript/lib/setup.mjs, según la API de GitHub: el payload, y nada más.

SafeDep ofrece una lectura del comportamiento del operador, etiquetada como inferencia propia: la primera edición del hook de preinstalación rompió la sintaxis JSON del archivo y un commit de reparación llegó diecinueve minutos después, lo que describe como coherente con una persona editando archivos en un navegador en lugar de un pipeline automatizado. Nada de lo publicado por Socket, SafeDep, Aikido, StepSecurity o Tensorlake menciona el método mediante el cual se tomó el control de la cuenta del mantenedor.

El atacante no necesitó un token de npm. SafeDep informa de que la cuenta inició el flujo de trabajo del proyecto publish_npm.yaml a mano el 8 de octubre a las 00:08 UTC; el registro de compilación muestra los archivos de carga útil dentro del tarball publicado. La publicación utilizó npm trusted publishing, y los paquetes hermanos tensorlake-native-* publicados en la misma ejecución llevan procedencia SLSA válida — una procedencia que es genuinamente válida para una compilación de código fuente envenenado. La publicación se produjo doce minutos después de que comenzara el flujo de trabajo.

El archivo registra que el repositorio estuvo comprometido durante aproximadamente 20 horasantes de que se activara la publicación —el lapso que la línea de tiempo a continuación detalla commit a commit—, lo cual es coherente con la propia declaración de Tensorlake de que el atacante publicó "a través de nuestro propio flujo de trabajo de lanzamiento".

Qué hizo el payload una vez que se ejecutó

La evaluación de Socket identifica la recolección en archivos locales, entornos de CI, fuentes de Kubernetes y Vault, además de exfiltración, persistencia y ejecución de código suministrado de forma remota. SafeDep reprodujo la carga útil decodificada: lib/setup.mjs descarga Bun 1.3.13 desde el lanzamiento oficial de GitHub y lo usa para ejecutar el gusano, y se detiene en los runners de CI — el objetivo es una máquina de desarrollador, no un agente de compilación. SafeDep también encontró que la carga útil lleva una copia simple de ese mismo cargador, que coloca en otros paquetes y repositorios.

El payload ejecuta tres métodos de ofuscación que SafeDep decodificó sin ejecutarlo: una cadena de ofuscador, un cifrado personalizado que usa la sal svksrhjkcejg idéntica a la reportada en el compromiso anterior de keyv — y AES-256-GCM sobre once archivos incrustados, incluidos scripts, hooks y dos claves públicas RSA. Su primera línea lleva la etiqueta de compilación WORMTAG='tensrlake', mal escrita, que es como SafeDep distingue esta compilación de una reinfección en curso.

Más allá de la configuración de herramientas de IA, la lista de recopilación es amplia y específica: ~/.claude.json y ~/.kiro/settings/mcp.json para la configuración de agentes; claves SSH, archivos de CLI en la nube, .npmrc, .env, archivos de Docker y Kubernetes, e historial de shell; wallet.dat además de datos de Exodus, Electrum y Ledger Live, y de extensiones de cartera del navegador como MetaMask y Phantom; AWS STS, SSM Parameter Store y Secrets Manager; secretos de GitHub Actions leídos de la memoria del proceso de Runner.Worker; y tokens de cuenta de servicio de Kubernetes y tokens de Vault. Obtuvo un binario por plataforma de iseekaigogo[.]com/hbd/<platform> y lo ejecutó con los argumentos "dump -b all -c password -f json" — argumentos que coinciden con la herramienta HackBrowserData, aunque SafeDep señala que el binario en sí no se recuperó y califica la identificación como una inferencia. El gusano, añade SafeDep, se cierra en configuraciones regionales rusas.

La persistencia es deliberada. Socket escribió sobre el payload: «Esa combinación extiende el riesgo más allá de una sola clave de API robada», y añadió que «la persistencia puede conservar el acceso del atacante después de que se elimine la dependencia afectada». SafeDep informa que el gusano realiza commits de archivos de hook de Claude Code y VS Code como el autor de git claude, y coloca un flujo de trabajo «Run Copilot» que vuelca todos los secretos del repositorio y luego elimina la ejecución y la rama. El aviso de Tensorlake indica a los desarrolladores que revisan sus registros que busquen una rama llamada dependabot/github_actions/format/setup-formatter y commits atribuidos a esa misma identidad.

La propagación funciona con tokens robados en lugar de con una segunda vulnerabilidad. Socket afirma que el gusano enumera los paquetes asociados con la identidad de publicación de una víctima, construye la procedencia de Sigstore y vuelve a publicar versiones envenenadas. SafeDep añade el detalle de que, dentro de CI, agrega una dependencia de git y firma su salida con Fulcio y Rekor, por lo que la procedencia del siguiente paquete que publique es tan válida como lo era la procedencia de 0.5.144.

Las veinte horas antes de la publicación

La brecha entre el primer commit fraudulento y el lanzamiento es la parte de la cronología que explica cómo un paquete envenenado llegó a contar con una procedencia válida. Todas las horas están en UTC; las horas de los commits son de SafeDep y de la API de GitHub, y las horas de publicación, eliminación y avisos son de Tensorlake.

Léelo de corrido: los archivos de payload llegaron a la rama principal del repositorio el 7 de octubre, la versión se fijó en 0.5.144 a las 03:57 de esa madrugada, y no se publicó nada hasta que una cuenta inició a mano el flujo de trabajo de publicación a las 00:08 del día siguiente. El código fuente comprometido permaneció en la rama durante unas veinte horas antes de que la propia canalización del proyecto lo compilara. Eso es todo el ataque a la ruta de publicación: ninguna atestación falsificada, ningún tarball republicado. La procedencia era exacta respecto a una compilación de código que nunca debería haber estado en la rama.

El interruptor de hombre muerto

La parte de este incidente que no tiene precedentes en compromisos anteriores de npm es lo que ocurre después de que una víctima reacciona correctamente. Si el token robado de GitHub pertenece a una cuenta sin organizaciones, según informa SafeDep, el gusano instala gh-token-monitor: un servicio que consulta api.github.com/user con ese token robado cada 60 segundos, durante 24 horas. Cuando GitHub devuelve un 40x —como lo hace en el momento en que se revoca el token—, el monitor ejecuta un manejador proporcionado por el atacante y elimina el directorio personal del usuario.

Socket describe el mismo componente como el uso de un monitor de PowerShell que persiste a través de ONLOGON (una tarea programada) y que ejecuta un controlador proporcionado por el atacante a través de Invoke-Expression, y señala que el código contiene la cadena literal "IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner", vista en oleadas anteriores de Shai-Hulud. SafeDep nombra el controlador como rm -rf ~/. El texto de Socket es explícito en que esto se activa independientemente de dónde ocurra la revocación; el monitor es local, y la revocación no lo es. Las cuatro fuentes — Socket, SafeDep, StepSecurity y el propio aviso de Tensorlake — dan el mismo orden de operaciones: eliminar el monitor primero, luego revocar.

Qué está establecido y qué solo se infiere

El archivo registra ausencia de daño confirmado para esta entrada, y las fuentes lo respaldan en lugar de limitarse a no contradecirlo.

• Tensorlake declara que no hay uso de esta versión. Su aviso indica que la empresa monitorea el uso del SDK mediante encabezados de user-agent y que "no ha visto ningún uso de esta versión desde que se publicó". Esa es una declaración del proveedor sobre su propia telemetría, no un recuento auditado.

• La cifra de descargas no es un recuento de infecciones. Socket informa que el paquete tiene aproximadamente 12.000 descargas semanales y señala que esto describe el uso general del paquete, no las descargas de la versión maliciosa; SafeDep cita alrededor de 106.000 descargas mensuales del mismo paquete. Ninguna de las dos es evidencia de que la 0.5.144 se ejecutara en algún lugar. La ventana de lanzamiento marcada de Socket y la ventana de dos horas de Tensorlake son consistentes con una versión que se eliminó antes de que se propagara.

• Los propios errores del payload pueden haberlo limitado. SafeDep encontró dos: la ruta de propagación de npm necesita ./dist/Math_Symbol.js en disco y se detiene sin él, y el cargador implantado busca ai_init.js mientras el gusano escribe math_init.js. SafeDep etiqueta estos hallazgos como limitaciones de propagación, y el artículo los trata como la interpretación del código de un análisis, no como una garantía de que no se propagó nada.

• La atestación de procedencia es real. Esto no es una afirmación controvertida: la procedencia de npm registra dónde se compiló un paquete y mediante qué flujo de trabajo, y en este caso registró la verdad: el propio flujo de trabajo de publicación del proyecto, compilando código fuente envenenado. El aviso de Tensorlake lo dice con todas las letras: "el paquete lleva procedencia de npm válida". Socket plantea el mismo punto sin rodeos cuando señala que la procedencia "dice dónde se compiló un paquete. No dice que el código sea seguro".

Varios detalles que circulan son afirmaciones derivadas de un único análisis y deben leerse como tales. El mecanismo específico mediante el cual el atacante obtuvo la cuenta del mantenedor no ha sido publicado por ninguna de las firmas investigadoras ni por Tensorlake. La dirección del contrato de Ethereum y su papel en la resolución del endpoint aparecen en los informes de SafeDep y de Socket —Socket afirma que el payload resuelve su endpoint a través de un contrato de Ethereum usando aproximadamente 30 endpoints RPC públicos con un respaldo en GitHub, mientras que SafeDep cifra el número de RPC en 35 e informa de que el 8 de octubre el contrato devolvió iseekaigogo.com— y Tensorlake confirma el endpoint y el contrato en su aviso. El número exacto de RPC difiere entre los dos escritos; el diseño, no.

Una laguna en el registro público merece mencionarse con claridad. Ninguna de las fuentes revisadas para este artículo reporta una infección secundaria confirmada: otro paquete o repositorio envenenado por el gusano mediante credenciales robadas de este. El código de propagación existe y SafeDep lo ha leído; se desconoce si produjo una segunda víctima.

¿Qué cambió después?

La respuesta fue más rápida y más coordinada que el incidente.

• La versión ya no existe. Estuvo activa desde las 01:12 hasta las 02:54 UTC del 8 de octubre, según Tensorlake; SafeDep informa de que npm la eliminó. Al consultar directamente el registro de npm el 10 de octubre para este artículo, la 0.5.144 ya no aparece entre las versiones publicadas del paquete, y la etiqueta más reciente del paquete es la 0.5.148. El aviso de Tensorlake indica a los desarrolladores que la 0.5.143 es la última versión no afectada.

• El aviso se publica con una corrección. El aviso GHSA-8g63-53c9-65j2 de Tensorlake indica que los paquetes de PyPI y crates.io tensorlake y la tensorlake CLI no se vieron afectados —solo el paquete de npm se vio afectado— y que las versiones 0.5.143 y anteriores no se ven afectadas. SafeDep informa de que los mantenedores revirtieron el código fuente en la solicitud de extracción #1016 y publicaron la versión 0.5.145.

• El hilo de divulgación es inusualmente completo.El investigador de StepSecurity, Ashish Kurmi, abrió el problema de GitHub #1014 a las 01:22:02 UTC del 8 de octubre — unos diez minutos después de la publicación — señalando el propio informe de StepSecurity sobre lo que llama el gusano del "token rehén". Oliver Smith, de Aikido, comentó que el payload se introdujo en el commit 41b38f0 y lo identificó como un nuevo stealer de información Shai-Hulud. El mantenedor David Lorenzo — la identidad del mantenedor listada en el paquete npm como calavera — respondió el 9 de octubre confirmando el aviso de seguridad y cerrando el problema como completado ese mismo día. El título del problema en sí mismo sigue la evidencia: comenzó como un informe "posiblemente malicioso" y fue renombrado, para cuando se cerró, para describir el payload como malicioso sin reservas.

• La campaña a la que pertenece esto es más grande que este paquete. Socket, SafeDep y Aikido sitúan la publicación de Tensorlake en la ola ChainDrop / Mini Shai-Hulud documentada por primera vez a principios de agosto de 2026, cuyas víctimas de npm incluían keyv, cacheable y paquetes relacionados. El aviso de Tensorlake dice lo mismo, citando a Socket, SafeDep y Aikido.

La guía de Socket para cualquiera que haya instalado la versión es que el host debe tratarse como comprometido: revise los archivos de bloqueo, los manifiestos y los registros de compilación de la versión; elimine gh-token-monitorel servicio antes de revocar cualquier token; luego rote las credenciales desde una máquina limpia. El aviso de Tensorlake añade el mismo orden y sugiere revisar los registros de paquetes y los repositorios en los que los tokens expuestos podrían escribir, en busca de versiones inesperadas. El artículo de Aikido aconseja establecer ignore-scripts=true en .npmrc para bloquear los hooks de instalación y tratar cualquier máquina donde se ejecutó el hook como totalmente comprometida.

Este es un registro, reportado por otros y citado aquí a ellos. Los demás incidentes documentados de agentes, cada uno con sus propias fuentes, gravedad, grado de confianza e indicador de disputa, se encuentran en el archivo de incidentes de IA — de modo que un compromiso de la cadena de suministro dirigido a las herramientas de agentes pueda leerse junto al resto de lo que realmente ha sucedido.