Comment and Control: un mismo patrón de inyección de prompt, tres agentes filtrando secretos de GitHub Actions

¿De qué se trata?

El 15 de abril de 2026, el investigador Aonan Guan publicó Comment and Control, la primera demostración pública de un mismo patrón de inyección de prompt comprometiendo tres de los agentes de IA más desplegados sobre GitHub Actions: Anthropic Claude Code Security Review, Google Gemini CLI Action y GitHub Copilot Agent. El trabajo se coordinó con Zhengyu Liu y Gavin Zhong, de Johns Hopkins University. En cada caso, un dato de GitHub controlado por el atacante — un título de pull request, un comentario de issue o un comentario HTML oculto en el cuerpo de un issue — secuestra al agente y exfiltra los secretos de GitHub Actions del propio repositorio anfitrión, a través del propio GitHub. No se requiere infraestructura externa.

Una actualización coordinada del 4 de mayo de 2026 detalla la cronología. Anthropic calificó inicialmente el hallazgo de Claude Code con CVSS 9.3, lo elevó a 9.4 en noviembre de 2025 y lo rebajó a «None» el 20 de abril de 2026, afirmando que la acción «no está diseñada para resistir la inyección de prompt». El VRP de Google pagó 1 337 USD. GitHub cerró primero el reporte de Copilot como «Informative» antes de reabrirlo y pagar 500 USD. Ninguno de los tres proveedores emitió CVE.

Cómo funciona

El patrón compartido cabe en una frase: dato de GitHub no confiable → el agente IA lo procesa → el agente ejecuta herramientas → las credenciales se exfiltran a través de GitHub.

En Claude Code Security Review, el título de la PR se interpola directamente en el prompt del agente sin sanitización, y la CLI claude se invoca sin --allowed-tools ni --disallowed-tools. El proceso hijo hereda así todas las variables de entorno del runner — incluidas ANTHROPIC_API_KEY y GITHUB_TOKEN. Un título manipulado instruye al agente a ejecutar comandos shell como ps auxeww y a incluir el entorno capturado en su JSON de «security finding», que luego se publica como comentario de PR — visible para cualquiera, incluido el atacante.

En Gemini CLI Action, el atacante inyecta una falsa «Trusted Content Section» en un comentario de issue, después del bloque legítimo "Additional Content" que el agente incorpora a su contexto. El agente trata la sección forjada como autorizada y publica GEMINI_API_KEY como comentario de issue.

El caso GitHub Copilot Agent es el más interesante porque tres capas en tiempo de ejecución — filtrado de entorno, escaneo de secretos y firewall de red — se diseñaron específicamente para impedir este robo. Las tres se sortean:

# Ilustrativo — no es código de exploit
1. Filtro (zJe[] / UU()): oculta ~20 secretos, pero solo en el subshell bash.
   ps auxeww desde ese bash lee /proc/$PPID/environ del proceso padre Node.js
   y del servidor MCP, que conservan el entorno completo.
2. Escaneo de secretos: regex sobre prefijos ghs_, ghu_.
   Codificar el volcado en base64 antes de `git push` neutraliza esos patrones.
3. Firewall de red: github.com está necesariamente en la lista permitida.
   El blob base64 se commitea como un archivo normal en una PR normal.

El disparador es invisible para un humano: el payload vive en un comentario HTML del cuerpo del issue. El renderizado Markdown de GitHub oculta el comentario, la víctima solo ve el texto inocente, asigna el issue a Copilot y el agente — que lee el Markdown crudo — ejecuta las instrucciones ocultas.

Por qué importa

No es un bug de parser. Títulos de PR, cuerpos de issues y comentarios son datos legítimos que el agente debe leer para hacer su trabajo. El conflicto es arquitectónico: el mismo runtime alberga simultáneamente secretos privilegiados y procesa entrada no confiable de colaboradores externos. Las defensas apiladas encima — blocklists, escáneres de secretos, allowlists de red — ganan tiempo pero terminan perdiendo frente a la próxima codificación, el próximo proceso hermano, el próximo destino permitido. Anthropic bloqueó ps; cat /proc/*/environ produce el mismo resultado. Es el lethal trifecta del que Simon Willison advierte desde hace tiempo (datos privados, entrada no confiable, vector de exfiltración) materializado en tres agentes de producción a la vez.

La divulgación también es una señal de gobernanza. Tres proveedores importantes pagaron discretamente menos de 2 000 USD acumulados en recompensas, sin CVE y sin advisories públicos. Los usuarios anclados a versiones vulnerables no tienen canal estándar para enterarse de que están afectados.

Defensas

Acciones concretas para esta semana, derivadas de la divulgación y del análisis que la rodea:

1. Auditar qué dispara sus agentes IA. Cualquier workflow disparado por pull_request_target, issues o issue_comment que exponga secretos del repositorio al agente está en el perímetro. Migrar a disparadores seguros para forks siempre que sea posible.
2. Allowlistar herramientas, nunca blocklistar. Pasar --allowed-tools a Claude Code, restringir capacidades shell/archivo/red en cada agente y rechazar la postura por defecto de «el agente hereda todo el entorno del runner».
3. Tratar a los agentes como practicantes recién llegados. Aplicar need-to-know y mínimo privilegio tanto a herramientas como a secretos. Un agente de revisión de código rara vez necesita un GITHUB_TOKEN con escritura ni claves API de producción en el mismo proceso.
4. Eliminar secretos en la frontera de proceso, no solo en el subshell. El filtro UU() de Copilot demuestra por qué filtrar únicamente el shell hijo es insuficiente: ps y /proc/*/environ recorren todos los PID. Ejecutar el agente en un runtime separado que nunca vea el conjunto ampliado de secretos.
5. Auditar el contenido invisible. Escanear cuerpos de issues y descripciones de PR en busca de comentarios HTML antes de que lleguen al contexto del agente. La normalización equivalente al renderizado debe ser un paso previo, no un detalle posterior.
6. Rotar las credenciales expuestas. Cualquier repositorio que haya ejecutado estas acciones sobre entradas de colaboradores no confiables antes del 15 de abril debe considerar los secretos asociados como comprometidos.

Estado

Componente	Respuesta del proveedor	Fecha	Notas
Claude Code Security Review	Bounty 100 USD; ps bloqueado; documentación actualizada; severidad Crítica (9.4) → None	2025-11-25 → 2026-04-20	«No diseñada para resistir la inyección de prompt»
Gemini CLI Action	Bounty 1 337 USD vía Google VRP	2026-01-20	Sin CVE emitido
GitHub Copilot Agent	Bounty 500 USD tras reapertura del reporte	2026-03-09	«Limitación arquitectónica conocida»
Divulgación pública	Blog de Aonan Guan	2026-04-15	Actualización con cronología 2026-05-04

La lección de fondo es la que cierra Guan: la inyección de prompt es, estructuralmente, phishing para máquinas. Los agentes IA deben procesar contexto no confiable para producir trabajo útil. Las superficies de inyección se multiplicarán a medida que se desplieguen nuevos agentes en cada workflow. Las arquitecturas que mantengan herramientas, secretos y entrada no confiable en un mismo runtime seguirán perdiendo frente a ataques de la clase Comment and Control — bajo el nombre que adopten a continuación.