Tus secretos CI/CD, robados desde una issue de GitHub

Cualquiera que pueda abrir una issue en tu repositorio pudo, hasta el 5 de mayo de 2026, llevarse tus secretos CI/CD robados desde GitHub Actions sin escribir una sola línea de código. El bug estaba en la herramienta Read de Claude Code corriendo dentro de GitHub Actions. Anthropic lo parchó el 5 de mayo de 2026 en la versión 2.1.128, seis días después de recibir el reporte.

Claude Code es la herramienta de línea de comandos de Anthropic que te permite interactuar con el modelo Claude desde la terminal o desde un pipeline de CI/CD. Su GitHub Action procesa eventos del repositorio (issues, pull requests, comentarios) y actúa sobre ellos con herramientas como Bash, Read y WebFetch. La falla permitía que contenido no confiable de una issue forzara la lectura de variables de entorno del runner.

¿Cuál es el riesgo real? Cualquiera que pueda comentar una issue

Acá está lo incómodo. No hacía falta tener acceso al código. No hacía falta permiso de push. No hacía falta ser maintainer ni colaborador. Alcanzaba con poder abrir una issue, algo que en cualquier repositorio público puede hacer literalmente cualquier persona con una cuenta de GitHub.

Ese es el cambio de escala. Las vulnerabilidades de CI/CD que conocíamos solían exigir, al menos, un PR malicioso que alguien tuviera que aprobar o ejecutar. Esta no. El atacante tipea texto en un formulario web, le da a “submit”, y si tu workflow tenía Claude Code escuchando eventos de issues, el agente hacía el trabajo sucio solo. Según el writeup de Microsoft, el flujo completo no requería ningún exploit binario ni malware.

Anthropic respondió rápido (seis días de la divulgación al fix es un tiempo que muchos vendors querrían tener). Pero la velocidad del parche no es la lección. La lección es qué se mandó a producción en primer lugar, y qué dice eso del resto de los stacks con agentes que hoy están corriendo en tu pipeline.

¿Cómo funciona Claude Code dentro de GitHub Actions?

Mucha gente metió Claude Code en sus Actions para automatizar tareas que antes hacía a mano: revisar un PR, sugerir cambios, responder issues, generar documentación, triagear bugs. Lo configurás como un workflow que se dispara con eventos de GitHub y listo, tenés un revisor que no duerme.

El problema es cómo decide qué hacer. El agente lee el contenido del evento que lo disparó (el cuerpo de la issue, el comentario, la descripción del PR) y lo toma como instrucción. Tiene herramientas para actuar: Bash para ejecutar comandos, Read para leer archivos, WebFetch para traer contenido de la web, más las APIs de GitHub. Si el contenido que lee viene de un atacante, el atacante está, en los hechos, dándole órdenes al agente. Complementá con comparativa de herramientas CI/CD modernas.

Eso ya se sabía como riesgo teórico (se llama inyección de prompts). Lo nuevo acá fue que una de las herramientas tenía acceso directo a los secretos del runner.

¿Qué es /proc/self/environ y por qué expone tus secretos?

En Linux, /proc/self/environ es un pseudo-archivo que expone todas las variables de entorno del proceso que lo lee. No es un archivo real en disco, es una ventana que el kernel te da al entorno del propio proceso. Si leés ese archivo desde un proceso, ves exactamente las variables que ese proceso tiene cargadas.

¿Y qué pone GitHub Actions en las variables de entorno del runner? Casi todo lo importante. Cuando definís un secreto en tu workflow y se lo pasás a un step, termina en el entorno del proceso. Ahí viven la ANTHROPIC_API_KEY, el GITHUB_TOKEN, tokens de publicación de npm, credenciales de AWS, claves de deploy. La exfiltración de secretos de CI/CD por esta vía es una clase de ataque ya conocida.

La herramienta Read corría dentro del mismo proceso que tenía esos secretos cargados. Entonces leer /proc/self/environ era, para Read, tan fácil como leer cualquier otro archivo del repo.

El ataque: comentarios HTML que vos no ves pero el agente sí

Ponele que sos maintainer de un repo open source. Te llega una issue que parece un reporte de bug normal, prolijo, hasta con pasos para reproducir. La leés en GitHub y no ves nada raro. Lo que no ves es que el cuerpo trae un comentario HTML, esas etiquetas <!-- --> que el navegador no renderiza, con instrucciones adentro para el agente.

El navegador esconde ese comentario. El agente, no. Claude Code procesa el texto crudo del cuerpo de la issue, comentario incluido, y lo interpreta como una orden. La instrucción oculta le pedía, básicamente, leer /proc/self/environ y devolver el contenido en algún lado donde el atacante pudiera verlo (un comentario público de la issue, por ejemplo). Subís el reporte, el workflow se dispara, el agente lee tu entorno, escribe tus secretos en un comentario, y vos te enterás cuando ya es tarde. En cuando evalúas GitHub Actions frente a Jenkins profundizamos sobre esto.

Cero malware. Cero exploit. Solo texto.

¿Por qué Read era vulnerable y Bash no?

Acá viene lo interesante, porque Anthropic no fue descuidado con todo. Con Bash hicieron las cosas bien: aislamiento estilo bubblewrap, y limpieza de variables de entorno para los subprocesos cuando un usuario no confiable podía influir en el workflow. El instinto correcto, si un atacante puede manejar al agente, no dejes que el subproceso del agente herede tus secretos.

Read se quedó afuera de ese sandbox. Corría in-process, dentro del mismo proceso del agente, sin el scrubbing de entorno que sí tenía Bash. Y como vivía en el mismo proceso, tenía el entorno completo a mano. El equipo blindó la puerta principal y dejó una ventana sin traba.

¿La moraleja de arquitectura? Sandboxear “la herramienta peligrosa” no alcanza si otra herramienta, en apariencia inocente como “leer un archivo”, tiene el mismo nivel de acceso al proceso. Es un problema de superficie completa, no de una sola herramienta.

¿Quién estuvo expuesto y qué secretos estaban en juego?

En riesgo estaba cualquier repositorio que corriera Claude Code GitHub Action disparándose con eventos donde un usuario externo pudiera escribir: issues y comentarios, sobre todo. Los repos públicos eran los más expuestos, porque ahí cualquiera abre una issue. Pero un repo privado con colaboradores externos o contribuciones de la comunidad tampoco zafaba del todo.

Los secretos en peligro eran los típicos de un pipeline real:

• ANTHROPIC_API_KEY: la clave que el propio workflow usa para hablar con Claude, con el costo de facturación que eso implica si te la roban.
• GITHUB_TOKEN: el token del runner, que según sus permisos puede escribir en el repo, crear releases o tocar otros recursos.
• Tokens de npm y registries: el camino directo a un ataque de cadena de suministro, publicando paquetes maliciosos con tu nombre.
• Credenciales de cloud y deploy: claves de AWS, tokens de despliegue, accesos a tu infraestructura de hosting.

La ventana de exposición va desde que se lanzó la herramienta con Read sin sandbox hasta el parche del 5 de mayo de 2026. Si corriste el workflow vulnerable en ese período sobre un repo donde alguien externo podía comentar, asumí que esos secretos pudieron filtrarse y rotalos.

Cómo proteger tus secretos en GitHub Actions ahora

Lo primero y obvio: actualizá Claude Code a 2.1.128 o superior. Pero el parche tapa este bug puntual, no la clase de problema. Estas son las defensas que conviene tener sí o sí, exista o no este CVE: Relacionado: análisis profundo sobre seguridad en GitHub.

• Pasá secretos a nivel de step, no de job: dale a cada step solo los secretos que necesita, así una herramienta comprometida no ve todo el set de credenciales.
• Limitá los permisos del GITHUB_TOKEN: definí permissions: con el mínimo necesario (idealmente read-only) en vez de heredar el default amplio.
• No dispares agentes con eventos de usuarios no confiables: si tenés un repo público, evitá que issues o comentarios externos activen workflows con acceso a secretos. Usá pull_request_target con muchísimo cuidado.
• Sanitizá el contenido antes de pasarlo al agente: tratá el cuerpo de issues y comentarios como input hostil, y filtrá o escapá los comentarios HTML antes de que el agente los lea.
• Usá GitHub Apps con permisos granulares: en vez del token genérico, una App con scopes acotados reduce el daño si algo se filtra.
• Auditá los logs de tus Actions: revisá ejecuciones pasadas en repos públicos buscando lecturas raras o comentarios con datos que parezcan credenciales.
• Apagá Claude Code donde no lo uses: si un repo no necesita el agente en CI, sacalo. Menos superficie, menos riesgo.

Y algo transversal: tratá tus credenciales de deploy como rotables. Si tu infraestructura de hosting (por ejemplo, una cuenta de donweb.com o cualquier proveedor cloud) tiene tokens en el pipeline, tené el procedimiento de rotación listo y probado antes de necesitarlo, no después de la filtración.

Qué está confirmado y qué no

Confirmado:

• La falla existió en la herramienta Read de Claude Code GitHub Action, según el writeup de Microsoft Threat Intelligence publicado el 10 de junio de 2026.
• Anthropic la parchó el 5 de mayo de 2026 en Claude Code 2.1.128, seis días después de la divulgación.
• Bash estaba sandboxeado; Read corría in-process y podía leer /proc/self/environ.
• El vector confirmado es un comentario HTML oculto en una issue con instrucciones para el agente.

Lo que no está claro:

• No hay, por ahora, un conteo público de cuántos repos fueron explotados de verdad en producción. La existencia de la falla no prueba explotación masiva.
• La fecha exacta de la divulgación inicial no figura de forma uniforme en todas las fuentes; lo consistente es la ventana de seis días hasta el parche.

Errores comunes al protegerse de este ataque

• Creer que actualizar alcanza: parcheás Claude Code y listo, pensás. Pero si tus secretos ya se filtraron durante la ventana de exposición, siguen comprometidos hasta que los rotes. El parche frena lo nuevo, no lo que ya salió.
• Confiar en que “mi repo es privado”: si tenés colaboradores externos o aceptás contribuciones, el repo privado no te blinda. Cualquiera con acceso a issues entra en el modelo de amenaza.
• Dejar el GITHUB_TOKEN con permisos default: mucha gente nunca define el bloque permissions: y hereda un token con más alcance del necesario. Es el error más fácil de corregir y el que más reduce el daño.
• Tratar el input de issues como confiable: si tu workflow pasa el cuerpo crudo de una issue a un agente sin filtrar, estás invitando a la inyección de prompts. El contenido externo es hostil por defecto.

Preguntas Frecuentes

¿Cómo pueden robar mis secretos desde una issue en GitHub?

Un atacante abre una issue con un comentario HTML oculto que contiene instrucciones para el agente Claude Code de tu workflow. El agente lee ese comentario aunque no se vea en GitHub, ejecuta la herramienta Read contra /proc/self/environ y expone las variables de entorno del runner, donde viven tus secretos.

¿Qué es Claude Code y cuál era la vulnerabilidad?

Claude Code es la herramienta CLI de Anthropic para interactuar con el modelo Claude, también disponible como GitHub Action. La vulnerabilidad era que su herramienta Read corría in-process sin sandbox, así que podía leer las variables de entorno del proceso y filtrar secretos del pipeline.

¿Por qué /proc/self/environ expone las variables de entorno?

/proc/self/environ es un pseudo-archivo de Linux que muestra todas las variables de entorno del proceso que lo lee. GitHub Actions carga los secretos del workflow en el entorno del proceso, así que leer ese archivo equivale a leer las claves y tokens activos en ese momento.

¿Cuándo se publicó el parche?

Anthropic publicó el parche el 5 de mayo de 2026 en Claude Code 2.1.128, seis días después de recibir la divulgación. Microsoft Threat Intelligence publicó el análisis técnico completo el 10 de junio de 2026.

¿Tengo que rotar mis secretos si usé el workflow vulnerable?

Sí, si corriste el workflow vulnerable antes del 5 de mayo de 2026 sobre un repositorio donde usuarios externos podían abrir issues o comentar. Rotá ANTHROPIC_API_KEY, GITHUB_TOKEN, tokens de npm y cualquier credencial de deploy que estuviera en el entorno del runner.

Conclusión

Lo que cambió no es una vulnerabilidad más en una lista de CVEs. Cambió el costo de atacar tu pipeline: pasó de “necesito un PR malicioso aprobado” a “abro una issue y escribo texto”. Cuando metés un agente con herramientas en tu CI/CD, cada input que el agente lee se vuelve una superficie de ataque, y el contenido de una issue lo escribe cualquiera.

Hacé tres cosas hoy: actualizá Claude Code a 2.1.128 o superior, rotá los secretos que estuvieron expuestos en la ventana vulnerable, y revisá qué eventos disparan agentes con acceso a credenciales. Y si tenés otros stacks con agentes corriendo en producción, asumí que pueden tener el mismo agujero hasta que verifiques lo contrario. Anthropic parchó rápido; el resto de tu infraestructura agéntica todavía es tu responsabilidad.

Fuentes

• Microsoft Security Blog – Securing CI/CD in an agentic world: Claude Code GitHub Action case
• AgentShield (dev.to) – Anyone with GitHub issue access can steal your CI/CD secrets
• Flatt Security Research – Poisoning Claude Code: one GitHub issue to break the supply chain
• The Hacker News – Claude Code GitHub Action flaw
• step-security GitHub Actions Goat – Exfiltrating CI/CD Secrets