Noticias de Tecnología 5-8 minutos

Plugin4Shell: el fallo zero-click que deja a los agentes de código ejecutando plugins que nadie aprobó

Diego Cortés
Diego Cortés
Full Stack Developer & SEO Specialist
Compartir:
Plugin4Shell: el fallo zero-click que deja a los agentes de código ejecutando plugins que nadie aprobó
Imagen generada con IA

Plugin4Shell es el fallo que dejaba a Claude Code, Codex, Copilot y Gemini CLI ejecutar el plugin de un tercero sin comprobar que el código descargado fuera el que estaba fijado. Bastaba con tener el plugin instalado: la actualización en segundo plano hacía el resto.

Qué es Plugin4Shell y por qué importa

La firma de seguridad AIR divulgó el 17 de septiembre de 2026 una vulnerabilidad de ejecución remota de código que afecta a los cuatro agentes de programación más usados. La describen como la primera vulnerabilidad de cadena de suministro del ecosistema de agentes de IA, y la etiqueta apunta a su origen: no está en los modelos ni en cómo responden, está en la manera en que el agente instala y verifica un plugin.

Ejecución de código sin interacción del usuario

Zero-click significa exactamente eso: la persona no hace nada. No abre un archivo, no aprueba un diálogo, no instala nada. Solo tener el plugin instalado, y además instalado correctamente —desde un marketplace de confianza, con la versión revisada y fijada como manda el modelo de seguridad— alcanza para quedar expuesto.

Quién lo encontró y cuándo

AIR encontró el fallo en mayo de 2026 y construyó pruebas de concepto funcionales contra los cuatro agentes. Lo reportó a cada fabricante en junio, con una ventana de divulgación responsable de unos 90 días, y lo publicó al no completarse las correcciones de todos los involucrados. No hay un identificador CVE publicado en el boletín revisado.

Cómo funciona, paso a paso

El mecanismo encaja en una cadena de tres eslabones, y el tercero es el más difícil de aceptar.

Qué es fijar un plugin por SHA y por qué se confiaba en eso

Cuando instalas un plugin, el agente lo fija a un commit concreto mediante su hash SHA. Es la garantía central del modelo: si el plugin pasó una revisión, ese código no puede cambiar sin que te enteres, porque cualquier alteración produce un hash distinto. Toda la confianza del ecosistema de plugins descansa en esa promesa.

El detalle que falla: git prefiere una rama antes que un commit con el mismo nombre

El agente pedía a git el commit fijado, pero nunca comprobaba que el resultado descargado fuera de verdad ese commit. Git resuelve antes una referencia o rama que se llame igual que el hash, y el pin seguía pareciendo intacto. Con permiso de escritura en el repositorio del plugin, al atacante le bastaba crear una rama cuyo nombre fuera el SHA fijado y subir código malicioso. El fallo funciona únicamente donde se permite nombrar una rama como un hash: GitHub rechaza de plano un nombre de 40 caracteres hexadecimales, pero Bitbucket y cualquier servidor git autoalojado sí lo permiten. Claude Code, Codex y Copilot comparten esta versión del problema; Gemini CLI estaba expuesto por un mecanismo distinto al descargar y preparar el commit fijado, con el mismo resultado.

La actualización automática hace el resto

El fallo no vive solo en la instalación, y por eso es cero clic: el mismo checkout se repite en la actualización automática en segundo plano, que es el comportamiento por defecto en Claude Code y Codex. Cuando el marketplace mueve el SHA fijado, el cambio llega a plugins ya instalados sin que nadie toque nada. El código se ejecuta con los permisos del agente, es decir, con acceso a todo lo que el agente puede alcanzar: repositorios, archivos del proyecto, variables de entorno y credenciales de desarrollo. Si el agente tiene llaves, el atacante se queda con ellas.

El estado real de los parches, uno por uno

La verificación que falta corre dentro del agente, no en el marketplace, así que ningún marketplace puede cerrar el agujero por su cuenta. Solo sirve actualizar el cliente, y ahí el panorama está partido:

  • Claude Code: corregido desde la versión 2.1.179.
  • Codex: corregido desde la versión 0.146.0.
  • GitHub Copilot: sin corrección publicada. Parte de la cobertura sitúa su vector en plugins servidos desde repositorios de terceros, como Bitbucket.
  • Gemini CLI: Google no lo parcheó, lo declaró obsoleto. Cada instalación existente queda vulnerable de forma indefinida, y la recomendación oficial es migrar a su agente más nuevo, Antigravity, construido sin el sistema de fijación de plugins que este ataque aprovecha.

Qué hacer esta semana según tu caso

Las acciones concretas dependen de qué agente uses y de cuántos plugins tengas encima.

  • Con Claude Code o Codex: actualiza y comprueba la versión instalada. Las anteriores siguen vulnerables.
  • Con Copilot: revisa qué plugins tienes y de dónde salen, desinstala los que no uses y desconfía de la actualización automática de plugins de terceros.
  • Con Gemini CLI: migra a otro agente, o asume la exposición.
  • En general: reduce los permisos del agente, usa tokens de vida corta y revísale el acceso a producción.
  • Y si crees que ya ocurrió: rota los secretos a los que el agente tuviera acceso y revisa el historial de acciones.

Esto no es nuevo: la cadena de suministro otra vez

El patrón es el de siempre: se ataca el eslabón en el que todos confían sin verificar. Lo que cambia es el consumidor de dependencias. La propia investigación de AIR sobre el ecosistema de skills de agentes encontró 925 skills que habían sido secuestradas de sus mantenedores originales y que alcanzaban a 134.000 agentes, en una línea de trabajo que la firma llama SkillJacking; en una investigación anterior, un plugin que construyeron se propagó a más de 26.000 agentes antes de ser retirado. La conclusión práctica del hallazgo es una sola frase: verifica el commit, no el nombre.

Conclusión

Plugin4Shell pone el dedo en un supuesto que el ecosistema daba por resuelto y no lo estaba: fijar la versión de un plugin no sirve de nada si nadie comprueba qué código llegó. Está corregido en dos de los cuatro agentes y sin corregir en los otros dos, así que la acción útil es concreta y esta semana: actualizar donde haya parche y reducir exposición donde no. El blog ya cubrió casos del mismo tipo, como los agentes de OpenAI que atacaron RubyGems, el CVE crítico de GitLab y la comparativa de editores de código con IA.

Categorías