Hackean la GitHub Action `tj-actions/changed-files`: 23,000 repositorios la usan

• Una GitHub Action popular usada para rastrear cambios en cada rama fue comprometida, y mediante un commit malicioso se intentó filtrar secretos de CI/CD
• 23,000 repositorios se vieron afectados, GitHub eliminó esta acción y ya no se puede usar
• Se debe reemplazar por una acción alternativa y, como existe la posibilidad de que los secretos hayan quedado expuestos en logs públicos de workflows, es indispensable verificarlo y rotar las claves
• Harden-Runner de StepSecurity detectó el incidente, y están distribuyendo gratis la alternativa reforzada step-security/changed-files

Resumen del incidente

• tj-actions/changed-files se usa en más de 23,000 repositorios y fue comprometida
  • Los atacantes modificaron el código de la acción y redirigieron las etiquetas de versión a un commit malicioso
  • Como resultado, los secretos de CI/CD se imprimían en los logs de compilación de GitHub Actions
• Existe la posibilidad de que secretos hayan quedado expuestos en logs públicos de workflows
• El problema se descubrió después de que Harden-Runner detectara un endpoint inesperado
• Un script malicioso en Python hacía que se volcaran secretos desde el proceso Runner Worker
• Todas las etiquetas quedaron apuntando al mismo hash de commit malicioso (0e58ed8671d6b60d0890c21b07f8835ace038e67)

Medidas de respuesta de GitHub

• GitHub eliminó la acción tj-actions/changed-files y suspendió su uso
• El CVE oficial es CVE-2025-30066

Cómo recuperarse

• 1. Usar la acción alternativa segura proporcionada por StepSecurity

  • Reemplazar la acción tj-actions/changed-files por step-security/changed-files@v45

• 2. Eliminar todas las referencias a tj-actions/changed-files

  • Buscar y eliminar referencias a tj-actions/changed-files en la base de código:

    git grep -l "tj-actions/changed-files"  
    

• 3. Auditar los logs de ejecución de workflows de GitHub Actions

  • Es necesario revisar los logs recientes para verificar si hubo filtración de secretos
  • Si se encuentran secretos expuestos, deben rotarse (restablecerse) de inmediato

• 4. Configurar una lista de permitidos para GitHub Actions

• Configurar la lista de permitidos para que solo se ejecuten GitHub Actions de confianza:
  • Puede configurarse en GitHub:
    • Settings → Actions → Allow select actions

• 5. Configurar StepSecurity Harden-Runner

  • En Harden-Runner se puede configurar el monitoreo del tráfico de red y de la ejecución de workflows

Próximos pasos

• El problema ya fue reportado a GitHub → GitHub issue: #2463
• El repositorio de tj-actions/changed-files fue eliminado
• Quedó registrado oficialmente como CVE-2025-30066
• Con StepSecurity Harden-Runner se pueden detectar y prevenir problemas de seguridad similares
• Se recomienda configurar Harden-Runner para reforzar la postura de seguridad y realizar monitoreo en tiempo real

[dl57934]

Anoche no funcionaba, pero ahora otra vez sí.

[GN⁺]

Opiniones en Hacker News

• El autor y mantenedor de Renovate explica el escenario del ataque

  • El atacante obtuvo permisos de escritura en el repositorio tj-actions/changed-files
  • El atacante suplantó un commit de Renovate para disfrazarlo como un commit reciente
  • Esta suplantación no fue para engañar al PR, sino simplemente para generar confusión
  • El commit aparecía como Unverified, y la mayoría de la gente no obliga a usar solo commits firmados
  • El verdadero Renovate Bot propone PR para actualizar dependencias
  • Algunas personas tenían activado el auto-merge, pero no es la configuración predeterminada
  • Este incidente recuerda que mucha gente cree erróneamente que los tags de git son inmutables

• En los últimos años ha disminuido la confianza en dependencias y extensiones de terceros

  • Si un paquete de npm tiene muchas dependencias, no lo instalo
  • No instalo extensiones de vscode ni de Chrome
  • Es muy común que agreguen malware o cambien la licencia
  • Al ver el árbol de dependencias de eslint, uno se pregunta si realmente puede confiar en todo

• El repositorio volvió a estar en línea y el desarrollador dio una explicación

  • El ataque se originó en el token PAT de la cuenta @tj-actions-bot
  • Se reforzó la seguridad de la cuenta y GitHub revocó el PAT comprometido

• En Clickhouse investigaron github_events para identificar la cuenta usada en el ataque

  • Las cuentas "2ft2dKo28UazTZ", "mmvojwip" resultan sospechosas

• Impacta que la forma de ejecutar CI/CD sea listar repositorios arbitrarios de GitHub

  • Con el aumento de los LLMs, el problema se vuelve más grave
  • Las tareas importantes deberían ejecutarse manualmente

• El cofundador de StepSecurity explica cómo detectaron el incidente de seguridad

  • Harden-Runner detectó anomalías al monitorear llamadas de red en workflows de GitHub Actions

• El problema es que la forma predeterminada de usar GitHub Actions depende de tags de git que no son inmutables

  • Como el algoritmo de hash SHA-1 puede tener colisiones, hace falta soporte para SHA-256

• Se planea introducir GitHub Actions inmutables

  • Hacer fork de Actions o usar hashes de commit

• El proyecto maven-lockfile explica un PR que fue fusionado automáticamente

  • El Renovate Bot real hizo auto-merge del commit del Renovate Bot falso

• GitHub Actions debería usar lockfile para las dependencias

  • La notación Semver es una buena solución para resolver este problema