Un token OAuth robado en el ataque a TanStack expuso repositorios privados de CrowdSec
Un token OAuth robado en el ataque a TanStack expuso repositorios privados de CrowdSec
CrowdSec confirmó que un token de GitHub sustraído mediante paquetes npm maliciosos permitió copiar cerca de 170 repositorios privados. El acceso pertenecía a un empleado saliente y permaneció activo durante la transición.
Qué ocurrió
CrowdSec publicó el 18 de septiembre su investigación final sobre la copia no autorizada de aproximadamente 170 repositorios privados de GitHub. La extracción ocurrió el 22 de mayo de 2026, entre las 05:52 y las 06:01 UTC, pero la empresa no conoció el incidente hasta que el archivo apareció en un foro el 16 de septiembre.
GitHub ayudó a reconstruir el ciclo de vida del token utilizado. La investigación vinculó el acceso con la cuenta de un desarrollador que acababa de salir de CrowdSec y cuyo permiso en la organización se mantuvo temporalmente para terminar trabajo pendiente. El equipo había sido afectado por la campaña de paquetes npm maliciosos contra TanStack, diseñada para robar credenciales de desarrolladores.
Alcance confirmado
El actor usó un token OAuth de GitHub para clonar código; CrowdSec no encontró evidencia de commits maliciosos, cambios en CI/CD, acceso a sus bases de datos ni intrusión en su infraestructura AWS. La separación de privilegios evitó que la credencial de GitHub ofreciera el mismo alcance sobre otros sistemas.
El material incluía código de la consola SaaS, scripts y modelos de ciencia de datos, automatizaciones y la lógica de consenso empleada para decidir cuándo una dirección IP entra en las listas de bloqueo. También quedaron expuestos 83 correos de usuarios y datos de contacto y contexto de inversión de 51 posibles inversores de 2020.
Por qué los controles habituales no bastaron
La autenticación multifactor no detiene el uso de un token OAuth ya autorizado. Además, cuando CrowdSec investigó meses después, la credencial ya no existía y la actividad Git no estaba disponible en los registros que podía consultar, lo que dificultó atribuir rápidamente las descargas.
El incidente combina dos fallas operativas: una dependencia comprometida alcanzó una estación de desarrollo con acceso valioso, y una excepción de salida dejó viva una credencial sin una caducidad y vigilancia suficientes. El desfase de casi cuatro meses demuestra que rotar solamente los paquetes afectados no cierra el riesgo de los secretos que pudieron robar.
Recomendaciones
- Revocar sesiones, tokens OAuth, claves SSH y accesos a repositorios en el momento efectivo de la salida; cualquier excepción debe tener propietario, vencimiento automático y monitoreo reforzado.
- Ante una dependencia maliciosa, tratar todos los secretos accesibles desde la estación o runner como potencialmente comprometidos y rotarlos, aunque el paquete ya se haya eliminado.
- Aplicar EDR y control de ejecución en estaciones de desarrollo y runners de CI, incluidos procesos iniciados por scripts de instalación de paquetes.
- Supervisar clonaciones masivas, accesos desde ubicaciones nuevas y uso de tokens por cuentas en transición; conservar registros Git durante un periodo acorde al riesgo.
- Escanear repositorios en busca de secretos y separar identidades de código, nube y despliegue para limitar el movimiento lateral cuando una credencial sea robada.
Fuentes y referencias
Esta publicación es una síntesis original. Consulte las fuentes primarias para información técnica completa y actualizaciones.
- 1
- 2
- 3CrowdSec — comunicado inicial ↗fabricante
- 4The Hacker News ↗prensa especializada
¿Esta amenaza puede afectar a su empresa?
ENERIT puede ayudarle a evaluar exposición, priorizar remediaciones y fortalecer su operación de ciberseguridad.
Hablar con un especialista