# Ataque npm de TanStack: 42 paquetes comprometidos, CrowdSec afectado > Un ataque dirigido contra 42 paquetes de TanStack en npm habría contribuido al clonado de unos 170 repositorios privados de CrowdSec. Web y ciberseguridad ## Ataque npm de TanStack: 42 paquetes comprometidos, CrowdSec afectado Se publicaron en npm 84 versiones maliciosas de 42 paquetes de TanStack. CrowdSec vincula el ataque con el clonado de unos 170 repositorios privados. ![NPM Supply Chain Attack Exposed main](https://sdx-development.com/media/News/attaque-npm-tanstack-packages-compromis-crowdsec/NPM-Supply-Chain-Attack-Exposed-main.webp?v=1789808864) [Web y ciberseguridad](https://sdx-development.com/es/noticias/web-ciberseguridad)Publicado el 19 de septiembre de 2026 a las 11:21 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 `. En resumen ## Una dependencia comprometida, accesos mucho más amplios 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. ## ¿Cómo se comprometieron 42 paquetes de TanStack? 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. ![Diagrama de la cadena de ataque que comprometió los paquetes de TanStack](https://sdx-development.com/media/News/attaque-npm-tanstack-packages-compromis-crowdsec/tanstack-attack-diagram.webp) Desde el envenenamiento de la caché de GitHub Actions hasta la publicación de versiones maliciosas en npm. Punto esencial ## npm no se comprometió en su totalidad 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. ## ¿Qué hacía el código malicioso? Las versiones comprometidas contenían un archivo JavaScript ofuscado de unos 2,3 MB, 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. Identidades de desarrollo ### 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. Nube e infraestructura ### AWS, Google Cloud, Kubernetes y Vault 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. ## Del paquete npm a los repositorios privados de CrowdSec 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. ### Un perímetro importante, pero acotado según CrowdSec 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. Defensa en profundidad ## El mínimo privilegio limita el radio de acción 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. 01 ### Limitar cada identidad a su función Un token destinado a publicar notificaciones no debería poder administrar la infraestructura, leer bases de datos ni modificar repositorios de código. 02 ### Separar lectura y modificación 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. 03 ### Reducir la duración y el perímetro de los accesos 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. ## Por qué los desarrolladores web están especialmente afectados 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. ## ¿Cómo comprobar si un proyecto ha quedado expuesto? 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. 01 ### Comprobar las versiones realmente instaladas 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. 02 ### Inventariar los secretos accesibles 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. 03 ### Renovar las credenciales desde un entorno limpio Idealmente, la rotación de secretos debe realizarse desde un equipo considerado fiable, para no exponer inmediatamente las nuevas credenciales. 04 ### Examinar los registros durante un periodo prolongado 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. ## Seis medidas para reducir el riesgo de la cadena de suministro ![Buenas prácticas para proteger las dependencias npm y los workflows de GitHub Actions](https://sdx-development.com/media/News/attaque-npm-tanstack-packages-compromis-crowdsec/tanstack-security-best-practices.webp) Los principales controles que deben aplicarse a las dependencias, los workflows, las cachés y las identidades técnicas. ## Reforzar las dependencias, los workflows y las identidades 1. **Bloquear las versiones** y supervisar los cambios inesperados en los lockfiles. 2. **Auditar los workflows de GitHub Actions**, especialmente los que utilizan ` pull_request_target `. 3. **Separar las cachés** entre las contribuciones externas y los procesos de publicación de confianza. 4. **Limitar los permisos** de cada token, cuenta, servicio y workflow a lo estrictamente necesario. 5. **Supervisar las instalaciones** y conservar registros que permitan rastrear operaciones inusuales. 6. **Retirar rápidamente los accesos** de los colaboradores que abandonen la organización o ya no los necesiten. 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. ### Regular los accesos conservados tras una salida 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. ## ¿Hay que dejar de utilizar TanStack o npm? 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. ## Una dependencia no es solo código 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. ## El riesgo de npm va mucho más allá de ` node_modules ` El 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. Fuentes y metodología Verificación del 19 de septiembre de 2026 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. - **TanStack — Postmortem: npm supply-chain compromise:** confirmación de las 84 versiones maliciosas distribuidas en 42 paquetes, descripción de la cadena de GitHub Actions, caché y OIDC, así como de las medidas adoptadas tras el incidente. - **GitHub — GHSA-g7cv-rxg3-hmpx:** lista de los paquetes y versiones afectados, comportamiento atribuido al malware y recomendaciones de remediación. - **CrowdSec — TanStack Supply Chain Attack Analysis:** informe que documenta el compromiso de la cuenta de GitHub, el clonado de unos 170 repositorios privados y el análisis del impacto declarado por CrowdSec. WEB Y CIBERSEGURIDAD ## Una base web fiable se prepara antes de que ocurra un incidente. La auditoría del código, las dependencias y las rutas sensibles convierte una alerta técnica en un plan de acción controlado. - Prioridades y riesgos claramente definidos - Correcciones probadas con un plan de reversión - Mantenimiento organizado a largo plazo [Solicitar una auditoría](https://sdx-development.com/es/contacto)[Ver servicios](https://sdx-development.com/es/servicios) --- [Consultar la página HTML](https://sdx-development.com/es/noticias/web-ciberseguridad/ataque-npm-tanstack-42-paquetes-comprometidos-crowdsec-afectado)