CrowdSec atribuye el robo de 300 repositorios de GitHub a una dependencia maliciosa de TanStack

Los atacantes accedieron a código privado a través de una dependencia de software

La empresa francesa de ciberseguridad CrowdSec ha confirmado que unos atacantes extrajeron código fuente de aproximadamente 300 de sus repositorios de GitHub, incluidos alrededor de 170 repositorios privados.

La empresa descubrió la semana pasada que el robo se había producido durante mayo de 2026. Su investigación vinculó la intrusión con la campaña contra la cadena de suministro de software de TanStack atribuida a TeamPCP, que distribuyó 84 artefactos maliciosos a través de 42 paquetes de TanStack.

CrowdSec cree que el malware distribuido mediante un paquete comprometido obtuvo una API key con capacidad para leer su base de código privada. Al parecer, esa credencial permitió a los atacantes copiar repositorios tanto públicos como no públicos, sin que fuera necesario identificar una intrusión independiente en la infraestructura central de producción de CrowdSec.

El código privado robado correspondía a la consola SaaS de CrowdSec, algunas rutinas de AWS Cloud, conectores y componentes de automatización. Según el relato de CrowdSec sobre la investigación, los investigadores no han encontrado pruebas de que se expusieran credenciales de clientes u otra información relacionada con ellos.

Por ahora, la empresa considera que el impacto directo es interno.

La posible ruta desde la instalación del paquete hasta el acceso a GitHub

CrowdSec utilizó un paquete de TanStack durante mayo de 2026, cuando los artefactos maliciosos estaban activos. La hipótesis de trabajo de la empresa es que el código ejecutado desde la dependencia comprometida capturó una API key de su entorno de desarrollo.

Una API key con permisos de lectura de repositorios puede proporcionar a un atacante de la cadena de suministro una vía directa hacia código propietario. En lugar de explotar cada repositorio por separado, el atacante puede utilizar la credencial de confianza para enumerar y descargar todos los proyectos disponibles para esa identidad.

Eso parece explicar la magnitud del robo: se vieron afectados aproximadamente 300 repositorios, más de la mitad de ellos privados. La información disponible no permite determinar si todos los repositorios se descargaron por completo o si los atacantes seleccionaron determinados archivos de algunos proyectos.

Varios detalles técnicos siguen sin conocerse. CrowdSec no ha identificado el paquete exacto de TanStack ni la versión que utilizaba, y tampoco ha publicado los permisos precisos de la API key, los eventos relevantes de auditoría de GitHub u otros indicadores de compromiso. No se han difundido nombres de archivos maliciosos, hashes, dominios ni direcciones de red.

La empresa describió el periodo probable de exposición como una ventana breve durante mayo de 2026. Cuando identificó el riesgo, rotó todos los tokens y credenciales que podrían haberse visto afectados.

Qué contenían los repositorios robados

Los repositorios privados incluían código relacionado con cuatro áreas importantes de las operaciones de CrowdSec:

• La consola SaaS de CrowdSec;
• Determinadas rutinas de AWS Cloud;
• Conectores utilizados para vincular sistemas o servicios;
• Funcionalidades internas de automatización.

Esto no equivale a una divulgación confirmada de bases de datos de clientes, contraseñas, tokens de acceso o datos de producción. CrowdSec buscó en el material afectado y en su entorno credenciales, API keys, tokens y otros secretos que pudieran facilitar el movimiento lateral. La empresa afirmó que, hasta el momento, esa búsqueda no había identificado material de ese tipo.

La distinción es importante, pero la exposición del código fuente sigue generando trabajo de seguridad. Los atacantes pueden analizar el código propietario en busca de debilidades de implementación, interfaces no documentadas, supuestos sobre la nube, convenciones internas de nomenclatura y lógica que pueda facilitar futuros intentos de intrusión. Aunque no haya secretos incrustados deliberadamente, los fragmentos de configuración, los datos de prueba, el historial de commits y los scripts de automatización pueden revelar detalles operativos.

CrowdSec sostiene que el código copiado no puede funcionar fácilmente fuera de su entorno original. Reproducir los servicios de la empresa requeriría su red, sus datos, sus herramientas y la infraestructura de soporte. El proveedor también señaló que el código SaaS se somete a auditorías periódicas y que gran parte del material filtrado había cambiado sustancialmente durante los cuatro meses anteriores.

Estos factores pueden reducir la facilidad de explotación inmediata. No hacen que el robo sea irrelevante.

No se ha identificado ninguna intrusión en clientes

CrowdSec no ha encontrado pruebas de que los atacantes obtuvieran credenciales de clientes u otra información relacionada con ellos. Tampoco ha informado de que TeamPCP utilizara el código robado para acceder a despliegues de clientes, recursos en la nube o la plataforma SaaS de producción.

Por tanto, la evaluación actual es más limitada de lo que el número de repositorios podría sugerir inicialmente: la propiedad intelectual de CrowdSec quedó expuesta, pero no se ha establecido una filtración de datos de clientes.

Esta conclusión podría cambiar si análisis posteriores descubren credenciales que escaparon a la búsqueda inicial o detectan actividad sospechosa vinculada a la información contenida en el código. Las investigaciones sobre código fuente pueden llevar tiempo, porque los secretos pueden encontrarse en commits anteriores, ramas archivadas, archivos generados o registros de compilación, en lugar de estar en la versión actual de un proyecto.

CrowdSec afirmó que continuará vigilando posibles comportamientos anómalos. La empresa no ha divulgado pruebas de una explotación posterior, extorsión, publicación de los repositorios ni intentos de utilizar como arma las vulnerabilidades encontradas en el código robado.

No corresponde ningún identificador CVE, puntuación CVSS ni clasificación formal de gravedad al incidente tal como se ha descrito. Tampoco existe una entrada asociada en el catálogo de vulnerabilidades explotadas conocidas de CISA. Se trata de una intrusión en la cadena de suministro habilitada por credenciales, no de una vulnerabilidad divulgada con un parche del proveedor y una tabla de versiones afectadas.

La respuesta se centró en las credenciales y el riesgo de movimiento lateral

La primera medida de contención de CrowdSec fue rotar todos los tokens y credenciales potencialmente afectados. Esa acción era necesaria porque se sospecha que el acceso inicial se produjo mediante una API key, no mediante un fallo de software que pudiera resolverse únicamente instalando una actualización.

La empresa también buscó material sensible que pudiera permitir al atacante avanzar más allá del acceso a los repositorios. Los investigadores revisaron los repositorios comprometidos y examinaron el código que sustenta la consola SaaS, las rutinas de AWS, los conectores y las automatizaciones.

Su respuesta continúa incluyendo:

1. La supervisión de actividad inusual asociada a las identidades y los entornos afectados;
2. La revisión de los repositorios privados en busca de secretos incrustados o históricos;
3. La evaluación de si el código expuesto revela vías útiles hacia sistemas de nube o de producción;
4. El mantenimiento de las auditorías del código fuente de la plataforma SaaS;
5. La investigación de posibles movimientos laterales desde la credencial de desarrollo comprometida.

CrowdSec no ha informado de ningún movimiento lateral. Sin embargo, la ausencia de credenciales detectadas en los archivos de código fuente actuales no excluye por sí sola una exposición a través del historial de los repositorios o de sistemas de desarrollo relacionados.

Qué deberían revisar los usuarios de TanStack y los equipos de desarrollo

Las organizaciones que utilizaron paquetes de TanStack durante la ventana de explotación de mayo de 2026 deberían verificar la procedencia de los paquetes y revisar los historiales de dependencias, archivos de bloqueo, compilaciones e instalaciones. Como no se han divulgado los nombres ni las versiones de los paquetes comprometidos relevantes para CrowdSec, los equipos de defensa no pueden basarse en un indicador específico de CrowdSec.

Los equipos deberían identificar las credenciales disponibles para los scripts de instalación de paquetes, los ejecutores de compilación, las estaciones de trabajo de los desarrolladores y los trabajos de integración continua. Cualquier token expuesto a esos entornos debería evaluarse según sus permisos y rotarse cuando no pueda descartarse que se haya visto comprometido.

Los administradores de GitHub deberían revisar el acceso a los repositorios en busca de enumeraciones, clonaciones, descargas de archivos o actividad de API inusuales que impliquen identidades de desarrollo y automatización. Los equipos de la nube también deberían examinar si el código de los repositorios o los sistemas de compilación contenían credenciales capaces de acceder a recursos de AWS u otra infraestructura.

Para las organizaciones que se integran con CrowdSec, actualmente no hay pruebas de que se hayan robado credenciales o información de clientes del proveedor. Los clientes no deberían interpretar el incidente como una prueba de que sus propios entornos fueron vulnerados. No obstante, deberían investigar cualquier actividad inesperada de autenticación o de API si sus despliegues compartían credenciales con flujos de trabajo de desarrollo afectados.

El incidente demuestra el alcance que puede tener una dependencia maliciosa: un solo paquete comprometido puede heredar el acceso disponible para el entorno que lo ejecuta. En el caso de CrowdSec, el resultado que se sospecha fue la obtención de una API key y el acceso a cientos de repositorios. La cuestión que queda por resolver es si el código robado puede ayudar a TeamPCP —o a otra parte que lo reciba— a ir más allá del robo de propiedad intelectual.