¿Es fiable el plugin?
El examen abarca su utilidad, diseño, comandos, hooks e integraciones externas.
Procesando…
IA y ciberseguridad
Plugin4Shell revela un fallo de verificación de los plugins de agentes de IA. Descubre el mecanismo, las correcciones y las precauciones que deben tomarse
Un plugin aprobado y bloqueado en una versión concreta debería ejecutar el código que se ha verificado, no otro. Plugin4Shell revela cómo esta garantía podía fallar en el momento de la instalación.
El 17 de septiembre de 2026, AIR Security presentó Plugin4Shell, una vulnerabilidad relacionada con los mecanismos de plugins de Claude Code, OpenAI Codex, GitHub Copilot y Gemini CLI. El ataque presupone, entre otras cosas, el control del repositorio del plugin.
El problema afecta a una etapa esencial: verificar que la revisión Git obtenida corresponde realmente a la que fue aprobada. La corrección pública de Codex confirma que una confusión entre un identificador de commit y un nombre de rama podía llevar a recuperar otra versión del código.
Para los desarrolladores, este caso recuerda que no basta con elegir una extensión fiable. También hay que poder garantizar que el código instalado es realmente aquel en el que se depositó la confianza.
Solicitar un commit aprobado no demuestra que ese commit se haya instalado realmente. El cliente debe resolver la revisión obtenida y verificar que corresponde exactamente al identificador esperado.
Un plugin de agente de programación no se limita necesariamente a añadir un atajo o unas pocas instrucciones.
En Claude Code, los plugins pueden agrupar competencias especializadas, subagentes, integraciones MCP y hooks. Estos últimos permiten activar comandos en respuesta a determinados eventos, por ejemplo, después de modificar un archivo.
Esta flexibilidad resulta útil: un equipo puede distribuir sus convenciones de desarrollo, sus herramientas de verificación o sus automatizaciones en un conjunto reutilizable.
El examen abarca su utilidad, diseño, comandos, hooks e integraciones externas.
La distribución, la verificación de las versiones y los permisos deben garantizar que el código obtenido corresponde al que fue aprobado.
Estas dos preguntas son complementarias. El examen inicial responde sobre todo a la primera; los mecanismos de distribución y control deben hacerse cargo de la segunda.
Para entender el problema, hay que distinguir una rama de Git de un commit concreto.
Una rama designa una línea de desarrollo y puede avanzar hacia nuevos commits. En cambio, un identificador de commit permite seleccionar una revisión determinada. El comando git checkout acepta distintas formas de referencias, incluidos nombres de ramas e identificadores de commits.
La fijación, o pinning, consiste en solicitar una revisión concreta en lugar de seguir una referencia susceptible de evolucionar.
La documentación de los marketplaces de Claude Code contempla así un campo sha que contiene el identificador completo del commit que se utilizará. Sirve para bloquear un plugin en una versión exacta, independientemente de la rama o la etiqueta que puedan haberse indicado.
El objetivo es sencillo: después de examinar una versión, un equipo quiere que las siguientes instalaciones utilicen esa misma versión.
GitHub también recomienda fijar las acciones en un SHA completo para utilizar versiones inmutables en los workflows de GitHub Actions. La vulnerabilidad subraya la necesidad de aplicar correctamente este control y verificar su resultado.
La corrección de Codex describe un caso concreto: cuando la rama predeterminada de un repositorio tiene el mismo nombre que el SHA solicitado, Git puede interpretar ese valor como un nombre de rama.
El cliente cree seleccionar el commit aprobado, cuando la operación puede terminar en otra revisión. Sin un control posterior al checkout, la instalación puede considerarse correcta a pesar de esta diferencia.
Por tanto, no se trata de una ruptura del mecanismo criptográfico de Git. El fallo se encuentra en la forma de seleccionar y después verificar el resultado esperado.
AIR también describe una variante relacionada con Gemini CLI y que implica FETCH_HEAD. El informe precisa que GitHub bloquea las ramas cuyo nombre coincide con un SHA completo, lo que limita la primera variante sin resolver todos los escenarios.
Esta distinción evita una generalización engañosa: no todos los repositorios, proveedores de alojamiento ni configuraciones presentan exactamente la misma exposición.
Según AIR, el escenario sin una nueva interacción afecta especialmente a las actualizaciones automáticas de plugins ya instalados en Claude Code y Codex. Una evolución del commit aprobado en el catálogo puede activar la recuperación del código malicioso.
Por tanto, el término zero-click debe entenderse en este contexto: ya existe una relación de confianza con el plugin y después interviene una operación automática.
No significa que cualquier ordenador pueda verse comprometido sin condiciones. La presencia de un componente afectado, su procedencia y su mecanismo de actualización forman parte del análisis del riesgo.
La pregunta operativa pasa a ser: ¿qué acciones pueden producirse después de la aprobación inicial sin que una persona vuelva a examinar el código?
Hay que distinguir las correcciones verificables públicamente de la información comunicada por los investigadores en el momento de su anuncio.
| Herramienta | Estado documentado |
|---|---|
| Claude Code | AIR indica una corrección en la versión 2.1.179. |
| OpenAI Codex | La versión 0.146.0 incluye la corrección de verificación de los checkouts Git de plugins, referenciada en las notas de versión oficiales. |
| GitHub Copilot | AIR no señalaba una corrección disponible en su informe del 17 de septiembre de 2026. |
| Gemini CLI | AIR informa de la ausencia prevista de una corrección y de una orientación hacia Antigravity, relacionada con la depreciación del producto. |
Las dos últimas líneas describen el estado comunicado por AIR en el momento de la publicación, no una confirmación independiente de su situación a 21 de septiembre de 2026.
En el caso de Codex, la verificación puede consultarse directamente: las notas de versión hacen referencia a la modificación «Verify Git plugin SHA checkouts». Por tanto, no se trata únicamente de una afirmación del informe de investigación.
Estos números designan versiones correctivas de referencia, no necesariamente las versiones más recientes que deban desplegarse.
La corrección pública de Codex añade una verificación después de la extracción: resolver el commit designado por HEAD y rechazar la fuente si ese identificador no coincide exactamente con el SHA solicitado. Una prueba de no regresión también cubre la confusión con una rama cuyo nombre coincide con el de un commit.
El siguiente comando permite resolver el commit actual en un repositorio Git:
git rev-parse --verify 'HEAD^{commit}'Solicita a Git que verifique que HEAD puede resolverse en un objeto commit y muestre su identificador.
Haber solicitado una versión aprobada no demuestra que esa versión se haya obtenido. El identificador resuelto efectivamente debe compararse con el SHA esperado.
Sin embargo, este comando no constituye una auditoría de seguridad completa. No certifica ni la inocuidad del commit ni, por sí solo, la ausencia de modificaciones en los archivos de trabajo. La documentación de Git distingue entre el commit seleccionado y las modificaciones locales que pueden permanecer en el directorio de trabajo.
Una vez cargado un código no fiable, su impacto potencial depende de aquello a lo que pueda acceder.
En sus recomendaciones para GitHub Actions, GitHub señala que un componente de terceros comprometido puede acceder a los secretos disponibles en su entorno y, según los permisos concedidos, utilizar los tokens asociados al workflow. Es una ilustración concreta del riesgo que plantea el código externo ejecutado en un entorno privilegiado.
Aplicado a un puesto de desarrollo, este razonamiento lleva a examinar los archivos, credenciales y servicios accesibles para el proceso afectado. Un entorno dedicado con permisos limitados no ofrece las mismas posibilidades que una sesión con acceso a las herramientas y secretos de producción.
Sin embargo, sería excesivo equiparar toda ejecución de código con un acceso administrativo automático.
OpenAI distingue, entre otros aspectos, las restricciones de sandbox, las solicitudes de autorización y los accesos de red en el funcionamiento de Codex. Estas protecciones deben evaluarse por separado: la verificación de un plugin y la limitación de las acciones que puede realizar no cumplen la misma función.
El control ausente se encuentra en el cliente que recupera el plugin. Por tanto, actualizar únicamente el catálogo o la extensión no sustituye al despliegue de la corrección del agente.
Relacionar cada plugin con su catálogo, su repositorio de origen, la versión esperada y su uso en el equipo facilita la verificación y el seguimiento.
La revisión debe abarcar los comandos activados, los hooks, las integraciones externas y la configuración de las herramientas, no solo la descripción del plugin.
Solo deberían estar disponibles los accesos necesarios para la tarea, en lugar del conjunto de privilegios del desarrollador o del entorno.
Un contenedor puede limitar algunas consecuencias, pero no protege los datos, las credenciales ni los servicios que siguen siendo accesibles desde su entorno.
Un equipo debe identificar las instalaciones que se utilizan realmente: puestos individuales, entornos compartidos e imágenes de desarrollo. El objetivo es evitar que una herramienta corregida en un puesto siga desactualizada en otro lugar.
Claude Code ofrece, entre otras opciones, parámetros administrados para restringir los marketplaces autorizados. Sin embargo, su documentación precisa que restringir el catálogo no equivale a verificar cada entrada que contiene.
Elegir una fuente autorizada y verificar su contenido son dos controles complementarios.
Los hooks de Claude Code pueden, por ejemplo, ejecutar un comando después de determinados eventos. Por tanto, la revisión debe centrarse en estas automatizaciones, no únicamente en las instrucciones visibles destinadas al modelo.
Una pregunta sencilla puede guiar esta verificación: ¿qué puede hacer este plugin sin una nueva decisión del usuario?
GitHub recomienda, entre otras medidas, permisos mínimos para los secretos y GITHUB_TOKEN, así como examinar el código de los componentes de terceros utilizados en los workflows. Esta lógica constituye un punto de partida útil para las automatizaciones de desarrollo.
OpenAI precisa que los devcontainers aportan protección, pero no impiden todos los ataques: los datos y credenciales accesibles desde el interior pueden seguir quedando expuestos por un proyecto malicioso en determinadas configuraciones.
Por tanto, el reto no consiste únicamente en colocar al agente «dentro de una caja», sino en verificar qué contiene esa caja y qué accesos conserva hacia el exterior.
La pregunta correcta no es únicamente: «¿Hemos aprobado este plugin?»
También debe ser: «¿Cómo verificamos que la instalación corresponde a lo que hemos aprobado?»
La corrección de Codex ofrece una respuesta concreta a esta pregunta al controlar la revisión obtenida, en lugar de confiar únicamente en la solicitada.
Para los desarrolladores web, la lección se aplica a cualquier cadena de herramientas: una revisión inicial, una referencia precisa y una fuente conocida son útiles, pero estas garantías deben seguir siendo coherentes hasta la ejecución.
La confianza depositada en un plugin nunca debería sustituir la verificación del código instalado efectivamente.
El alcance anunciado y los estados atribuidos a los editores proceden del informe Plugin4Shell de AIR Security, publicado el 17 de septiembre de 2026.
El mecanismo y la corrección de Codex se contrastaron con la pull request oficial n.º 34644 y las notas de versión de Codex 0.146.0. Las explicaciones complementarias se basan en las documentaciones de Git, Anthropic, GitHub y OpenAI citadas en el artículo.
WEB Y CIBERSEGURIDAD
La auditoría del código, las dependencias y las rutas sensibles convierte una alerta técnica en un plan de acción controlado.
Introduce al menos 2 caracteres para iniciar la búsqueda.