GitHub Action de Claude Code: cómo la herramienta Read filtró secretos de CI/CD

¿Qué es esto?

El 5 de junio de 2026, el equipo Microsoft Defender Security Research publicó una vía de inyección de prompts en el GitHub Action de Claude Code de Anthropic. Cuando la acción procesaba contenido de GitHub no confiable — cuerpos de issue, descripciones de pull request, comentarios — una instrucción manipulada podía dirigir la herramienta Read del agente a abrir /proc/self/environ y extraer las variables de entorno del runner, incluida la ANTHROPIC_API_KEY. Microsoft reportó el problema a Anthropic vía HackerOne el 29 de abril de 2026; Anthropic publicó una corrección en Claude Code 2.1.128 el 5 de mayo de 2026, que ahora rechaza incondicionalmente los archivos sensibles de /proc/. Este artículo trata de una falla ya corregida y de la lección sobre fronteras de confianza que ilustra, no de un instructivo.

Cómo funciona

Claude Code Action envuelve el Claude Agent SDK y ejecuta Claude dentro de un runner de GitHub Actions — una VM efímera que puede contener el GITHUB_TOKEN, credenciales de nube, tokens de publicación y claves de API de terceros. Anthropic había anticipado el riesgo: la herramienta Bash se ejecuta en un sandbox Bubblewrap con un entorno saneado (CLAUDE_CODE_SUBPROCESS_ENV_SCRUB, activado automáticamente cuando un workflow puede ser disparado por usuarios sin permiso de escritura). La brecha que encontró Microsoft es que la herramienta Read no pasaba por ese mismo aislamiento. Las operaciones Read eran llamadas directas en proceso, por lo que corrían con acceso completo al entorno del proceso padre — eludiendo el saneamiento que protegía a Bash.

Eso convierte el patrón clásico de «IA en CI/CD» en la trifecta letal: entrada no confiable (un issue de GitHub), acceso a secretos (el entorno del runner) y un canal de salida (WebFetch, un comentario vía GitHub MCP, o el log de la acción). El texto inyectado se ocultaba dentro de un comentario HTML — invisible en el issue renderizado, pero presente en el markdown crudo que el modelo lee. Dos capas defensivas seguían en pie; la carga las sorteó a nivel conceptual:

Capa de defensa                 Por qué falló
-----------------------------  ------------------------------------------------
Rechazo del modelo / system     Petición presentada como «revisión de
prompt                          cumplimiento», con la consigna de recortar los
                                primeros caracteres del valor antes de
                                imprimir — la salida ya no parecía una clave
                                «sk-ant-...»
Secret scanner de GitHub        Como la clave se modificó antes de escribirse en
                               stdout, el detector de patrones conocidos no la
                               reconoció

El atacante reconstruye luego la clave completa anteponiendo el prefijo retirado. Aquí no se reproduce ninguna carga funcional; el mecanismo importante es la idea de lavado: mutar un secreto lo justo para pasar a la vez bajo la heurística de rechazo de un modelo y bajo un escáner basado en expresiones regulares. Microsoft asocia la cadena a técnicas de MITRE ATLAS: inyección de prompts (AML.T0051), invocación de herramientas (AML.T0053), jailbreak (AML.T0054), recolección de credenciales (AML.T0098) y fuga de datos (AML.T0057).

Por qué importa

El valor expuesto era una credencial activa alojada en un runner de build, accesible para cualquiera que pudiera abrir un issue contra un workflow lo bastante permisivo. La misma brecha de confianza también habilitó un segundo resultado observado en la práctica: un bot de triaje con IA coaccionado para leer un archivo de documentación, añadir una etiqueta de imagen XSS invisible y abrir una pull request — un intento de envenenamiento de la cadena de suministro que no necesitaba permiso de escritura del atacante, solo el del agente. El punto de fondo es estructural. GitHub Actions se diseñó para automatización determinista; injertarle un LLM significa que el lenguaje natural se vuelve ejecutable, y que cada issue o comentario se convierte en una instrucción potencial. Una sola frontera de confianza mal evaluada — una herramienta que se saltó el sandbox — bastó para llevarse credenciales de producción. Es la misma clase de debilidad que Comment and Control, vista desde dentro del runner.

Defensas

La corrección ya está disponible, pero la lección de arquitectura aplica a cualquier despliegue de IA en CI:

1. Actualice. Use Claude Code Action / Claude Code 2.1.128 o posterior, que bloquea las lecturas de /proc/. Fije la acción a una versión verificada en vez de a una etiqueta flotante.
2. Aplique la regla de dos para agentes. Ningún workflow de IA debe acumular a la vez: procesamiento de entrada no confiable, posesión de secretos y una herramienta de escritura/comunicación externa. Quite una de las tres ramas — normalmente el canal de salida o el acceso a secretos — en los jobs disparados por contenido no confiable.
3. Mínimo privilegio en cada token. Limite el GITHUB_TOKEN y las claves de proveedor a lo estrictamente necesario, una clave por workflow/entorno, y alerte en el proveedor ante nuevas IP o picos de tráfico.
4. Trate todo el contenido del repositorio como datos hostiles. Endurezca el system prompt para declarar issues, comentarios, diffs y contenidos de archivos como datos no confiables, nunca instrucciones, y fije el agente a una única tarea con rechazo por defecto fuera de alcance.
5. Aísle el runtime y vigile el egreso. No ejecute los jobs de IA disparados por contenido no confiable en runners autoalojados con credenciales permanentes. Restrinja los dominios de salida y revise el log de llamadas a herramientas — la pista de auditoría convierte una fuga silenciosa en una prueba detectada.

Estado

Elemento	Referencia	Fecha	Notas
Reporte a Anthropic (HackerOne)	Microsoft TI	2026-04-29	Investigación black-box → white-box sobre Claude Code Action
Corrección en Claude Code 2.1.128	Anthropic	2026-05-05	La herramienta Read rechaza sin condición los archivos sensibles de /proc/
Divulgación pública	Microsoft Security Blog	2026-06-05	Elusión del saneamiento por Read; /proc/self/environ → ANTHROPIC_API_KEY
Cobertura	The Hacker News, CyberSecurityNews	2026-06-05 → 2026-06-06	Reportes que corroboran

La conclusión no es que la acción de un proveedor fuera singularmente insegura — toda integración de IA en CI comparte esta forma. Es que el aislamiento a nivel de herramienta debe ser uniforme: un sandbox que protege a Bash pero no a Read es un sandbox con una puerta abierta, y el contenido no confiable de GitHub terminará por encontrarla.