Claude Code Action: confiar ciegamente en los «bots» abrió una vía de cadena de suministro

¿De qué se trata?

El 1 de junio de 2026, RyotaK, de GMO Flatt Security, publicó Poisoning Claude Code: One GitHub Issue to Break the Supply Chain, documentando una falla en el modelo de permisos de Claude Code GitHub Action — el flujo de trabajo que Anthropic distribuye para integrar Claude en CI/CD (triaje de incidencias, etiquetado, revisión de código, comandos slash). El hallazgo central: el control de acceso de escritura de la acción podía eludirse por cualquier atacante que registrara su propia GitHub App, dejando que contenido no confiable llegara a un flujo diseñado para procesar solo entradas de confianza. Encadenado con inyección de prompts indirecta, ese bypass conducía al robo de las credenciales usadas para generar un token de repositorio privilegiado — y, como el propio repositorio de la acción ejecutaba un flujo vulnerable, a una vía para comprometer todos los proyectos que dependen de ella aguas abajo.

RyotaK informó del bypass a Anthropic el 12 de enero de 2026; Anthropic lo corrigió cuatro días después y reforzó las defensas durante la primavera, con las correcciones incluidas en claude-code-action v1.0.94. Anthropic calificó los problemas con 7,8 según CVSS v4.0 y pagó una recompensa. La publicación siguió a la divulgación pública, y el investigador señala que variantes de configuración incorrecta del mismo patrón ya se habían explotado en el mundo real antes de la publicación.

Cómo funciona

Por defecto, el flujo tiene acceso de lectura y escritura al código, incidencias, pull requests, discusiones y archivos de flujo del repositorio. Como esos permisos son amplios, se supone que la acción es selectiva respecto a quién puede activarla — solo usuarios con acceso de escritura. Ese control residía en una función checkWritePermissions que devolvía true para cualquier actor cuyo nombre terminara en [bot], asumiendo que las GitHub Apps son entidades de confianza que instalan los administradores.

Esa suposición no se sostiene en repositorios públicos. Cualquiera puede registrar una GitHub App, instalarla en un repo de su propiedad y usar su token de instalación para abrir una incidencia o pull request en cualquier repositorio público — GitHub concede a las Apps acceso implícito a los recursos públicos. La acción veía un actor terminado en [bot] y dejaba pasar el contenido controlado por el atacante. El modo tag incluía una verificación adicional (checkHumanActor); el modo agente, en aquel momento, no.

A partir de ahí, el atacante se apoyaba en la inyección de prompts indirecta — instrucciones ocultas en el contenido que lee el agente, para que el modelo las siga en lugar de su tarea. En la prueba de concepto documentada, el texto inyectado se redactaba para que el agente «se recuperara» de un supuesto error de lectura ejecutando comandos incrustados, alcanzando /proc/self/environ para extraer las variables de entorno del runner. Los valores decisivos son el par de credenciales que GitHub Actions usa para solicitar un token OIDC; ese token se intercambia por un token de instalación de la Claude GitHub App con acceso de escritura. Roba el par, repite el intercambio y obtienes acceso de escritura al código y los flujos de la víctima. Apúntalo al propio repositorio de la acción y el veneno se propaga aguas abajo. Aquí no se reproduce ningún payload funcional; el interés está en el fallo de la frontera de confianza, y el investigador solo validó la cadena en sus propios repositorios de prueba.

Una variante más sencilla evitaba por completo el truco del bot: el flujo de ejemplo de triaje de incidencias que se distribuía fijaba allowed_non_write_users: "*", y el agente publicaba resúmenes de tareas en el panel público de la ejecución — un canal de exfiltración listo para usar, heredado por numerosos despliegues copiados y pegados.

Por qué importa

Es el modelo de amenaza de la CI/CD agéntica hecho realidad. Un flujo que (1) ingiere contenido de GitHub no confiable, (2) posee secretos y tokens, y (3) puede actuar mediante herramientas reúne exactamente la combinación peligrosa contra la que advierten la tríada letal y la regla de dos de los agentes — y aquí las tres convivían en una sola acción. El bypass convertía un diseño «solo entradas de confianza» en una superficie «cualquier internauta», y el radio de impacto no era un repo sino todo el grafo de dependencias bajo una acción muy usada, incluido el del propio mantenedor. Se suma al patrón «Comment and Control», donde títulos de PR y cuerpos de incidencias filtraban secretos de GitHub Actions en tres proveedores, y a una fuga vía la herramienta Read que alcanzaba el mismo archivo /proc/self/environ por otra vía. La lección se repite: los controles de identidad basados en patrones de cadena no son autorización, y la inyección de prompts sigue sin resolverse allí donde un agente con tokens reales lee texto controlado por un atacante.

Defensas

• Actualice a claude-code-action v1.0.94 o posterior. La corrección añade una verificación de actor humano al modo agente, desactiva por defecto el canal del resumen de ejecución, envuelve gh para bloquear argumentos propicios a la exfiltración y depura las variables de entorno de los procesos hijos.
• Audite todo flujo que permita a usuarios sin permiso de escritura — o a bots — activar el agente. Si procesa entradas no confiables, no exponga ningún secreto más allá del mínimo, y elimine herramientas o permisos capaces de exfiltrar (WebFetch, Bash arbitrario, git push, incluso gh issue view con un argumento URL).
• Aplique la regla de dos. Nunca deje que un mismo flujo lea entradas no confiables, posea credenciales sensibles y actúe hacia el exterior al mismo tiempo. Retire una de las tres patas — fije la tarea, elimine el secreto o coloque la escritura tras una validación humana.
• Trate la identidad del actor como dato, no como autorización. Un sufijo [bot], un nombre de autor o una insignia de «verificado» es contexto falsificable; imponga controles reales de permiso y procedencia en el lado del servidor.
• Adopte arquitecturas de agentes CI/CD basadas en el aislamiento. Véase nuestra cobertura de la arquitectura de seguridad de GitHub Agentic Workflows — agentes sin secretos, cortafuegos de flujo y escrituras en cola y verificadas — como respuesta estructural en lugar de parches a nivel de prompt.

Estado

Elemento	Detalle
Divulgado por	RyotaK, GMO Flatt Security
Reporte / primera corrección	2026-01-12 / 2026-01-16 (cuatro días)
Publicación	2026-06-01
Componente afectado	claude-code-action (modo agente + flujo de ejemplo de triaje)
Corregido en	claude-code-action v1.0.94
Gravedad	CVSS v4.0 7,8 (alta), según Anthropic
Variantes explotadas	Flujo de triaje de Cline (robo de token npm, feb. 2026); sin indicios públicos de que la vía de envenenamiento de la acción alcanzara un objetivo real

Se trata de una clase de vulnerabilidad divulgada y corregida en una integración CI/CD. Los nombres de componentes y las cifras son los reportados por el artículo de GMO Flatt Security, The Hacker News y el commit de corrección de Anthropic.