| 4 min de lectura
Un incidente crítico en la seguridad de una cadena de suministro ha sacudido recientemente a la comunidad del código abierto, y ha tenido como objetivo la muy utilizada acción de GitHub tj-actions/changed-files. Con más de 23.000 repositorios que confían en esta herramienta —diseñada para enumerar los archivos modificados en commits y pull requests— la vulnerabilidad, ahora rastreada como CVE-2025-30066, sirve como un duro recordatorio de los riesgos potenciales inherentes a la confianza en acciones de terceros y subraya la urgente necesidad de prácticas de seguridad estrictas dentro de los CI/CD pipelines.
¿Qué ha ocurrido?
El 14 de marzo salió a la luz una importante brecha de seguridad en el ecosistema de "acciones" de GitHub (i.e., "GitHub Actions"), centrada en la muy utilizada acción tj-actions/changed-files. Esta acción, esencial para identificar archivos modificados en flujos de trabajo CI/CD, se vio comprometida por la inyección de código malicioso. Para contextualizar, es importante saber que las GitHub Actions son componentes reutilizables, a menudo de código abierto, a los que los desarrolladores pueden hacer referencia en sus flujos de trabajo CI/CD. La acción tj-actions/changed-files, como muchas otras, procesa variables de entorno que pueden contener secretos sensibles. Por tanto, este ataque expuso secretos, claves API y otras credenciales en los registros de ejecución de flujos de trabajo.
Fueron investigadores de StepSecurity quienes al parecer detectaron por primera vez una anomalía en este entorno, y es que observaron un endpoint externo inesperado durante la ejecución de un flujo de trabajo. Su rápido reporte fue crucial para alertar a la comunidad. El ataque consistió en que los adversarios modificaron el código de la acción y actualizaron retroactivamente numerosas etiquetas de versión para que apuntaran a un commit malicioso. Esto significaba que casi todas las versiones históricas de tj-actions/changed-files estaban comprometidas. El código inyectado ejecutaba un script en Python para extraer secretos de CI/CD de la memoria del ejecutor e imprimirlos directamente en los registros del flujo de trabajo. Cabe destacar que no se observó ninguna filtración externa a servidores controlados por los atacantes; los secretos sólo eran visibles en los registros de los repositorios afectados. Esto supone un riesgo significativo para los repositorios públicos, donde estos registros son accesibles a cualquier persona con acceso de lectura.
Investigaciones posteriores revelaron que el compromiso de tj-actions/changed-files estaba potencialmente vinculado a un ataque a la acción reviewdog/actions-setup@v1, con vulnerabilidad asignada CVE-2025-30154, indicando una brecha más amplia dentro del ecosistema de acciones de GitHub. Todas las versiones de tj-actions/changed-files estaban afectadas el 15 de marzo, ya que los atacantes habían manipulado con éxito las etiquetas de versión existentes. La causa principal fue un Token de Acceso Personal (PAT) de GitHub comprometido perteneciente a la cuenta @tj-actions-bot. Los atacantes utilizaron este PAT para enviar el commit malicioso y se hicieron pasar por la cuenta de usuario "renovate[bot]" para que pareciera que procedía de un usuario legítimo. Este éxito se vio facilitado por la falta de controles de seguridad en el repositorio tj-actions/changed-files, como exigir commits firmados e implementar reglas de protección de ramas y etiquetas.
En respuesta, StepSecurity publicó un reemplazo drop-in seguro, step-security/changed-files, para ayudar en la recuperación. Además, el gist de GitHub que albergaba el script malicioso fue eliminado, y el repositorio comprometido fue retirado temporalmente del mercado de acciones por GitHub. Los mantenedores de tj-actions/changed-files también actuaron con rapidez, eliminando el código malicioso, publicando versiones parcheadas y restaurando el repositorio a un estado seguro, revirtiendo todas las etiquetas de versión a código limpio.
Aunque se ha mitigado la explotación futura, sigue existiendo el riesgo de acciones en caché y secretos ya filtrados. Por lo tanto, la remediación inmediata es crucial, especialmente para los repositorios públicos donde los secretos expuestos son ampliamente accesibles. Los investigadores de seguridad siguen analizando el incidente para comprender plenamente sus implicaciones.
Medidas inmediatas y a corto plazo
-
Realiza una auditoría exhaustiva de GitHub: Identifica todos los repositorios y organizaciones que utilicen GitHub Actions, dando prioridad a los que utilicen tj-actions/changed-files. Emplea la consulta de GitHub proporcionada, entra en la sección "Actions" y busca acciones que incluyan el componente afectado para agilizar este proceso.
-
Examina los registros de flujo de trabajo: Evalúa minuciosamente las ejecuciones anteriores de flujos de trabajo, especialmente en repositorios públicos, en busca de cadenas Base64 con doble codificación, indicativas de exposición de secretos.
-
Implementa restricciones de acceso y rotación de secretos: Restringe temporalmente el acceso a los repositorios potencialmente comprometidos y rota inmediatamente todos los secretos potencialmente expuestos, adhiriéndote al plan de respuesta a incidentes de tu organización.
-
Sustituye las acciones comprometidas: También puedes auditar todos los archivos de flujo de trabajo y sustituir tj-actions/changed-files por una alternativa segura, como step-security/changed-files, eliminando todas las referencias de cada rama.
-
Vincula acciones a commits específicos: Modifica los archivos de flujo de trabajo para vincular todas las acciones de GitHub a commits SHA específicos, garantizando el uso de versiones de confianza y mitigando riesgos futuros.
-
Establece una supervisión sólida: Implementa una supervisión continua de la actividad anómala de CI/CD pipelines, incluidos los endpoints externos inesperados y los patrones de registro inusuales.
-
Integra herramientas SAST y SCA: Utiliza herramientas de pruebas de seguridad de aplicaciones estáticas (SAST) y análisis de composición de software (SCA) para identificar y abordar las vulnerabilidades en el código y las dependencias de forma proactiva.
-
Realiza revisiones periódicas de las dependencias: Establece un proceso de revisión y actualización periódica de todas las dependencias (todo tu SBOM) para minimizar los riesgos.
Conclusión
El compromiso de tj-actions/changed-files sirve como un fuerte recordatorio de las vulnerabilidades inherentes dentro del ecosistema de código abierto, en particular en lo que respecta a la seguridad de la cadena de suministro. Este incidente subraya la necesidad de aplicar prácticas de seguridad rigurosas, que incluyan evaluaciones exhaustivas, una supervisión proactiva y una gestión meticulosa de las dependencias. Permaneciendo vigilantes y adoptando medidas de seguridad sólidas, las organizaciones pueden mitigar significativamente los riesgos asociados a este tipo de ataques. La confianza depositada en componentes de uso generalizado debe validarse continuamente para garantizar la integridad de los CI/CD pipelines.
Para navegar eficazmente por las complejidades de la seguridad de la cadena de suministro, las organizaciones deben priorizar la detección proactiva de y la respuesta a vulnerabilidades. En Fluid Attacks, comprendemos la naturaleza crítica de estas amenazas y ofrecemos soluciones especializadas para ayudar a identificar y remediar vulnerabilidades, incluidas las derivadas de incidentes como el de tj-actions/changed-files. De hecho, podemos ayudarte a detectar y responder a este problema y a otras vulnerabilidades relacionadas con ataques a la cadena de suministro a través de GitHub Actions. Si tu organización necesita el apoyo de expertos, ponte en contacto con nosotros. Nos comprometemos a proporcionarte las herramientas y los conocimientos necesarios para proteger tus procesos de desarrollo.
Comparte
Blog posts recomendados
Quizá te interesen los siguientes posts similares.

¿Por qué calcular riesgos de ciberseguridad con nuestra métrica CVSSF?