Investigadores descubrieron una vulnerabilidad de cero clics en herramientas como Codex, Claude Code y Copilot que explota cómo verifican plugins de terceros.
Investigadores de la startup de ciberseguridad AIR identificaron en mayo una vulnerabilidad de ejecución remota de código (RCE) de cero clics en agentes de codificación asistida por IA que afecta a OpenAI Codex, Anthropic Claude Code, Google Gemini CLI y GitHub Copilot. La falla, denominada Plugin4Shell, permite que un atacante ejecute código malicioso en el entorno de desarrollo sin que el desarrollador interactúe con el sistema, simplemente reemplazando un plugin confiable por una versión comprometida en el repositorio. Los investigadores divulgaron el hallazgo a los proveedores en junio. Anthropic lanzó un parche en Claude Code versión 2.1.179 y OpenAI en Codex versión 0.146.0, mientras que Google deprecó Gemini CLI y recomendó migrar a Antigravity en lugar de emitir una corrección.
Cómo la verificación de commits se convierte en vector de ataque
Los agentes de codificación IA utilizan plugins para extender sus capacidades, descargando código desde repositorios Git y verificando que ejecutan una versión aprobada mediante un identificador criptográfico único llamado SHA (secure hash algorithm), asignado a cada commit. El desarrollador proporciona al agente el SHA del commit revisado para indicarle que ejecute esa copia específica del plugin.
La vulnerabilidad surge porque Claude Code, Codex y GitHub Copilot pasan el SHA directamente a Git para descargar el código del plugin, pero no verifican posteriormente que Git haya descargado el commit correspondiente a ese SHA. Un atacante que controle el repositorio del plugin — ya sea porque publicó un plugin inicialmente benigno que luego convirtió en malicioso, o porque comprometió un repositorio existente — puede crear una nueva versión del repositorio con código malicioso y usar el SHA del commit legítimo como nombre de esa versión. Cuando el agente solicita a Git que descargue el SHA, Git resuelve la petición a la versión controlada por el atacante, ejecutando código malicioso aunque se le haya indicado usar el commit revisado.
En Gemini CLI el mecanismo difiere en implementación pero comparte el mismo problema de fondo. El agente usa el SHA para indicar a Git qué versión legítima del plugin recuperar, pero luego le pide que descargue ese código usando el nombre FETCH_HEAD. Un atacante puede crear una versión maliciosa del plugin con el mismo nombre FETCH_HEAD, generando una segunda versión que Git puede devolver cuando Gemini CLI solicite el código.
Por qué GitHub considera insuficiente restringir nombres de versiones
GitHub implementó restricciones en la creación de nombres de versiones o etiquetas que se asemejen a SHAs de commits, una medida que según un representante de la compañía previene que la vulnerabilidad reportada sea explotada en GitHub o en plugins de su marketplace. Sin embargo, investigadores de AIR indicaron que estas restricciones de nomenclatura podrían no ser suficientes para bloquear ataques Plugin4Shell, dado que los marketplaces de plugins también pueden alojarse en otras plataformas como Bitbucket. GitHub aún no ha lanzado un parche para Copilot según los investigadores de AIR.
Exposición en entornos corporativos donde los agentes tienen acceso privilegiado
Las empresas que ejecutan agentes de codificación IA afectados con plugins de terceros enfrentan exposición en sus entornos de desarrollo, especialmente cuando esos agentes tienen acceso a código fuente, credenciales, sistemas cloud o herramientas de integración continua y despliegue continuo (CI/CD). Los plugins maliciosos se ejecutan con el mismo nivel de acceso que tiene el desarrollador o empleado que los instaló. Esto significa que un atacante podría acceder a código fuente, robar claves API o credenciales cloud, modificar repositorios o alcanzar sistemas CI/CD y otras infraestructuras corporativas.
En América Latina, donde empresas de desarrollo de software en Argentina, Brasil, México y Colombia han adoptado agentes de codificación IA para acelerar ciclos de desarrollo, la dependencia de estas herramientas sin procesos de revisión de seguridad de plugins representa un punto de exposición estructural. Aunque no hay datos reportados sobre incidentes específicos en la región vinculados a Plugin4Shell, la práctica común de instalar plugins desde marketplaces públicos sin auditoría previa — combinada con entornos donde los desarrolladores tienen acceso directo a sistemas de producción — amplifica el riesgo de que un plugin comprometido se convierta en punto de entrada a infraestructura crítica.
Qué medidas reducen el riesgo sin resolver la falla de origen
Los equipos de seguridad pueden examinar máquinas que ejecutan estos agentes vulnerables buscando señales de advertencia como procesos o conexiones de red inusuales, archivos de plugins inesperados, repositorios de código modificados, actividad sospechosa en Git y uso anómalo de credenciales de desarrollador o cloud. Los logs de EDR (detección y respuesta en endpoints), Git, CI/CD, IAM de cloud y autenticación son puntos de investigación recomendados. Las empresas también deben verificar si sus agentes de codificación actualizan automáticamente para asegurar que han recibido los parches de los proveedores que los emitieron.
Estas medidas reducen el riesgo pero no corrigen la vulnerabilidad subyacente, que es responsabilidad del proveedor porque radica en cómo los agentes verifican el código que se les indica ejecutar. Las empresas pueden implementar controles sobre el uso de plugins, pero no pueden corregir una falla en la forma en que el agente de codificación valida el código que descarga.
Nuestro análisis
Plugin4Shell expone un patrón recurrente en herramientas de desarrollo asistidas por IA: la velocidad de adopción supera la madurez de los controles de seguridad en la cadena de suministro de código. La falla no reside en un error de implementación puntual sino en una suposición de diseño — que Git devolverá exactamente lo que se le pidió — que los cuatro proveedores afectados compartían. Que Google haya optado por deprecar Gemini CLI en lugar de parcharlo sugiere que la corrección requiere cambios arquitectónicos no triviales. La respuesta fragmentada de los proveedores — dos parches, una deprecación, una restricción de nombres sin parche — deja a las empresas en una posición donde la mitigación depende de qué herramienta usan y si actualizan manualmente.
Lo que aún no se sabe es cuántas empresas ejecutan versiones sin parchar de estos agentes en entornos de producción, y si algún atacante explotó Plugin4Shell entre mayo (cuando fue descubierto) y las fechas de los parches. La ausencia de telemetría pública sobre intentos de explotación no significa que no hayan ocurrido — solo que no hay visibilidad. ¿Qué pasaría si un marketplace de plugins popular fuera comprometido y distribuyera versiones maliciosas de herramientas ampliamente instaladas antes de que las empresas actualicen sus agentes?