ANÁLISIS
GitHub Actions, 23.000 repositorios: cuando la pipeline expone las claves
El 14 y 15 de marzo de 2025 el componente tj-actions/changed-files, usado por más de 23.000 repositorios, fue alterado para imprimir en los registros los secretos CI/CD; el primer objetivo era un proyecto de Coinbase. El análisis: costes sin robo, la pipeline como proveedor, responsabilidad, cúmulo y preguntas para las renovaciones.
Archivo: reconstrucción escrita en noviembre de 2026
Tema del mes de marzo de 2025 · por cybercoverinsurance
El 14 y 15 de marzo de 2025 tj-actions/changed-files, un componente de GitHub Actions usado por más de 23.000 repositorios, fue modificado para imprimir en los registros de compilación los secretos de los proyectos que lo usaban: claves de la nube, tokens de acceso, claves privadas. Pocos días antes se había comprometido otro componente, reviewdog/action-setup. Los análisis posteriores señalaron como primer objetivo un proyecto de código abierto de Coinbase.
Para quien asume el riesgo cyber el caso es útil aunque no haya producido grandes siniestros conocidos. Muestra cómo un solo componente de la cadena de compilación puede exponer en pocas horas las credenciales de miles de organizaciones, y plantea tres preguntas: qué pasa cuando los secretos salen pero nadie los usa, quién responde si de la pipeline sale código manipulado y cómo se mide un cúmulo que pasa por las herramientas de los desarrolladores.
Lo que se sabe
El componente. tj-actions/changed-files es una GitHub Action que detecta qué archivos han cambiado en un proyecto. Según StepSecurity la usaban más de 23.000 repositorios. El código alterado ejecutaba un script que leía de la memoria del proceso de compilación los secretos CI/CD (claves API, contraseñas, tokens) y los escribía en los registros. En los proyectos con registros públicos, los secretos eran legibles por cualquiera. Wiz encontró decenas de repositorios públicos con secretos expuestos, entre ellos claves AWS válidas, tokens de GitHub y npm y claves RSA privadas (The Register).
La causa. El ataque pasó por un token de acceso personal vinculado a la cuenta automática @tj-actions-bot. GitHub declaró que no podía determinar cómo se comprometió. El componente se identifica como CVE-2025-30066, con una puntuación de 8,6 (The Register). La CISA lo incluyó en su catálogo de vulnerabilidades explotadas, con un aviso del 18 de marzo (Cybersecurity Dive).
La cadena. El 11 de marzo se había comprometido reviewdog/action-setup (CVE-2025-30154), durante unas dos horas y en unos 1.500 repositorios según Wiz. El compromiso de tj-actions duró unas 22 horas y afectó a unos 14.000 repositorios. Endor Labs contó unos 218 repositorios que expusieron efectivamente secretos, en su mayoría tokens de GitHub que caducan al terminar el trabajo (Cybersecurity Dive).
El objetivo. Según Unit 42 de Palo Alto Networks, confirmada después por Wiz, el atacante apuntaba primero al flujo CI/CD público de agentkit, un proyecto de código abierto de Coinbase. El 14 de marzo había obtenido un token con permisos de escritura en el repositorio, pero no logró acceder a los secretos de Coinbase ni publicar paquetes. Tras la reacción de Coinbase pasó al ataque extendido sobre todas las versiones de tj-actions (Cybersecurity Dive).
Lo que no se sabe. No constan públicamente robos de datos o fraudes atribuibles a los secretos expuestos. No hay prueba de que los secretos de los repositorios públicos se enviaran a servidores externos (The Register). No se sabe cuántas organizaciones tuvieron costes de saneamiento, ni cuánto.
El secreto expuesto ya es un incidente
Ningún robo conocido, muchos costes ciertos. Las indicaciones de GitHub, Wiz y Sysdig eran las mismas: considerar comprometidos los proyectos, rotar todos los secretos, revisar los flujos ejecutados el 14 y 15 de marzo (The Register, Cybersecurity Dive). Para una empresa con decenas de pipelines, son días de trabajo entre análisis de registros, rotación de claves y verificación de accesos a la nube.
La póliza debe decir si responde. Muchas pólizas cyber cubren los costes de respuesta tras un evento de seguridad, pero la definición varía: acceso no autorizado, violación sospechada, compromiso de credenciales. Un secreto impreso en un registro público, sin prueba de uso, está en el límite. Para quien asume el riesgo, conviene aclarar antes si los costes de análisis y rotación están cubiertos aunque no haya acceso comprobado.
El valor del secreto depende de lo que abre. Un token de GitHub que caduca al terminar el trabajo vale poco. Una clave AWS válida abre el entorno de nube de producción. La gravedad del incidente, y del posible siniestro, depende de los permisos del secreto más que del componente comprometido.
La pipeline es un proveedor
El código de terceros funciona con las claves del asegurado. Una GitHub Action es código de un tercero, descargado en cada ejecución, que trabaja con los secretos del proyecto. Es el mismo esquema del caso Polymarket en 2026 y de Bybit en 2025: código externo ejecutado en el punto más delicado. En la pipeline el punto delicado son las claves de publicación y de acceso a la nube.
La referencia por versión no protege. El atacante movió todas las etiquetas de versión de tj-actions al código malicioso. Quien llamaba al componente por versión recibió el código nuevo sin darse cuenta. GitHub recomienda fijar cada Action al identificador completo del commit (The Register). Es un control sencillo, verificable y poco extendido.
Las cuentas automáticas son identidades privilegiadas. La vía de entrada fue el token de una cuenta bot. Estas cuentas suelen tener permisos amplios, ninguna autenticación multifactor y tokens que no caducan. Tras el incidente tj-actions redujo los permisos, añadió passkeys e impuso commits firmados (The Register).
Responsabilidad y cúmulo
El riesgo mayor es el código que sale, no el que entra. En este caso el atacante buscó secretos. Con un token de escritura habría podido insertar código en los paquetes publicados por un proyecto. Para una empresa de software, un paquete manipulado distribuido a los clientes es un siniestro de responsabilidad frente a terceros, con posibles efectos sobre muchas víctimas aguas abajo.
El cúmulo pasa por las herramientas, no por los sectores. Las mismas Actions las usan bancos, empresas de software, aseguradores y administraciones públicas. Una cartera diversificada por sector puede estar concentrada en las mismas herramientas de desarrollo. El dato no aparece en los cuestionarios tradicionales.
Un evento, muchos plazos. El compromiso duró horas, pero los secretos expuestos pueden usarse semanas después si nadie los rota. Un evento con causa única puede producir siniestros repartidos en el tiempo, con cuestiones de agregación similares a las de Cleo y MOVEit.
Qué llevar a las renovaciones
Impacto para las aseguradorasMedio
Un componente de GitHub Actions usado por más de 23.000 repositorios expuso los secretos CI/CD durante unas 22 horas, sin grandes siniestros conocidos pero con costes de saneamiento extendidos.
En el lado de la cartera, la pregunta útil es cuántos asegurados usan GitHub Actions o herramientas similares con componentes de terceros no fijados. Para las empresas de software, la exposición de responsabilidad frente a los clientes por código manipulado debe evaluarse junto con la exposición cyber propia.