Investigadores de seguridad secuestraron tres de los agentes de codificación de IA más usados en entornos empresariales. No explotaron una vulnerabilidad tradicional de software. No forzaron credenciales. Escribieron un título de pull request.
Eso es todo. Un título malicioso de PR. Claude Code, Gemini CLI Action de Google y GitHub Copilot de Microsoft, todos comprometidos, usados para exfiltrar claves API y tokens de acceso. Y aquí está lo que debería mantener a tu equipo de seguridad despierto: ninguno de los proveedores afectados emitió un CVE ni publicó un aviso público de seguridad.
Investigadores de la Universidad Johns Hopkins revelaron estos hallazgos esta semana y llaman al patrón de ataque "comment-and-control", un juego deliberado con command-and-control, porque toda la infraestructura del ataque reside dentro de GitHub. Sin servidores externos. Sin malware. Solo agentes de IA haciendo exactamente lo que fueron diseñados para hacer: leer datos de GitHub y actuar en consecuencia.
Cómo Funciona Realmente el Ataque
Agentes de codificación de IA como Claude Code Security Review y Gemini CLI Action siguen un flujo predecible. Leen contenido de GitHub, títulos de PR, cuerpos de issues, comentarios, tratan ese contenido como contexto confiable y luego ejecutan tareas basadas en lo que encuentran. Esa suposición de diseño es la vulnerabilidad.
El investigador Aonan Guan de Johns Hopkins se dio cuenta de que si podía inyectar instrucciones en los datos que la IA leía, podía redirigir lo que la IA hacía. Así que envió un pull request e incrustó instrucciones maliciosas directamente en el título del PR, diciéndole esencialmente a Claude que ejecutara comandos bash y devolviera la salida como un "hallazgo de seguridad".
Claude ejecutó los comandos. Luego publicó los resultados, incluidas credenciales del entorno, como comentario en el PR. Atacante escribe el título. Atacante lee el comentario de revisión del bot. Fin.
Para Gemini, los investigadores escalaron la inyección a través de cadenas de comentarios, engañando finalmente a Gemini para que publicara su propia clave API como comentario en un issue de GitHub. GitHub pagó 1.337 dólares por ese hallazgo, un guiño pícaro de la comunidad de seguridad.
El agente de GitHub Copilot fue más difícil. GitHub había añadido tres defensas a nivel de tiempo de ejecución: filtrado de entorno, escaneo de secretos y un firewall de red. Guan las evitó todas ocultando el prompt malicioso dentro de un comentario HTML, invisible para revisores humanos en el Markdown renderizado de GitHub, pero totalmente visible para la IA que procesa el contenido en bruto. La víctima asigna el issue a Copilot para que lo arregle. Copilot filtra los secretos. El atacante limpia sus huellas editando el título del issue y borrando la respuesta del bot.
El Problema de la Divulgación Silenciosa
Aquí es donde esto empeora para las empresas. Anthropic fue notificado inicialmente del fallo de Claude Code en octubre. Pagaron una recompensa de 100 dólares, la más baja de las tres, elevaron la gravedad a 9.4 (crítica) y añadieron una nota en su documentación diciendo que la acción "no está protegida contra ataques de inyección de prompts."
Sin CVE. Sin aviso público. Sin notificación a usuarios con versiones vulnerables.
Google pagó 1.337 dólares y acreditó al equipo de investigación. Aún sin CVE. Microsoft, tras decir inicialmente que era un "problema conocido" que "no pudieron reproducir", finalmente pagó 500 dólares en marzo. Sin divulgación pública.
Guan dijo a The Register: "Sé con certeza que algunos usuarios están anclados a una versión vulnerable. Si no publican un aviso, esos usuarios pueden nunca saber que son vulnerables o que están siendo atacados."
Esa frase describe perfectamente el estado actual de la seguridad de IA empresarial. Tu equipo despliega un agente de IA para ayudar en la revisión de código. Investigadores descubren que puede ser secuestrado para robar todos los secretos en tu entorno de GitHub Actions. El proveedor lo parchea silenciosamente. Nunca te enteras.
Esto No es un Caso Aislado
Lo que hace esto particularmente incómodo es que la superficie de ataque no es exótica. GitHub Actions es usado por cientos de miles de organizaciones. Agentes de codificación de IA, Claude Code, Copilot, integraciones Gemini, se están desplegando rápidamente en equipos de ingeniería en todas partes. La mayoría de las organizaciones no tienen visibilidad de qué herramientas de IA usan activamente sus desarrolladores en pipelines CI/CD, ni si esas herramientas están ejecutando versiones parcheadas.
Esto cae directamente en el territorio de la IA en la sombra. No la clase donde un empleado abre ChatGPT en una pestaña del navegador, sino donde agentes de IA están integrados en flujos de trabajo de desarrollo clave con acceso a secretos de producción y nadie en seguridad tiene un inventario completo de qué está corriendo dónde.
Y esta semana llegó una segunda historia relacionada: un fallo de diseño en el Modelo Context Protocol (MCP) de Anthropic, el estándar abierto que permite a modelos de IA conectarse a herramientas y fuentes de datos externas. El equipo de seguridad de Ox descubrió que el uso de STDIO como mecanismo de transporte local permite la ejecución arbitraria de comandos del sistema operativo, y el patrón de vulnerabilidad se extiende a todos los proyectos que usan el SDK oficial MCP de Anthropic, con 150 millones de descargas en Python, TypeScript, Java y Rust.
Anthropic se negó a parchear el protocolo en sí, calificando el comportamiento como "esperado". Desde entonces se han emitido diez CVEs de alta y crítica severidad para proyectos individuales dependientes de MCP. La causa raíz sigue sin solucionarse.
Qué Deben Hacer las Empresas Ahora
Algunos pasos prácticos para actuar esta semana:
Audita tus GitHub Actions para integraciones con agentes de IA. Cualquier flujo de trabajo que invoque Claude Code, Gemini CLI Action o GitHub Copilot debe ser revisado. Comprueba qué versión está fijada. Confirma si se ha actualizado desde finales de 2025.
Restringe el acceso externo a flujos de trabajo con agentes de IA. Los tres proveedores recomiendan requerir la aprobación de un mantenedor antes de que los agentes de IA procesen contribuciones externas. Esto no evitará ataques internos, pero cierra el vector de ataque externo más evidente.
Trata el contenido de PR e incidencias como entrada no confiable. Si un agente de IA en tu pipeline lee contenido proporcionado por usuarios y actúa sobre él, eso es una superficie de inyección de prompts. Las organizaciones apenas están comenzando a construir los modelos de seguridad necesarios para manejar esto correctamente.
Obtén visibilidad antes de gobernar. El problema más difícil es que la mayoría de los equipos de seguridad no tienen un inventario fiable de qué herramientas de IA están activamente en uso en su entorno, especialmente en los flujos de trabajo de desarrollo. No puedes parchear lo que no conoces, y no puedes aplicar políticas sobre agentes de IA que no has descubierto.
Este último punto es donde encaja el [Descubrimiento de IA en la Sombra](https://aona.ai/product) de Aona. Obtener una visión completa del uso de herramientas de IA en toda la empresa, incluidos agentes de IA integrados en herramientas de desarrollo, es el requisito previo para cualquier gobernanza significativa. El ataque descrito esta semana no requiere que un empleado tome un riesgo deliberado. Explota herramientas de IA que TI ya aprobó, ejecutándose en pipelines que TI controla, haciendo exactamente lo que fueron diseñadas para hacer.
El modelo de amenaza para la seguridad de IA empresarial se ha vuelto significativamente más complejo. La buena noticia es que el ataque está comprendido, las mitigaciones están documentadas y nada de esto requiere esperar a que los proveedores actúen. La pregunta es si tu equipo de seguridad tiene la visibilidad para saber por dónde empezar.
