La vulnerabilidad de agente de IA Plugin4Shell eludió plugins de confianza y dejó sin parchear dos herramientas de programación

Plugin4Shell comprometió una protección fundamental en cuatro agentes de programación con IA, pese a que los usuarios siguieron el proceso previsto para instalar plugins revisados. La empresa de seguridad AIR afirma que la falla afectó a Claude Code, OpenAI Codex, GitHub Copilot y Gemini CLI. Sus investigadores demostraron ejecución remota de código funcional contra los cuatro productos.

Anthropic y OpenAI publicaron correcciones tras recibir la divulgación de AIR. AIR informó que no existía un parche correspondiente para GitHub Copilot cuando publicó sus hallazgos el 17 de septiembre de 2026. También señaló que Google no corregiría el comportamiento afectado de Gemini CLI y dirigió a los usuarios hacia Antigravity.

Esa respuesta desigual es el problema central. Los mercados de plugins prometen que la revisión y el anclaje a commits protegen a los desarrolladores frente a cambios de código posteriores a la aprobación. Según se informa, la vulnerabilidad de agente de IA Plugin4Shell rompió esa promesa sin requerir una instalación descuidada, una aprobación sospechosa ni un nuevo clic.

Plugin4Shell convirtió una actualización de confianza en ejecución remota de código

El ataque se dirigió al proceso de distribución de plugins, no al modelo de lenguaje que decide cómo responder a un prompt.

Los agentes de programación con IA admiten cada vez más plugins, skills, extensiones y otros complementos. Estos paquetes pueden personalizar flujos de trabajo, conectar servicios o ejecutar código dentro de entornos de desarrollo. A menudo heredan la capacidad del agente para acceder a archivos, ejecutar comandos de shell e interactuar con sistemas autenticados.

Ese acceso hace que un plugin de agente se parezca más a una aplicación local que a un prompt de texto pasivo. Si código malicioso llega al directorio de plugins, puede operar con los permisos concedidos al desarrollador que ejecuta el agente.

AIR afirma que Plugin4Shell llegó a ese punto al eludir el anclaje SHA. Un SHA es un identificador criptográfico que se utiliza habitualmente para nombrar un commit específico de Git. Anclar un plugin a ese identificador debería mantener fijo su código instalado, incluso si su repositorio cambia después.

Según la investigación sobre Plugin4Shell, los agentes afectados solicitaban un commit anclado, pero no verificaban el commit que realmente se extraía. Un atacante que controlara el repositorio upstream podría explotar el comportamiento de resolución de nombres de Git y sustituirlo por código diferente.

El registro del marketplace podía seguir mostrando el identificador de commit esperado. El agente también podía informar de una instalación correcta. Sin embargo, los archivos del directorio de trabajo procederían de una rama controlada por el atacante, en lugar del commit revisado.

AIR describió dos vías prácticas de entrada. Un atacante podía publicar un plugin legítimo, conseguir adopción y volver malicioso el repositorio durante una actualización posterior. Como alternativa, podía tomar control del repositorio que respalda un plugin existente.

La segunda vía importa porque traslada la responsabilidad desde los autores individuales de plugins. Un plugin puede comenzar como un proyecto legítimo y superar todas las revisiones. Su repositorio puede volverse hostil solo después de que desarrolladores y equipos de seguridad hayan confiado en él.

AIR afirma que los investigadores detectaron el problema en mayo de 2026 y lo comunicaron a los cuatro proveedores en junio. La empresa publicó su análisis técnico el 17 de septiembre. Help Net Security informó sobre los hallazgos al día siguiente.

Ninguna evidencia pública citada por ambas organizaciones mostraba que Plugin4Shell hubiera sido explotado contra víctimas reales antes de la divulgación. El impacto demostrado procede de las pruebas de concepto de AIR, no de una campaña criminal documentada.

Esa distinción limita lo que puede afirmarse sobre una compromisión inmediata. No reduce la importancia del control roto. Un ataque exitoso ejecutaría código a través de un componente que las organizaciones ya habían revisado y aprobado.

El problema también sigue investigaciones previas de AIR sobre la distribución de plugins. La empresa afirma que una skill de prueba llegó a más de 26.000 agentes antes de ser eliminada. Una investigación independiente habría identificado 925 skills secuestradas que afectaban a 134.000 agentes.

Esas cifras proceden de AIR y no se han reproducido de forma independiente en la divulgación de Plugin4Shell. Ilustran el argumento más amplio de los investigadores: conseguir distribución y comprometer repositorios upstream son etapas realistas, no meros requisitos teóricos.

Cómo la vulnerabilidad de agente de IA Plugin4Shell eludió el anclaje SHA

Plugin4Shell funcionó porque cada agente afectado confiaba en la referencia de Git solicitada en vez de verificar el commit final extraído.

Claude Code, Codex y GitHub Copilot compartían, según se informa, una variante. Sus instaladores de plugins clonaban un repositorio y pasaban el identificador de commit anclado de 40 caracteres a git checkout.

Git permite nombres de ramas que se parecen a identificadores de commits en muchas configuraciones de alojamiento. Cuando un nombre puede identificar tanto una rama como un objeto, Git puede resolverlo como una referencia mientras muestra una advertencia de ambigüedad.

Un atacante que controlara el repositorio del plugin podría crear una rama con exactamente el mismo nombre que el commit anclado. Después, convertiría esa rama en la predeterminada del repositorio y la dirigiría hacia código malicioso.

La clonación inicial descargaría la rama predeterminada del atacante. La comprobación posterior podría resolver el aparente identificador de commit hacia esa rama local. El agente cargaría o ejecutaría entonces archivos distintos de los revisados por el marketplace.

Esta técnica no funciona de manera idéntica en todos los servicios de alojamiento. GitHub bloquea los nombres de ramas y etiquetas que parecen identificadores completos de objetos de Git, según sus restricciones de nombres de ramas.

Sin embargo, AIR afirma que Bitbucket y los servicios Git autoalojados pueden aceptar esos nombres. Algunos marketplaces de agentes admiten oficialmente repositorios alojados fuera de GitHub, lo que deja expuesta una configuración más amplia.

Gemini CLI utilizaba, según se informa, una ruta distinta hacia el mismo resultado. Su instalador obtenía el commit anclado y luego ejecutaba una comprobación contra FETCH_HEAD, una referencia de Git que normalmente apunta al contenido obtenido.

AIR descubrió que un repositorio podía utilizar FETCH_HEAD como nombre de su rama predeterminada. La comprobación podía resolver entonces esa rama en lugar del archivo especial que contiene el commit obtenido.

Ambas variantes dependían de que faltara una comparación final. Tras completar la comprobación, el agente debía resolver HEAD y verificar que coincidía con el SHA anclado del marketplace.

La comprobación es pequeña, pero su ubicación importa. Un marketplace no puede confirmar qué colocó finalmente un cliente en su árbol de trabajo local. La verificación debe producirse dentro del agente que realiza la clonación y la comprobación.

La etiqueta de cero clics procede de las actualizaciones en segundo plano. AIR afirma que Claude Code y Codex actualizan automáticamente los plugins instalados de forma predeterminada. Por tanto, un reemplazo malicioso podría llegar después de que un marketplace cambiara su anclaje, sin otra decisión de instalación.

La víctima no necesitaría encontrar un nuevo plugin malicioso. El atacante se dirigiría a uno que ya estuviera presente en la máquina y esperaría al proceso de actualización del agente.

La ejecución remota de código, o RCE, significa que instrucciones controladas por un atacante se ejecutan en el sistema objetivo. El alcance resultante depende de la cuenta, el entorno, el sandbox, las credenciales y el acceso de red disponibles para el agente afectado.

AIR describe el impacto potencial como equivalente al acceso del empleado que ejecuta la herramienta. Se trata de una descripción del peor caso, no de una medición universal para todas las instalaciones.

Un agente estrictamente aislado podría exponer solo un espacio de trabajo temporal. Un agente instalado localmente con credenciales de nube, repositorios de código fuente, claves de firma o acceso a producción genera un radio de impacto potencial mucho mayor.

Esta variabilidad explica por qué el inventario de versiones por sí solo es insuficiente. Los equipos de seguridad también necesitan saber dónde se ejecuta cada agente, qué plugins carga y qué credenciales están disponibles dentro de ese límite de ejecución.

La revisión de plugins funcionó según lo previsto, pero el código instalado aun así cambió

El conflicto central se da entre la promesa de una revisión inmutable y la realidad de la resolución de Git en el cliente.

Los controles de la cadena de suministro de software suelen separar la aprobación de la ejecución. Un revisor evalúa una versión conocida, registra su resumen criptográfico y permite que los sistemas instalen solo esa versión.

Ese modelo presupone que el resumen identifica los archivos que se ejecutarán. Según se informa, Plugin4Shell preservó el anclaje visible mientras rompía la conexión entre ese anclaje y el árbol de trabajo final.

Esto es más grave que advertir a los usuarios sobre extensiones desconocidas. Los investigadores afirman que el ataque sigue funcionando cuando un plugin procede de un marketplace de confianza, supera la revisión y permanece anclado.

Por lo tanto, una guía de seguridad basada únicamente en la reputación del marketplace no detectaría el paso vulnerable. El atacante no necesita comprometer la base de datos del marketplace si puede engañar al agente local durante la comprobación.

La misma limitación se aplica a los catálogos internos de plugins. Una empresa podría revisar cada paquete y replicar los metadatos aprobados. Esos controles siguen siendo incompletos si los clientes de los empleados no validan el commit resuelto.

AIR califica Plugin4Shell como la primera vulnerabilidad de cadena de suministro del ecosistema de agentes de IA. Esa formulación es la caracterización de la empresa y merece cierta cautela.

Las herramientas de desarrollo con IA ya han enfrentado envenenamiento de repositorios, inyección de prompts, archivos de configuración maliciosos y vulnerabilidades relacionadas con extensiones. Plugin4Shell es más limitada en un sentido, porque se centra en complementos de agentes anclados y su ruta de actualización.

Aun así, el mecanismo expone un fallo de confianza distinto. Ataca la forma en que la funcionalidad de agentes revisada viaja desde un repositorio hasta la máquina de un desarrollador.

Investigaciones recientes muestran que este no es un punto de presión aislado. Wiz divulgó GhostApproval en julio de 2026 tras probar seis asistentes de programación con IA. Ese problema utilizaba enlaces simbólicos para alcanzar archivos fuera de los límites esperados del espacio de trabajo.

Los hallazgos de GhostApproval afectaron a productos de Amazon, Anthropic, Augment, Cursor, Google y Windsurf. Las respuestas de los proveedores variaron, con varias correcciones y al menos una decisión controvertida sobre el modelo de amenazas.

GhostApproval y Plugin4Shell utilizan primitivas técnicas diferentes. Uno explota la resolución de rutas mediante enlaces simbólicos. El otro explota, según se informa, la resolución de referencias de Git durante la instalación y las actualizaciones de plugins.

El patrón que los conecta es una brecha entre la decisión visible del usuario y la acción real del sistema. Una ruta parece local, pero se resuelve en otro lugar. Un anclaje parece inmutable, pero se resuelve en código diferente.

Los avisos de permisos por sí solos no pueden reparar ese desajuste. Los usuarios no pueden tomar decisiones informadas cuando la interfaz muestra el nombre de confianza mientras la operación subyacente se dirige a otra cosa.

Anthropic ha descrito públicamente el aislamiento del sistema de archivos y de red como protecciones complementarias para Claude Code. Su modelo de sandboxing busca impedir que un proceso inyectado alcance archivos sensibles o destinos de red no autorizados.

El sandboxing puede reducir el impacto del código malicioso de un plugin. No sustituye una verificación precisa de paquetes, especialmente cuando los plugins se ejecutan fuera de las mismas restricciones o reciben permisos más amplios.

Por ello, las empresas necesitan dos límites independientes. El proceso de instalación debe verificar que el código revisado realmente se instala. El entorno de ejecución debe limitar a qué puede acceder ese código después de ejecutarse.

Un fallo en cualquiera de las dos capas no debería convertirse automáticamente en la vulneración de una estación de trabajo o una cuenta en la nube. Plugin4Shell importa porque muchos despliegues de agentes todavía combinan extensiones modificables con credenciales locales valiosas.

Cuatro agentes de programación produjeron cuatro resultados de seguridad distintos

La divulgación expuso un proceso de parcheo fragmentado entre herramientas que implementan flujos de trabajo de plugins similares.

AIR afirma que Anthropic corrigió la vulnerabilidad de Claude Code en la versión 2.1.179. La empresa registró el 17 de junio de 2026 como la fecha en que Anthropic confirmó la corrección.

OpenAI corrigió el comportamiento afectado de Codex en la versión 0.146.0, según AIR. La cronología de la investigación indica que la empresa verificó esa versión como corregida el 12 de agosto.

Los usuarios de esos productos no deberían asumir que las actualizaciones automáticas se completaron correctamente. Las estaciones de trabajo administradas, los entornos sin conexión, los bloqueos de paquetes y los sistemas internos de distribución pueden dejar instaladas versiones antiguas.

Las organizaciones deberían consultar los endpoints reales y comparar sus versiones con las versiones corregidas. También deberían reiniciar las sesiones de larga duración si su proceso de despliegue no reemplaza los procesos de agente activos.

GitHub Copilot presenta un problema diferente. AIR indicó que Microsoft recibió el mismo informe de vulnerabilidad, pero no había publicado una corrección cuando la investigación se hizo pública.

GitHub había ampliado recientemente los controles centralizados para las operaciones de agentes. Su anuncio del 9 de septiembre indicó que los administradores podían bloquear, permitir o exigir aprobación para comandos de shell, operaciones de archivos y dominios de red mediante permisos administrados de agentes.

Estos controles pueden limitar las consecuencias, pero no constituyen evidencia de un parche para Plugin4Shell. Un instalador sin parchear y una política de ejecución restrictiva abordan etapas distintas del ataque.

Por lo tanto, los administradores de Copilot deberían buscar un aviso específico del producto, una versión corregida o una confirmación del proveedor. Hasta entonces, las organizaciones pueden suspender las actualizaciones de plugins del marketplace o limitar los agentes a repositorios aprobados bajo su control.

Gemini CLI tiene el estado más complejo. AIR afirma que Google confirmó el 4 de agosto que no corregiría el flujo de trabajo afectado y aconsejó migrar a Antigravity.

Google ya había comenzado a trasladar a usuarios individuales de Gemini CLI a Antigravity CLI. Un anuncio de junio indicó que Gemini CLI dejó de atender solicitudes de cuentas individuales, mientras que el uso empresarial y mediante claves de API seguía disponible.

Sin embargo, el anterior aviso de transición de Google también indicó que el proyecto de código abierto Gemini CLI seguiría recibiendo actualizaciones de modelos, correcciones de errores y correcciones de seguridad para clientes empresariales.

Ese lenguaje público no encaja claramente con la afirmación de que todas las instalaciones de Gemini CLI permanecerán vulnerables indefinidamente. Deja una importante brecha de verificación para los administradores.

El registro de cambios de Google de septiembre muestra que las versiones de Gemini CLI continuaron después de la transición de consumidores. También enumera endurecimientos de seguridad no relacionados con el fallo preciso de checkout. Esa actividad no establece una corrección para Plugin4Shell.

La conclusión cautelosa es más limitada. AIR informó que no había un parche para Plugin4Shell en Gemini CLI en el momento de la divulgación y recomendó Antigravity. Google siguió manteniendo partes de Gemini CLI para uso empresarial, pero ninguna nota de versión citada identifica esta corrección específica.

Los usuarios empresariales no deberían inferir seguridad a partir de un lenguaje general de mantenimiento. Necesitan confirmación directa de que su versión verifica el commit final extraído tras instalar o actualizar una extensión.

Tampoco deberían tratar la migración como un simple cambio de nombre. Trasladar skills, hooks, servidores MCP y credenciales a un nuevo agente puede reproducir otros riesgos si las configuraciones se transfieren sin revisión.

AIR afirma que Antigravity no utiliza el mecanismo de fijación de SHA de plugins explotado por Plugin4Shell. Esto significa que esta ruta específica no se aplica, según el análisis de los investigadores.

No significa que Antigravity sea inmune a plugins maliciosos, inyección de prompts, herramientas inseguras o futuros fallos en la cadena de suministro. Los equipos de seguridad deberían mantener los mismos requisitos de aislamiento y mínimo privilegio tras la migración.

Las cuatro respuestas revelan un problema de gobernanza que va más allá de este error. Funciones similares pueden distribuirse entre varios agentes sin convenciones compartidas de divulgación, puntuación común de gravedad ni remediación sincronizada.

Los desarrolladores deben seguir registros de cambios y declaraciones de proveedores independientes. Después, los administradores empresariales deben traducir esos registros desiguales en una única postura de seguridad exigible.

Qué deberían cambiar de inmediato los equipos de desarrollo

La primera prioridad es detener las actualizaciones de plugins vulnerables, verificar las versiones de los agentes y reducir las credenciales disponibles para cada agente de programación.

Para Claude Code, las organizaciones deberían trasladar todas las instalaciones a la versión 2.1.179 o posterior. Para Codex, AIR identifica la versión 0.146.0 como la versión corregida.

Los equipos deberían verificar las versiones mediante un inventario de endpoints, no mediante encuestas. Los desarrolladores pueden usar varios agentes de programación en terminales locales, extensiones de IDE, espacios de trabajo remotos y sistemas de CI.

Para GitHub Copilot, los administradores deberían solicitar orientación explícita de remediación a GitHub o Microsoft. No deberían tratar mejoras de permisos no relacionadas como confirmación de que se ha corregido la vulnerabilidad de checkout.

Cuando la funcionalidad de plugins no sea esencial, deshabilitar paquetes de terceros del marketplace ofrece la reducción temporal más clara. Las organizaciones que no puedan deshabilitarlos deberían pausar las actualizaciones automáticas y restringir las fuentes de repositorios.

Los usuarios de Gemini CLI deberían evaluar la migración a Antigravity, especialmente al usar extensiones del marketplace. Los clientes empresariales también deberían solicitar confirmación por escrito sobre el estado de su versión exacta de Gemini CLI.

Eliminar un plugin afectado después de la divulgación es útil, pero incompleto. Un paquete comprometido podría haber creado persistencia, modificado archivos de inicio, copiado credenciales o alterado repositorios antes de su eliminación.

Los equipos de respuesta a incidentes deberían revisar el historial de actualizaciones de plugins, la actividad de Git, la ejecución de procesos, las conexiones de red y los cambios en archivos sensibles. La ventana temporal relevante comienza antes de la divulgación pública si estaban activas actualizaciones automáticas vulnerables.

Los equipos deberían rotar credenciales cuando la telemetría indique que se ejecutó código de plugin inesperado. Los objetivos prioritarios incluyen tokens de control de código fuente, credenciales en la nube, claves de publicación de paquetes, material de firma y secretos almacenados en entornos de shell.

El alcance de las credenciales importa tanto como su rotación. Un agente de programación con IA no debería heredar acceso ilimitado a producción simplemente porque el desarrollador que lo ejecuta posee esos permisos.

Las identidades separadas para agentes facilitan contener y auditar acciones anómalas. Los tokens de corta duración también limitan el valor de las credenciales recopiladas desde una estación de trabajo.

El aislamiento en tiempo de ejecución proporciona otra capa. El acceso a archivos debería limitarse por defecto al proyecto activo, mientras que el acceso a red debería utilizar una lista de permitidos ajustada a la tarea.

La ejecución de shell requiere límites similares. Un plugin que puede invocar cualquier comando bajo una cuenta de desarrollador puede eludir muchos controles aplicados solo al código fuente generado.

Las organizaciones deberían comprobar si las reglas de sandbox cubren los subprocesos creados por plugins, hooks, gestores de paquetes y servidores MCP. Una restricción sobre las herramientas directas del modelo puede no cubrir todos los procesos de extensiones.

La gobernanza de plugins también necesita evidencias más sólidas. Un catálogo interno debería almacenar el commit revisado, el origen del repositorio, el identificador de árbol resuelto, el revisor, la fecha de aprobación y la versión desplegada.

El instalador debería validar el HEAD resuelto tras el checkout. Si no coincide con el commit aprobado, la instalación debe detenerse en lugar de mostrar una advertencia y continuar.

Los equipos de seguridad pueden probar este comportamiento sin reproducir una ejecución maliciosa. Un repositorio controlado puede presentar referencias ambiguas mientras el sistema de validación comprueba si la instalación falla de forma segura.

El resultado debería formar parte de las pruebas de adquisición y aceptación interna. Los proveedores deberían poder explicar cómo sus agentes verifican el contenido de los plugins después de clonar, obtener y actualizar.

Los equipos también necesitan un registro fiable de por qué existe cada plugin. Una base de conocimiento de ingeniería con capacidad de búsqueda puede conectar aprobaciones, responsables, incidentes y decisiones de reemplazo.

Esa documentación no evita la explotación. Reduce el tiempo necesario para identificar a los equipos afectados y eliminar integraciones riesgosas cuando aparece otra divulgación.

Por último, no debería culparse a los desarrolladores por confiar en una fijación anunciada. Según los informes, Plugin4Shell eludió un control diseñado para que esa confianza fuera razonable.

La acción correctiva corresponde al código de los proveedores, la política empresarial y la arquitectura de ejecución. Formar a los usuarios para que inspeccionen cada actualización no puede compensar que un instalador ejecute código distinto al resumen aprobado.

Tres señales mostrarán si la seguridad de los plugins de agentes está mejorando

La próxima prueba será si los proveedores convierten esta divulgación en controles de instalación verificables en lugar de promesas de seguridad más amplias.

La primera señal es una remediación específica para GitHub Copilot. Los administradores deberían buscar un aviso de seguridad, un identificador de versión o una declaración técnica que confirme la verificación del commit posterior al checkout.

Una actualización general de Copilot no responderá a la pregunta. La evidencia relevante es si el cliente resuelve el HEAD del árbol de trabajo y lo compara con la fijación del marketplace.

Si GitHub documenta ese comportamiento y lo distribuye en las interfaces compatibles de Copilot, la actual brecha de parcheo se reducirá. El silencio continuado reforzaría las preocupaciones sobre una gestión inconsistente de vulnerabilidades.

La segunda señal es la aclaración de Google para los usuarios empresariales de Gemini CLI. El lenguaje público de transición indica que el acceso empresarial y el mantenimiento de seguridad continúan, mientras AIR informa que no hay parche para Plugin4Shell.

Google puede resolver esa tensión nombrando las versiones afectadas, explicando si existe una corrección y definiendo fechas de soporte. Un aviso específico ayudaría a los equipos a decidir entre parchear y migrar.

Si Gemini CLI recibe comprobación verificada de commits, el estado comunicado por AIR en el momento de la divulgación quedará desactualizado. Si Google confirma que no lo hará, las organizaciones deberían tratar la migración como un requisito de seguridad y no como una preferencia de producto.

La tercera señal es la adopción, a nivel de marketplace, de un comportamiento de cliente verificable. Los marketplaces no pueden imponer por sí solos el checkout final, pero pueden exigir agentes compatibles y rechazar configuraciones de repositorios inseguras.

Los cambios útiles incluirían manifiestos firmados, artefactos de paquetes inmutables, certificaciones de procedencia y recibos de instalación que contengan el commit resuelto. Cada control debería seguir siendo verificable de forma independiente.

Los proveedores de agentes también deberían revelar si los plugins se ejecutan dentro del mismo sandbox que los comandos generados. Un paquete verificado aún puede verse comprometido aguas arriba antes de la revisión o contener una vulnerabilidad pasada por alto.

La lección más amplia no es que los plugins sean intrínsecamente inseguros. Es que los agentes autónomos convierten los errores de empaquetado en acciones realizadas con privilegios de desarrollador.

Según los informes, Plugin4Shell atravesó cuatro productos competidores porque sus implementaciones se basaban en la misma suposición no comprobada. El identificador Git solicitado se trataba como equivalente al código realmente instalado.

Los desarrolladores y responsables de seguridad deberían formular ahora una pregunta directa a cada proveedor de agentes de programación: ¿qué demuestra que el código revisado es el código que se ejecuta en la máquina?

Hasta que Copilot y Gemini CLI tengan respuestas específicas para cada producto, las organizaciones afectadas deberían limitar el uso de plugins, verificar cada versión de agente y aislar las credenciales. Los equipos que usen Claude Code o Codex corregidos deberían seguir auditando las extensiones instaladas y confirmar que las actualizaciones llegaron a todos los endpoints.

La vulnerabilidad del agente de IA Plugin4Shell es, en última instancia, una prueba de visibilidad operativa. ¿Puede su organización identificar cada agente, sus plugins, su versión y sus privilegios antes de que se ejecute la próxima actualización en segundo plano?