Plugin4Shell: Cuatro agentes de codificación con IA confiaron en un PIN que nunca verificaron

El 17 de septiembre de 2026, AIR Security, una startup que crea herramientas de seguridad para agentes de IA empresariales, publicó una investigación que describe Plugin4Shell — una vulnerabilidad de ejecución remota de código sin clic en cuatro agentes de programación con IA: Claude Code de Anthropic, Codex de OpenAI, GitHub Copilot y Gemini CLI de Google. El error no está en ningún modelo. Reside en la operación de checkout de git que cada agente realiza al instalar un plugin, y en el hecho de que ninguno de los cuatro verificó que el código que recibía fuera el código que había fijado. Dos de los cuatro tenían un parche cuando la investigación se hizo pública. Dos no. Este incidente es una entrada en el Orca AI Incident Archive, que lo registra como una vulnerabilidad de cadena de suministro de gravedad alta sin explotación notificada.

Lo que los agentes realmente hicieron mal

Cada agente afectado instala plugins desde un marketplace, y cada marketplace fija un plugin a un commit de git específico —un SHA de 40 caracteres— una vez que el plugin ha sido revisado. Esa fijación es todo el modelo de seguridad: un revisor aprueba una versión inmutable, y se supone que el agente sigue ejecutando esa versión incluso si el repositorio subyacente cambia después. AIR describe la falla como una omisión de la fijación por SHA de plugins. El agente hace checkout del commit exacto que fijó el marketplace, pero nunca verifica que el árbol de trabajo con el que termina sea ese commit. En palabras de los investigadores, el agente "hace checkout del commit exacto que fijó el marketplace pero nunca verifica que haya llegado allí, así que un atacante que controle el repositorio del plugin hace que el checkout resuelva a código malicioso mientras la fijación todavía parece respetarse".

Git cubre ese hueco. Cuando un nombre es a la vez una rama válida y un objeto de commit, Git prefiere la rama y solo muestra una advertencia de ambigüedad. Un atacante que controla el repositorio del plugin crea una rama cuyo nombre es exactamente el SHA fijado de 40 caracteres hexadecimales, la apunta a código malicioso y la convierte en la rama predeterminada del repositorio. Un clonado normal entonces trae esa rama al entorno local bajo el nombre con forma de SHA, y el checkout posterior se resuelve a ella. El commit fijado en sí puede permanecer intacto, así que nada en la versión revisada parece incorrecto. Según AIR, deben cumplirse dos condiciones: la rama con nombre de SHA debe ser la rama predeterminada, porque una rama no predeterminada solo se obtiene como una referencia de seguimiento remoto y el checkout recurriría al commit real; y el host de Git debe aceptar un nombre de rama de 40 caracteres hexadecimales. GitHub rechaza esos nombres de plano. Bitbucket y los servidores Git autoalojados no.

Gemini CLI falló por una vía distinta. Obtuvo el commit fijado, lo registró en el archivo FETCH_HEAD del repositorio y luego ejecutó un checkout de FETCH_HEAD, un checkout que no tiene por qué leer ese archivo. Un repositorio cuya rama predeterminada se llama a sí misma FETCH_HEAD redirige el checkout hacia contenido controlado por el atacante y descarta silenciosamente el commit que se había obtenido. El relato de Cybersecurity News sobre el mecanismo coincide con el de AIR, incluida la distinción entre las dos variantes.

¿Por qué nadie tuvo que hacer clic en nada?

La misma operación de checkout se ejecuta de nuevo durante la actualización automática de plugins en segundo plano, que es la opción predeterminada en Claude Code y Codex. Eso es lo que hace que el ataque sea de cero clics en lugar de simplemente silencioso: cuando un marketplace cambia un SHA fijado a una nueva versión rutinaria, todos los agentes que ya tienen el plugin instalado vuelven a ejecutar el checkout sin solicitud de confirmación y sin acción del usuario. El punto de AIR es que la víctima no tiene que instalar nada con descuido. Solo tiene que haber instalado un plugin, de un marketplace en el que confía, que fue revisado y fijado exactamente como pretende el diseño.

Hay dos maneras de alcanzar esa posición, y ninguna requiere controlar el marketplace. En la primera, un atacante publica un plugin genuinamente benigno que pasa la revisión, forma una base de instalaciones, distribuye una actualización normal y solo entonces crea la rama con nombre malicioso. En la segunda, el atacante se hace con el control del repositorio que hay detrás de un plugin escrito por otra persona y en el que el marketplace ya confía, y luego distribuye la versión maliciosa a todos los que lo tienen instalado.

Las cifras detrás de esas dos rutas provienen del trabajo anterior de AIR, no de Plugin4Shell. En una campaña que la empresa llama The Story of Skills, afirma que un plugin que desarrolló se propagó a más de 26.000 agentes antes de ser retirado. En SkillJacking, informó que 925 habilidades que ya estaban en uso activo habían sido tomadas de sus mantenedores originales, alcanzando a 134.000 agentes. El titular de AIR para la publicación sobre Plugin4Shell afirma que "millones de agentes afectados"; la investigación no ofrece un recuento de instalaciones expuestas, y ningún tercero ha publicado uno.

La cronología y dónde se aplicaron las correcciones

AIR dice que encontró la falla en mayo de 2026 con exploits funcionales de prueba de concepto contra los cuatro agentes, y la divulgó a cada proveedor el mes siguiente bajo divulgación coordinada. Anthropic confirmó su corrección en Claude Code 2.1.179 el 17 de junio. Google le dijo a AIR el 4 de agosto que no se lanzaría ninguna corrección, porque Gemini CLI se está retirando. Se verificó que Codex 0.146.0 estaba corregido el 12 de agosto. Microsoft no ha lanzado una corrección para GitHub Copilot.

Las versiones parcheadas son la única confirmación pública de que la falla era real en los dos productos que la corrigieron. La entrada del registro de cambios publicada por Anthropic para 2.1.179 enumera la gestión de caídas de conexión, el desplazamiento en WSL2, correcciones de glob del sandbox y de la interfaz, y no menciona la fijación (pinning), la verificación de plugins ni ningún tipo de corrección de seguridad. The Hacker News hizo la misma observación, según el relato de The Next Web. En el momento de la publicación de la investigación, no se había asignado ningún identificador CVE, y la nota de investigación de Cloud Security Alliance sobre la falla repite que no existía ningún identificador tres meses después de que se notificara a los proveedores.

Cuatro proveedores, tres respuestas diferentes.

Google fue más allá de negarse a aplicar un parche. Marcó como obsoleto Gemini CLI, lo que significa que las instalaciones existentes permanecen expuestas mientras la gente siga ejecutándolas. Su recomendación es migrar a Antigravity, el entorno de desarrollo agéntico más reciente, al que, según AIR, el ataque no alcanza porque no tiene una fijación de SHA de complementos del marketplace que eludir.

La postura de GitHub es distinta una vez más. Un portavoz de GitHub dijo a The Register que la plataforma no permite a los usuarios crear nombres de ramas o etiquetas que se parezcan a SHA de commit, y que "esta mitigación garantiza que la vulnerabilidad reportada no pueda explotarse en GitHub". AIR discute el alcance de esa mitigación, no su existencia: los marketplaces pueden alojarse en otras plataformas como Bitbucket, dijeron los investigadores a The Register, y GitHub Copilot sigue admitiendo marketplaces de esas plataformas, por lo que la variante del nombre de rama sigue siendo accesible para los usuarios de Copilot. AIR también afirma que la propia documentación de Anthropic enumera Bitbucket y git autoalojado como backends válidos para marketplaces; la documentación actual sobre marketplaces de Anthropic describe cómo añadir un marketplace desde una URL de repositorio git, no solo desde GitHub. Microsoft no respondió a la solicitud de comentarios de The Register, y AIR dijo que no había recibido respuesta de Microsoft desde que notificó el problema en junio, y citó el volumen de divulgaciones que la empresa está gestionando.

Esta es una discrepancia sobre la amplitud de la exposición, no sobre si el fallo existe. La mitigación de GitHub es una restricción a nivel de host; el hallazgo de AIR es que la comprobación debe realizarse dentro del agente, porque el pin se resuelve en el cliente.

Qué está establecido y qué no

• Establecido: el mecanismo. El informe de AIR ofrece los comandos git exactos, la regla de resolución que prioriza la ref sobre el objeto, las dos condiciones que necesita el truco de la rama y la variante separada de FETCH_HEAD para Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld y The Next Web lo informan de la misma manera.

• Establecido: dos versiones parcheadas. Anthropic confirmó Claude Code 2.1.179 el 17 de junio de 2026 y se verificó que Codex 0.146.0 de OpenAI estaba corregido el 12 de agosto de 2026, según la cronología de divulgación de AIR.

• Confirmado: dos productos no tenían parche en el momento de la divulgación. Google no parcheará Gemini CLI y lo está retirando; Microsoft no ha publicado ninguna corrección para Copilot.

• No establecido: reproducción independiente. Todos los relatos publicados se remontan a la propia entrada del blog de AIR, y la nota de investigación de Cloud Security Alliance no describe explícitamente una validación técnica por parte de terceros ni una reproducción independiente del exploit. Por esa razón, el archivo califica la confianza de este registro con una B.

• No determinado: cuántas instalaciones estuvieron realmente expuestas. «Millones» es la caracterización de AIR en su titular, no una cifra medida.

• No se ha determinado: si actualizar un agente afectado elimina un complemento que ya se ha sustituido, o solo impide la siguiente sustitución. Ninguna fuente publicada lo resuelve.

• No establecido: ningún uso en el mundo real. Ninguna fuente en el registro informa de explotación, sondeo o infraestructura de atacantes, y el archivo registra el daño real como falso. Eso es una ausencia de informes, no evidencia de que no haya ocurrido nada.

Una comprobación de terceros sí acota el panorama práctico. The Next Web, al resumir las comprobaciones de The Hacker News, informa de que los plugins del catálogo comunitario de Anthropic y de los catálogos predeterminados de Claude Code y Copilot apuntan a repositorios de GitHub, y de que la actualización automática está activada de forma predeterminada principalmente en esos marketplaces integrados. Dado que GitHub rechaza los nombres de rama con forma de SHA, la variante del nombre de rama resulta más difícil de alcanzar para los usuarios que se mantienen en los catálogos predeterminados. Ese razonamiento no cubre la variante FETCH_HEAD de Gemini CLI, que no depende de cómo el host nombre las ramas.

Cómo tiene que ser una solución

La corrección recomendada por AIR es una única aserción: tras el checkout, resolver el commit que realmente está presente en el árbol de trabajo y abortar a menos que sea igual al SHA fijado. Los investigadores insisten en que debe comprobar el HEAD resuelto en lugar de la referencia que se solicitó, porque esa distinción es exactamente lo que se cuela en la variante de Gemini CLI, y en que debe ejecutarse dentro del agente, porque la fijación se resuelve en el cliente y ningún marketplace puede hacer cumplir la garantía que anuncia.

Consejos prácticos para los equipos que ejecutan estos agentes, extraídos de AIR, Cybersecurity News y los comentarios de analistas de InfoWorld:

• Actualiza Claude Code a 2.1.179 o posterior y Codex a 0.146.0 o posterior. Actualizar es la única mitigación completa cuando existe un parche.

• Desactive las actualizaciones automáticas de plugins en cualquier agente que no tenga parche. Eso reduce la vulnerabilidad de cero clics a una reinstalación manual, lo que supone una reducción de la exposición en lugar de una corrección.

• Migrar desde Gemini CLI en lugar de esperar un parche que Google ha dicho que no llegará.

• Audita el inventario de plugins y restringe las fuentes de marketplace cuando sea posible. AIR señala que un marketplace puede mitigar la variante de nombre de rama al permitir solo hosts que rechazan nombres con forma de SHA, en la práctica solo GitHub, pero que eso prohíbe hosts que los agentes admiten oficialmente y no hace nada para la variante de Gemini.

• Trate la estación de trabajo como el límite de exposición. Los plugins heredan los permisos del agente, por lo que un exploit exitoso llega al código fuente, las claves SSH, las credenciales de la nube, los tokens de CI/CD y los repositorios internos con la propia autoridad del desarrollador. Pareekh Jain, analista principal de Pareekh Consulting, declaró a InfoWorld que los equipos de seguridad deberían revisar EDR, git, CI/CD, cloud IAM y los registros de autenticación en busca de procesos inusuales, archivos de plugins inesperados, repositorios modificados y actividad sospechosa en git — y añadió que estas medidas reducen el riesgo sin corregir la falla subyacente, que atribuye al código del proveedor. "Las empresas pueden establecer controles en torno al uso de plugins", dijo a InfoWorld, "pero no pueden corregir una falla en la forma en que el agente de codificación valida el código que extrae."

Por qué un error de fijación fue el que importó

El pinning de SHA fue la respuesta de la industria precisamente al tipo de toma de control que AIR ya había demostrado: si un repositorio público se ve comprometido, el agente sigue ejecutando el hash auditado en lugar de descargar lo que sea que el atacante haya subido. Plugin4Shell no rompe el hash. Muestra que los agentes resolvieron el pin a un nombre de rama que simplemente parecía el hash, y nunca compararon el resultado. Todo lo que está aguas abajo de esa suposición —los procesos de revisión, las listas de permitidos internas, la confianza que los desarrolladores depositan en una versión fijada— hereda el fallo.

Lo que el registro no respalda es la afirmación de que se haya tomado algo. Se trata de una vulnerabilidad que se encontró y, en dos de cuatro casos, se corrigió; ninguna fuente en él reporta una intrusión, y los productos que no publicaron un parche siguen esperando. La pregunta abierta es la menos satisfactoria: para cualquiera que haya ejecutado un plugin en un agente sin parchear, no hay una forma publicada de saber si el código que se ejecutó era el código que aprobaron.