GitHub, npm y claves SSH
El malware podía buscar distintos tokens de GitHub y npm, el contenido de archivos .npmrc, así como claves SSH privadas.
Procesando…
Web y ciberseguridad
Se publicaron en npm 84 versiones maliciosas de 42 paquetes de TanStack. CrowdSec vincula el ataque con el clonado de unos 170 repositorios privados.
Un ataque contra la cadena de suministro de software permitió publicar 84 versiones maliciosas de 42 paquetes de TanStack en npm. Unos días después, una cuenta de GitHub comprometida se utilizó para clonar unos 170 repositorios privados de CrowdSec. El incidente muestra cómo una dependencia de JavaScript puede exponer mucho más que el contenido de node_modules.
El código malicioso podía buscar tokens de GitHub y npm, claves SSH y secretos relacionados, entre otros, con AWS, Google Cloud, Kubernetes o HashiCorp Vault. CrowdSec vincula el incidente con el clonado de unos 170 repositorios privados.
El incidente no se debió al simple robo de una contraseña de npm. TanStack utilizaba GitHub Actions y el mecanismo OIDC Trusted Publishing, diseñado para evitar conservar un token permanente de npm en los secretos del repositorio.
Durante una publicación, el workflow autorizado obtiene un token de corta duración para comunicarse con npm. Esta arquitectura reduce los riesgos asociados a las credenciales persistentes, pero no protege automáticamente frente al compromiso del proceso que solicita el token.
Según el post mortem de TanStack, un workflow de GitHub Actions que utilizaba pull_request_target podía ejecutar código procedente de una pull request externa mientras interactuaba con una caché compartida. El atacante habría explotado esta configuración para envenenar una caché que posteriormente restauró un workflow legítimo de publicación.
El código inyectado pudo ejecutarse entonces en el entorno de release y recuperar en memoria el token OIDC destinado a npm. Este token se utilizó para publicar las versiones maliciosas bajo la identidad legítima del proyecto.
Los paquetes se distribuyeron desde el registro oficial, pero su publicación se autenticó mediante la identidad asociada a TanStack. El workflow de publicación no se había modificado y no se habría robado ningún token permanente de npm.
El 11 de mayo de 2026 se publicaron dos versiones maliciosas para cada uno de los 42 paquetes @tanstack/* afectados, es decir, 84 versiones en total. TanStack indica que las marcó rápidamente como obsoletas y después las retiró del registro.
Las versiones comprometidas contenían un archivo JavaScript ofuscado de unos 2,3MB, ejecutado durante la instalación. Según el aviso de seguridad publicado por TanStack y GitHub, buscaba varias categorías de secretos accesibles desde el equipo o el entorno de integración continua.
El malware podía buscar distintos tokens de GitHub y npm, el contenido de archivos .npmrc, así como claves SSH privadas.
La información disponible en las variables de entorno o en los archivos locales también podía ser objetivo y exfiltrarse.
El código también disponía de un mecanismo de propagación. Cuando encontraba las credenciales de un mantenedor de npm, podía buscar los demás paquetes asociados a esa cuenta para intentar volver a publicarlos con el mismo contenido malicioso.
Por tanto, el riesgo no depende de los datos contenidos en el propio paquete. Depende sobre todo de los recursos accesibles para el proceso que ejecuta su script de instalación. En un equipo de desarrollo o en una CI, este perímetro puede incluir repositorios privados, servicios en la nube y entornos de despliegue.
El 16 de septiembre de 2026, CrowdSec descubrió que se había publicado en un foro un archivo que contenía código procedente de su organización de GitHub. La empresa inició una investigación con GitHub para rastrear el token OAuth utilizado para descargar los repositorios.
Según CrowdSec, el token pertenecía a la cuenta de un desarrollador que había dejado recientemente la empresa. Algunos accesos ya se habían revocado, pero la cuenta seguía presente en la organización de GitHub para finalizar trabajos en curso. Su equipo habría sido comprometido por el ataque dirigido contra los paquetes de TanStack.
El 22 de mayo, esta cuenta se habría utilizado para clonar unos 170 repositorios privados de GitHub. Su acceso se eliminó el 25 de mayo, antes de que CrowdSec tuviera conocimiento del clonado. El archivo no se hizo público hasta varios meses después.
CrowdSec afirma no haber detectado modificaciones en sus repositorios ni alteraciones en sus pipelines de build o en su código. La empresa también indica que sus bases de datos y su infraestructura no se vieron comprometidas: la cuenta afectada solo se habría utilizado para clonar los repositorios.
Sin embargo, la filtración incluía código privado, algunas direcciones de correo electrónico y ciertos secretos presentes en los repositorios. CrowdSec menciona, en particular, un token de AWS vinculado al servicio SNS que seguía siendo utilizable, pero cuyos permisos limitados no habrían permitido superar su perímetro previsto.
Impedir que una identidad disponga de permisos excesivos no siempre bloquea el compromiso inicial. Sin embargo, esta separación puede evitar que un token expuesto permita modificar la infraestructura, los repositorios o los datos más sensibles.
Un token destinado a publicar notificaciones no debería poder administrar la infraestructura, leer bases de datos ni modificar repositorios de código.
Un acceso de lectura ya puede provocar una filtración importante, pero la ausencia de permisos de escritura reduce el riesgo de sabotaje, inyección de código o propagación.
Los tokens de corta duración, los permisos limitados a un recurso y una revocación rápida reducen el periodo durante el cual un secreto expuesto sigue siendo utilizable.
El mínimo privilegio no sustituye ni la protección de los equipos ni la supervisión de las identidades. Constituye una capa de contención: cuando cede una primera barrera, las autorizaciones restantes determinan hasta dónde puede llegar el atacante.
Un equipo de desarrollo suele concentrar numerosos privilegios. Puede estar conectado simultáneamente a GitHub, npm, un proveedor de alojamiento, varios servicios en la nube, servidores SSH, bases de datos y entornos de preproducción.
Al mismo tiempo, este equipo instala regularmente código procedente de cientos, incluso miles, de dependencias directas e indirectas. Ahora bien, algunos paquetes disponen de scripts que se ejecutan automáticamente durante la instalación.
Por tanto, un comando npm install no solo descarga archivos JavaScript. Puede ejecutar código con los permisos del usuario o del proceso de CI que lo inició. Así, un ataque contra npm puede convertirse en un incidente de GitHub, de la nube o de CI/CD.
El ataque tuvo lugar el 11 de mayo de 2026. TanStack indica que las versiones maliciosas fueron detectadas, marcadas como obsoletas y retiradas, y que las versiones actualmente disponibles se consideran seguras. No obstante, un equipo que utilice TanStack debe comprobar si se resolvió y ejecutó una versión afectada durante el periodo correspondiente.
El archivo package.json no siempre es suficiente. Hay que examinar los archivos package-lock.json, pnpm-lock.yaml o yarn.lock, y después comparar las versiones con la lista publicada en el aviso GHSA-g7cv-rxg3-hmpx.
Si se ejecutó una versión comprometida, eliminar el paquete no es suficiente. Los tokens de GitHub, npm o la nube, las claves SSH y los secretos de CI/CD accesibles desde el entorno deben considerarse potencialmente expuestos.
Idealmente, la rotación de secretos debe realizarse desde un equipo considerado fiable, para no exponer inmediatamente las nuevas credenciales.
Los registros de GitHub, AWS, Google Cloud y otras plataformas deben analizarse más allá del momento de la instalación. En el caso de CrowdSec, el clonado se habría producido once días después de la publicación de los paquetes maliciosos.
El aviso de TanStack precisa que una instalación con npm, pnpm o Yarn podía activar el payload cuando se resolvía una versión afectada. Por tanto, todo entorno que haya ejecutado una de estas versiones debe tratarse como potencialmente comprometido.
pull_request_target.TanStack indica que reforzó sus workflows, sus permisos, la gestión de las cachés y el bloqueo de determinadas GitHub Actions tras el incidente. El caso demuestra que los archivos situados en .github/workflows forman parte integral de la infraestructura de seguridad de un proyecto.
Mantener temporalmente un acceso puede responder a una limitación operativa, pero esta excepción debe ser explícita, limitada en el tiempo y supervisada. Una identidad poco utilizada sigue siendo explotable si su equipo, sesión o tokens se ven comprometidos.
No. TanStack publicó un post mortem, retiró las versiones afectadas e implementó varios cambios de seguridad. El 15 de mayo, el proyecto indicaba que las versiones disponibles en ese momento eran seguras para instalar.
El incidente tampoco significa que npm sea intrínsecamente peligroso. Las aplicaciones JavaScript dependen necesariamente de bibliotecas de terceros. Reescribir cada componente no eliminaría el riesgo y podría introducir otras vulnerabilidades.
La respuesta consiste más bien en tratar las dependencias, los scripts de instalación y los pipelines que los gestionan como una parte integral de la superficie de ataque.
Las prácticas habituales suelen centrarse en las vulnerabilidades conocidas y en la actualización periódica de los paquetes. Los ataques a la cadena de suministro añaden otra pregunta: ¿qué ocurre si la nueva versión se convierte en el propio vector de ataque?
En este escenario, instalar la versión más reciente ya no constituye automáticamente una protección. La seguridad se basa en varias capas: control de versiones, análisis de las nuevas dependencias, separación de permisos, protección de los equipos, supervisión de las publicaciones y capacidad para renovar rápidamente los secretos.
node_modulesEl incidente no se limitó a los 42 paquetes publicados en npm. Una dependencia comprometida pudo buscar información en un entorno de desarrollo. Según la investigación de CrowdSec, uno de los accesos expuestos de este modo habría permitido posteriormente clonar unos 170 repositorios privados de GitHub.
El archivo malicioso puede encontrarse en node_modules, pero su objetivo real puede ser GitHub, la nube, CI/CD o cualquier otro servicio accesible desde el equipo del desarrollador.
Por tanto, antes de instalar una dependencia, la pregunta ya no es solo si funciona. También hay que determinar a qué podrá acceder si se vuelve maliciosa. Este perímetro es el que determina el impacto real de un compromiso.
Esta síntesis se basa en el post mortem oficial publicado por TanStack, el aviso de seguridad de GitHub GHSA-g7cv-rxg3-hmpx y el informe del incidente publicado por CrowdSec el 18 de septiembre de 2026.
WEB Y CIBERSEGURIDAD
La auditoría del código, las dependencias y las rutas sensibles convierte una alerta técnica en un plan de acción controlado.
Introduce al menos 2 caracteres para iniciar la búsqueda.