Las GitHub Actions habilitadas para IA pueden ser secuestradas con un solo comentario, filtrando claves de API, tokens de la nube y otros secretos. Un investigador de seguridad descubrió 22 repositorios de código abierto donde un activador público, una herramienta de IA ejecutada con una bandera “skip prompts” y secretos expuestos crean una ruta de exfiltración directa.

Cómo funciona el fallo

Los proyectos ahora integran agentes de IA —Claude Code, la GitHub Copilot CLI y herramientas similares— directamente en los pipelines de CI. Un paso del workflow ejecuta un comando de shell y, a menudo, añade una bandera que indica a la herramienta que ignore las solicitudes de permiso interactivas. Cuando el workflow se inicia mediante cualquier entrada pública —un issue, un comentario o el título de un pull request— el atacante solo necesita publicar una línea de texto que la IA tratará como un comando.

La IA, que ya cuenta con acceso de shell sin restricciones debido a la bandera “skip prompts”, lee cualquier variable de entorno o archivo que el workflow exponga. Si el job también carga secretos —claves de API, tokens de servicios en la nube o credenciales completas de cuentas de servicio— la IA redirige esos valores a un servidor controlado por el atacante. Sin cambios en el código, sin nuevas dependencias, solo un comentario que parece inofensivo.

Ejemplos del mundo real

El investigador confirmó tres repositorios vulnerables que ya han sido parcheados:

  • pymc-labs/pymc-marketing – un issue público podría utilizarse para acceder a una clave de la API de Anthropic mediante inyección de prompts.
  • MadAppGang/dingo – el workflow otorgaba a Claude Code acceso completo a Bash y exponía dos secretos en el mismo job.
  • MadAppGang/claudish – reutilizaba la misma plantilla vulnerable que el proyecto dingo.

Un hallazgo involucró una clave de cuenta de servicio en la nube activa, la cual el investigador reportó directamente al equipo de seguridad de un importante proveedor de IA. Doce informes adicionales están pendientes con los mantenedores; sus nombres se mantienen en reserva hasta que los arreglos se implementen.

Lo que está en juego

Cuando un atacante extrae un secreto, el daño puede ser inmediato y costoso. Una clave de cuenta de servicio en la nube otorga acceso sin restricciones a recursos de computación, buckets de almacenamiento y otros servicios de pago. Una clave de API de un proveedor de modelos de lenguaje de gran tamaño puede ejecutar consultas ilimitadas, lo que podría generar miles de dólares en cargos. Debido a que el exploit se ejecuta dentro del entorno de CI, la brecha puede propagarse hacia abajo: cualquier artefacto construido en el runner comprometido puede contener código malicioso, convirtiendo un solo repositorio en un vector de la cadena de suministro.

Para los equipos que dependen de la CI asistida por IA, la disyuntiva es clara. La conveniencia del código autogenerado, el linting o la documentación debe sopesarse frente al riesgo de que un comentario público se convierta en una puerta trasera encubierta.

Por qué es fácil pasar por alto la vulnerabilidad

El investigador presentó inicialmente seis informes que luego fueron retirados. Las retractaciones se debieron a suposiciones sobre las comprobaciones de permisos de GitHub Actions, no a una revisión línea por línea del código fuente de la Action. La documentación y la intuición pueden ser engañosas; la única forma fiable de confirmar la postura de seguridad de un paso habilitado para IA es inspeccionar el código que ejecuta la herramienta y el YAML del workflow que la conecta.

Lista de verificación de mitigación

Si ejecutas una CLI de IA o una herramienta similar dentro de un workflow de GitHub Actions, responde estas dos preguntas antes de realizar un merge:

  1. ¿Quién puede activar el workflow? Limita los activadores a eventos de confianza (por ejemplo, pushes a ramas protegidas) o requiere aprobación explícita para las ejecuciones iniciadas por colaboradores externos. Evita on: issue_comment o on: issues sin controles adicionales.

  2. ¿Qué secretos se cargan en el mismo job? Nunca expongas claves de API, tokens de la nube o credenciales de cuentas de servicio en un job que también ejecute un agente de IA con acceso de shell sin restricciones. Separa los pasos con muchos secretos en jobs o runners aislados que no invoquen herramientas de IA.

Pasos adicionales de endurecimiento (hardening):

  • Elimina la bandera que omite las solicitudes de permiso, obligando a la herramienta de IA a solicitar una confirmación explícita antes de ejecutar comandos de shell.
  • Añade un paso que sanee o anonimice cualquier variable de entorno que la herramienta de IA pueda leer.
  • Utiliza runners auto-alojados (self-hosted) con controles de salida de red para bloquear la exfiltración a endpoints arbitrarios.

Contrapunto: la utilidad de la IA en CI

Los defensores argumentan que las ganancias de productividad superan el riesgo. Las sugerencias de código automatizadas reducen el tiempo de revisión y las pruebas impulsadas por IA detectan errores más temprano. Sin embargo, la misma conveniencia amplía la superficie de ataque. La clave no es abandonar la IA, sino tratar cualquier herramienta con privilegios a nivel de shell como un vector potencial.

Qué observar a continuación

Los hallazgos ya han suscitado debates en los foros de seguridad de GitHub sobre la implementación de permisos predeterminados más estrictos para las Actions habilitadas para IA. Las futuras actualizaciones de la plataforma podrían incluir:

  • Un parámetro que obligue a las herramientas de IA a ejecutarse en un entorno de sandbox sin acceso directo a la shell.
  • Detección integrada de patrones de inyección de prompts en el cuerpo de los issues o en los comentarios.
  • Alertas automatizadas cuando un workflow combine disparadores públicos con tareas que contengan secretos.

Por ahora, la responsabilidad recae en los mantenedores de los repositorios. Los 22 repositorios identificados demuestran que el problema no es un caso aislado; cualquier proyecto que replique el mismo patrón de workflow es vulnerable. Una auditoría rápida de las configuraciones de CI puede revelar el problema antes que un atacante.

En conclusión: Una sola línea de texto en un issue público de GitHub puede otorgar a un agente de IA el control total sobre su entorno de CI y robar los secretos que almacene allí. Verifique quién puede ejecutar sus workflows, mantenga los secretos alejados de los pasos impulsados por IA y examine minuciosamente cada parámetro que otorgue permisos sin control. El coste de una brecha de seguridad supera con creces el esfuerzo de una revisión disciplinada.