La vulnerabilidad Plugin4Shell rompe una promesa central de seguridad en los agentes de programación con IA
Plugin4Shell ha expuesto una vía de ejecución remota de código sin interacción en cuatro grandes familias de agentes de programación con IA, pese a que utilizan versiones fijadas de plugins. Investigadores de seguridad afirman que la vulnerabilidad Plugin4Shell afectó a Anthropic Claude Code, OpenAI Codex, GitHub Copilot y Google Gemini CLI.
El fallo importa porque estos agentes hacen más que sugerir código. Pueden leer repositorios, ejecutar comandos, acceder a credenciales de desarrollo y comunicarse con servicios internos. Un plugin malicioso puede heredar ese alcance sin explotar antes otro límite de privilegios.
Anthropic y OpenAI han publicado correcciones, según los investigadores. Microsoft cuestiona que la vía reportada siga siendo explotable a través de GitHub, mientras que los investigadores sostienen que otros hosts Git compatibles mantienen el riesgo. Google ha dirigido a muchos usuarios de Gemini CLI a su entorno Antigravity más reciente, en lugar de corregir la herramienta de consumo obsoleta.
No se trata simplemente de otra historia de inyección de prompts. El ataque apunta a la capa de distribución de plugins y derrota un control conocido de la cadena de suministro de software. Tanto la revisión de código como la fijación de commits pueden parecer correctas mientras un agente instala código distinto.
Esa inversión pone bajo presión el modelo de seguridad de los marketplaces de agentes. Confiar en un plugin revisado ya no basta cuando el cliente no verifica qué llegó realmente al directorio de trabajo.
Qué cambió la vulnerabilidad Plugin4Shell
Plugin4Shell convierte un plugin ya instalado y previamente confiable en una vía para la ejecución silenciosa de código.
Investigadores de Air Security revelaron el problema el 17 de septiembre de 2026, después de informarlo a los proveedores afectados en junio. Su investigación sobre Plugin4Shell describe un error compartido en la forma en que los agentes de programación resuelven commits Git fijados.
Un marketplace de plugins puede revisar un complemento y registrar el commit exacto que contiene el código aprobado. Este proceso se conoce como fijación de SHA. Un SHA es un identificador hexadecimal que normalmente apunta a un commit específico de Git.
La fijación debería impedir que un cambio posterior en el repositorio reemplace silenciosamente el código revisado. Aunque un atacante cambie una rama, el agente debería seguir recuperando el commit aprobado.
Plugin4Shell rompe esa expectativa durante el checkout. Los agentes afectados solicitan el valor fijado, pero no confirman de forma fiable que el árbol de trabajo resultante coincida con él. Git puede interpretar un nombre ambiguo como una rama u otra referencia, en lugar del commit previsto.
Los investigadores demostraron dos variantes relacionadas. Claude Code, Codex y GitHub Copilot habrían estado expuestos mediante una rama denominada como un hash de commit de 40 caracteres. Gemini CLI utilizó una ambigüedad distinta relacionada con FETCH_HEAD.
En la primera variante, un atacante debe controlar el repositorio detrás de un plugin. El atacante crea una rama cuyo nombre coincide con un hash de commit fijado y la convierte en la rama predeterminada.
El agente clona el repositorio y pide a Git que haga checkout del valor fijado. Git prefiere la referencia coincidente cuando el nombre puede representar tanto una rama como un identificador de objeto. Puede emitir una advertencia y, aun así, hacer checkout de la rama del atacante.
Después, el agente informa que la instalación se realizó correctamente. Sin embargo, los archivos de su directorio de trabajo proceden de la rama maliciosa, no del commit revisado.
En la variante de Gemini CLI, el agente recupera el commit correcto y lo registra en FETCH_HEAD. Una rama predeterminada maliciosa con el mismo nombre puede influir en el checkout posterior. Por tanto, el objeto recuperado correctamente puede ignorarse.
La corrección técnica es breve. Tras el checkout, el agente debe resolver HEAD y compararlo con el hash de commit esperado. Cualquier discrepancia debe detener la instalación o actualización.
Las consecuencias van más allá de una comprobación de integridad fallida. Los plugins de agentes de programación pueden contener hooks, comandos e instrucciones que se ejecutan con los permisos del sistema operativo del agente.
Los investigadores clasifican el resultado como ejecución remota de código, o RCE. Este término significa que un atacante puede provocar la ejecución de código elegido en otra máquina desde una ubicación remota.
No se requiere una nueva instalación una vez que se produce el intercambio malicioso. Claude Code y Codex habilitan por defecto las actualizaciones automáticas de plugins, según Air Security. La actualización en segundo plano aporta el componente sin interacción.
Un desarrollador puede seguir el proceso de seguridad previsto, instalar un plugin aprobado y fijar su versión revisada. La actualización posterior aún puede sustituirlo sin otra solicitud.
Eso convierte a Plugin4Shell en un caso de verificación fallida, no de clics descuidados. La víctima no necesita aceptar un archivo sospechoso, aprobar un comando ni instalar un complemento desconocido.
Por qué la RCE en agentes de programación con IA implica riesgos inusuales
El valor de un agente de programación con IA proviene de su acceso, y ese mismo acceso determina el daño tras una vulneración.
Los asistentes de código tradicionales se limitaban principalmente a devolver sugerencias dentro de un editor. Las herramientas agénticas pueden inspeccionar archivos, modificar proyectos, ejecutar pruebas, llamar a gestores de paquetes e interactuar con sistemas de desarrollo en la nube.
Estas capacidades reducen el trabajo repetitivo. También sitúan al agente cerca de secretos y sistemas que los atacantes valoran.
Una estación de trabajo de desarrollo puede contener código fuente, claves SSH, tokens de registros de paquetes, credenciales en la nube, sesiones del navegador, materiales de firma y documentación interna. Las variables de entorno pueden exponer credenciales adicionales a los procesos iniciados durante el desarrollo.
Un agente también puede heredar sesiones autenticadas de línea de comandos. Un plugin malicioso no necesita necesariamente un exploit independiente de escalada de privilegios cuando el agente ya dispone de permisos útiles.
Air Security afirma que los plugins heredan las capacidades del empleado que ejecuta el agente. Esta afirmación depende de cada configuración local, pero refleja el riesgo central. El impacto potencial sigue el acceso efectivo del agente.
Un agente estrictamente aislado sin acceso a red presenta un nivel de exposición. Un agente que se ejecuta en el portátil de un desarrollador con credenciales de producción presenta uno mucho mayor.
Esta diferencia complica las calificaciones de gravedad. El mismo error de checkout puede afectar a un contenedor de pruebas desechable y a una estación de trabajo de ingeniería con privilegios. Sus consecuencias para el negocio no son comparables.
El ataque también puede cruzar límites organizativos a través de un marketplace de confianza. Un atacante puede publicar primero un plugin inocuo, superar la revisión y esperar su adopción. El repositorio puede modificarse después de que los usuarios hayan establecido su confianza.
La segunda vía comienza con la toma de control del repositorio. Un atacante compromete o recupera el control sobre infraestructura asociada a un autor legítimo de plugins. Plugin4Shell derrota entonces la fijación de commit destinada a contener ese incidente.
Air Security relaciona esta vía con su trabajo anterior sobre SkillJacking y RepoJacking. La empresa afirma que identificó previamente 925 skills susceptibles de secuestro que afectaban a 134.000 agentes.
Estas cifras proceden del proveedor de seguridad y no se han reproducido de forma independiente aquí. Aun así, muestran por qué la propiedad del repositorio y la identidad del plugin merecen atención junto al comportamiento del modelo.
Los investigadores también afirman que una skill maliciosa anterior llegó a más de 26.000 agentes. Ese experimento sugiere que la visibilidad en los marketplaces puede distribuir rápidamente contenido ejecutable, aunque no mide la explotación de Plugin4Shell.
Estos ejemplos ponen de relieve un cambio difícil en las herramientas para desarrolladores. Un plugin de IA no es simplemente una plantilla de prompt cuando puede registrar comandos, ejecutar hooks de ciclo de vida o influir en la ejecución de herramientas.
Las organizaciones deberían tratar estos complementos como paquetes de software. Necesitan comprobaciones de procedencia, actualizaciones controladas, límites de permisos y visibilidad de incidentes.
La vulnerabilidad reportada también presiona a los proveedores para definir dónde termina la seguridad del marketplace. Un marketplace puede inspeccionar el código enviado, pero el cliente local realiza la instalación.
Esa división importa porque la decisión final de integridad se produce en el endpoint. Un registro del marketplace no puede demostrar qué colocó realmente el agente en el disco.
Por tanto, los equipos de seguridad necesitan un inventario de complementos de agentes instalados. También deben saber a qué sistemas pueden acceder esos agentes y qué credenciales permanecen disponibles durante la ejecución.
Los desarrolladores afrontan un problema relacionado de documentación. La configuración de plugins, los permisos, el comportamiento de actualización y las notas sobre incidentes suelen estar repartidos entre repositorios e hilos de chat. Una base de conocimientos de ingeniería con capacidad de búsqueda puede ayudar a los equipos a conservar esas decisiones operativas.
La documentación por sí sola no bloquea un exploit. Sin embargo, puede reducir la confusión cuando los equipos deben identificar instalaciones afectadas, responsables y políticas de actualización previstas.
Los plugins de confianza se convirtieron en el principal adversario
Plugin4Shell enfrenta la promesa de plugins confiables y fijados con la realidad de checkouts del lado del cliente sin verificar.
La narrativa de seguridad de la industria se ha apoyado en varios pasos razonables. Revisar el complemento, aprobar una revisión específica, registrar su hash y mantener las instalaciones futuras vinculadas a ese objeto inmutable.
Cada paso puede seguir ocurriendo bajo Plugin4Shell. El fallo aparece en el límite final, donde el agente convierte la revisión solicitada en archivos y comportamiento ejecutable.
Eso hace que esta vulnerabilidad sea más inquietante que un listado de marketplace con código abiertamente malicioso. Los revisores pueden inspeccionar el commit correcto. Los administradores pueden confirmar que existe una fijación. Los registros pueden mostrar que se utilizó el valor solicitado.
No obstante, el contenido instalado puede diferir del contenido revisado.
Los investigadores describen esto como una elusión de la fijación SHA de plugins. La etiqueta resulta útil porque identifica la garantía rota sin implicar que la criptografía de Git haya fallado.
El hash de commit sigue siendo válido. La debilidad reside en la resolución de nombres y en la ausencia de verificación posterior al checkout.
Git permite referencias flexibles porque los desarrolladores usan ramas, etiquetas, referencias remotas e identificadores de objetos en muchos flujos de trabajo. El manejo de referencias ambiguas es una preocupación operativa antigua.
Los agentes de programación transformaron ese comportamiento en un límite de seguridad automatizado. Trataron un comando de checkout exitoso como prueba de que el commit solicitado se convirtió en el árbol de trabajo.
El estado de salida del comando solo respondía si Git completó la operación. No respondía si el HEAD resultante coincidía con la fijación del marketplace.
Esa distinción es fundamental para explicar Plugin4Shell en términos prácticos. Los metadatos de seguridad describían un objeto, mientras que la ejecución procedía de otro.
Por tanto, el marketplace y el endpoint mantenían versiones distintas de la realidad. El marketplace creía que autorizaba un commit fijo. El endpoint confiaba en la resolución de nombres de Git sin comparar el estado final.
La actualización automática amplificó la brecha. Una advertencia durante la instalación podría atraer atención durante una configuración manual. Una actualización en segundo plano puede repetir la secuencia vulnerable mientras el desarrollador realiza tareas no relacionadas.
Este diseño también debilita el consejo habitual de instalar solo plugins de confianza. La confianza en el momento de la instalación no puede predecir si un repositorio upstream será comprometido más adelante.
La pregunta más importante es si la confianza sigue siendo verificable durante cada actualización. Eso exige comprobar la identidad del repositorio, el contenido esperado del commit, el HEAD resuelto, las firmas cuando estén disponibles y las capacidades solicitadas por el plugin.
Ninguna comprobación individual sustituye al aislamiento en entornos sandbox. Incluso un código correctamente verificado puede contener vulnerabilidades no detectadas o comportamientos dañinos intencionados que hayan escapado a la revisión.
Por tanto, el principio de mínimo privilegio sigue siendo el segundo control. Un agente solo debería recibir los archivos, las credenciales, las rutas de red y las capacidades de comando necesarios para la tarea actual.
Eso puede generar fricción. Los agentes de programación resultan menos útiles cuando cada operación requiere aprobación manual o carece de acceso a los sistemas necesarios.
Plugin4Shell deja clara esta disyuntiva. Una mayor autonomía permite flujos de trabajo más rápidos, mientras que una autoridad más amplia incrementa el valor de cualquier extensión comprometida.
Las empresas no pueden resolver esta tensión únicamente mediante la reputación de un marketplace. Necesitan controles en las capas de instalación, ejecución, identidad, red y actualización.
Aquí es donde la seguridad de los agentes de programación con IA empieza a asemejarse a la seguridad consolidada de la cadena de suministro de software. Los nombres son nuevos, pero las preguntas centrales resultan familiares.
¿Quién publicó el componente? ¿Qué bytes exactos se revisaron? ¿Qué se ejecutó en el endpoint? ¿A qué podía acceder ese proceso? ¿Pueden los investigadores reconstruir posteriormente la secuencia?
Los parches ayudan, pero las respuestas de los proveedores dejan un riesgo desigual
La exposición inmediata depende ahora del agente, su versión, la fuente de su plugin y la interpretación del proveedor sobre la posibilidad de explotación.
Air Security afirma que Anthropic corrigió la falla en Claude Code 2.1.179. También afirma que OpenAI corrigió Codex en la versión 0.146.0 tras una divulgación coordinada.
Los usuarios deberían verificar las versiones instaladas en lugar de asumir que una actualización automática se completó. Las organizaciones también deberían confirmar qué imágenes gestionadas, contenedores de desarrollo y estaciones de trabajo remotas incluyen compilaciones antiguas.
La situación en torno al producto de Microsoft sigue siendo objeto de disputa. Air Security afirma que la implementación de GitHub Copilot estaba afectada y que Microsoft no había distribuido una corrección del lado del agente antes de la publicación.
Un portavoz de GitHub dijo a The Register que GitHub bloquea los nombres de ramas o etiquetas que se parecen a hashes de commit. La empresa sostiene que esta restricción impide el ataque reportado contra repositorios alojados en GitHub.
Esa respuesta aborda una condición previa importante. Un atacante no puede crear la rama ambigua de 40 caracteres en un host que rechaza esos nombres.
Los investigadores afirman que esta restricción a nivel de host no cierra todas las rutas compatibles. Su argumento se centra en marketplaces o repositorios alojados mediante Bitbucket y servicios Git autogestionados, que pueden permitir nombres de rama con forma de SHA.
El desacuerdo no debería simplificarse como una afirmación de que cualquiera de las partes ha resuelto plenamente el asunto. La restricción de alojamiento de GitHub puede bloquear la ruta demostrada basada en el nombre de la rama dentro de GitHub.
No demuestra necesariamente que todas las fuentes de marketplace compatibles con Copilot reciban una protección equivalente. Esa cuestión más amplia depende de los hosts aceptados por el producto y de su comportamiento de instalación.
Microsoft no había proporcionado una respuesta adicional a The Register antes de la publicación de su artículo. Los usuarios deberían estar atentos a un aviso del producto que defina las configuraciones afectadas y las mitigaciones compatibles.
Google presenta otro caso inusual. Air Security afirma que Gemini CLI se veía afectado por su variante distinta de FETCH_HEAD, pero Google decidió no corregir la herramienta de consumo obsoleta.
Google anunció su transición de CLI el 19 de mayo de 2026. La empresa trasladó su foco de consumo hacia Antigravity CLI y Antigravity 2.0.
Google indicó que Antigravity CLI pasó a estar disponible de forma general ese día. El acceso para consumidores mediante Gemini CLI y ofertas individuales relacionadas estaba programado para finalizar el 18 de junio.
El acceso empresarial no terminó bajo las mismas condiciones. El anuncio de Google señala que algunos clientes empresariales pueden seguir utilizando Gemini CLI mediante servicios con licencia y claves API empresariales.
Esa distinción hace que la palabra "obsoleto" sea insuficiente para tomar decisiones de riesgo. Los equipos de seguridad deben determinar si Gemini CLI sigue instalado, es utilizable y está conectado a plugins en su entorno.
Air Security afirma que Antigravity no está expuesto al ataque reportado porque carece del mismo mecanismo de fijación SHA del marketplace. Esta es una afirmación más limitada que decir que el producto más reciente no presenta riesgos de plugins.
No hay evidencia pública en la divulgación citada que establezca una explotación activa de Plugin4Shell en entornos reales. Los investigadores demostraron una prueba de concepto y técnicas relacionadas de toma de control.
Esa diferencia importa. Una cadena de explotación funcional demuestra viabilidad técnica, pero no establece cuántos endpoints fueron comprometidos.
La afirmación de que millones de agentes resultaron afectados también exige cautela. Los principales productos tienen grandes bases de usuarios, pero no todos los usuarios instalan plugins de marketplace ni habilitan configuraciones vulnerables.
La exposición depende de un plugin instalado, un repositorio ascendente controlable, un host Git compatible, un comportamiento vulnerable del cliente y capacidad de ejecución suficiente.
Las organizaciones deberían evitar ambos extremos. No deberían descartar el problema porque la explotación activa siga sin confirmarse. Tampoco deberían considerar que cada instalación ya está comprometida.
La respuesta adecuada depende de cada configuración. Inventaríen versiones, fuentes de plugins, registros de actualización, hosts de repositorios y privilegios de endpoint antes de asignar la gravedad del incidente.
Los agentes de IA Plugin4Shell necesitan más que comprobaciones de versión
Actualizar los clientes afectados es necesario, pero no responde a si un plugin malicioso ya llegó a un endpoint.
Los equipos deberían empezar por identificar productos y versiones. Deben localizar Claude Code, Codex, integraciones de GitHub Copilot y Gemini CLI en los dispositivos de los empleados y en los sistemas de desarrollo gestionados.
El inventario debe incluir entornos remotos. Las estaciones de trabajo en la nube, los contenedores de desarrollo, los ejecutores de CI y los hosts de compilación compartidos pueden ejecutar herramientas de agentes fuera de las vistas tradicionales de gestión de endpoints.
A continuación viene el descubrimiento de plugins. Los equipos deberían enumerar los complementos instalados, sus marketplaces, ubicaciones de repositorio, hashes fijados, commits resueltos actuales y configuraciones de actualización automática.
Un pin registrado en la configuración no basta. Los administradores deberían comparar el commit esperado con el HEAD real en el árbol de trabajo instalado.
También deberían revisar las reglas de alojamiento de repositorios. El rechazo de GitHub a las referencias con forma de SHA modifica la superficie de ataque demostrada, mientras que Bitbucket o los servicios Git autohospedados pueden comportarse de otra manera.
Esto no significa que los hosts que no son GitHub sean inherentemente inseguros. Significa que la mitigación descrita por GitHub depende de una restricción de nomenclatura específica de la plataforma.
Las organizaciones que usen versiones vulnerables deberían actualizar cuando existan correcciones. Los usuarios de Claude Code necesitan la versión 2.1.179 o posterior, según la divulgación de Air Security.
Los usuarios de Codex necesitan la versión 0.146.0 o posterior conforme a la misma orientación. Los administradores deberían confirmar esos umbrales con la información de versiones mantenida por los proveedores cuando haya avisos formales disponibles.
Los usuarios de Gemini CLI deberían evaluar la migración a Antigravity. Los clientes empresariales que conserven acceso necesitan orientación explícita de Google sobre las configuraciones afectadas y los controles compensatorios.
Los usuarios de Copilot deberían seguir la respuesta de Microsoft mientras revisan si sus fuentes de plugins se extienden más allá de los repositorios alojados en GitHub. Desactivar las actualizaciones de plugins puede reducir la exposición inmediata, pero también retrasa correcciones de seguridad legítimas.
Esa tensión aboga por actualizaciones controladas en lugar de una congelación permanente. Las empresas pueden replicar plugins aprobados, restringir las fuentes, validar los commits resueltos y promover actualizaciones después de verificarlas.
Los controles de ejecución aportan otra capa. Ejecute los agentes de programación en entornos aislados, restrinja el acceso a credenciales de producción e impida conexiones salientes innecesarias.
Las credenciales de corta duración reducen el valor de los secretos recuperados de una sesión comprometida. Las identidades de desarrollo separadas también pueden impedir que el compromiso de una estación de trabajo alcance la administración de producción.
La monitorización de red debería buscar conexiones inesperadas de procesos de agentes o plugins. Las herramientas de endpoint deberían conservar árboles de procesos, historiales de comandos, archivos modificados y eventos de acceso a credenciales.
Los equipos deberían inspeccionar los hooks del ciclo de vida de los plugins porque esas rutas pueden ejecutarse antes de que un desarrollador inicie una conversación normal. Las tareas en segundo plano merecen la misma atención que los comandos visibles del agente.
Los mantenedores de repositorios también tienen responsabilidades. Deberían proteger los repositorios de plugins con autenticación robusta, revisar los cambios de propiedad y eliminar la infraestructura abandonada de los listados de marketplaces.
Los marketplaces pueden mejorar la procedencia y la monitorización aunque no puedan corregir por completo el error del cliente. Pueden restringir los hosts compatibles, volver a validar la propiedad del repositorio, señalar cambios inusuales en la rama predeterminada y suspender actualizaciones sospechosas.
Sin embargo, el endpoint debe seguir verificando el commit extraído. La documentación de Git explica cómo checkout acepta ramas, etiquetas e identificadores de commit, creando la ambigüedad que los clientes deben gestionar de forma segura.
La formación en seguridad debería reflejar este nuevo modelo de ejecución. Los desarrolladores deben comprender que las habilidades y los plugins de agentes pueden ser software ejecutable, no paquetes inofensivos de instrucciones.
Un flujo de trabajo de IA interno claro puede ayudar a los responsables a seguir el trabajo de mitigación y las preguntas pendientes para los proveedores. Las defensas reales deben seguir residiendo en los controles de endpoint y de acceso.
Por último, los equipos deberían preparar un umbral de investigación. Un commit que no coincide, una actualización de plugin sin explicación, un proceso hijo inusual o una solicitud de red inesperada deberían desencadenar una revisión más profunda.
Esas señales no prueban una explotación de Plugin4Shell. Proporcionan motivos concretos para preservar evidencias y examinar el alcance del agente afectado.
Tres señales mostrarán si el riesgo está contenido
La próxima fase estará definida por la claridad de los proveedores, la evidencia de explotación y una verificación más sólida de los marketplaces.
La primera señal es un aviso de seguridad de Microsoft o GitHub que cubra las fuentes de plugins compatibles. Debería explicar si Copilot acepta marketplaces fuera de GitHub y si cambiará la verificación del lado del cliente.
Una declaración limitada sobre la nomenclatura de ramas de GitHub deja abiertas preguntas sobre Bitbucket y los repositorios autohospedados. Una corrección del producto que valide el commit resuelto reforzaría la conclusión más amplia de los investigadores.
Una conclusión documentada de que Copilot nunca procesa esas fuentes la debilitaría. Cualquiera de los dos resultados daría a los usuarios empresariales una base más clara para actuar.
La segunda señal es la evidencia de explotación en el mundo real. Los proveedores de seguridad, los equipos de respuesta a incidentes y los fabricantes de productos deberían publicar indicadores si identifican ramas maliciosas con forma de SHA o contenido de plugins sustituido.
Los compromisos confirmados trasladarían Plugin4Shell de una vulnerabilidad demostrada a una categoría de incidente activo. La ausencia continuada de abuso observado reduciría la urgencia inmediata, pero no la necesidad de aplicar parches.
La calidad de la detección importa aquí. Las organizaciones pueden carecer de inventarios de plugins de agentes, mientras que las actualizaciones en segundo plano pueden parecer actividad normal de desarrollo.
La tercera señal es un cambio en el diseño de verificación de plugins. Los proveedores de agentes deberían empezar a comprobar el HEAD resuelto después de cada instalación y actualización, y luego exponer ese resultado mediante registros.
Los marketplaces pueden añadir firmas, controles de identidad del editor, empaquetado reproducible y declaraciones de permisos más claras. Ninguna de esas funciones debería sustituir la verificación del endpoint.
Plugin4Shell probablemente seguirá siendo relevante después de que desaparezcan las versiones afectadas. La lección subyacente se aplica siempre que los metadatos de seguridad hagan referencia a un artefacto mientras el cliente ejecuta otro.
Los agentes de programación con IA hacen que esa discrepancia sea más relevante porque combinan recuperación de código, uso de herramientas, ejecución local y acceso empresarial. Su utilidad depende de capacidades que también amplían el impacto de una vulneración.
Los desarrolladores deberían plantearse una pregunta práctica antes de confiar en una extensión para agentes: ¿puede el sistema demostrar que el código revisado es el código que se está ejecutando ahora?
Los responsables de seguridad deberían plantearse una segunda pregunta: si esa prueba falla, ¿a qué puede acceder el agente antes de que alguien lo advierta?
La vulnerabilidad Plugin4Shell demuestra por qué ambas preguntas deben formar parte de la gobernanza rutinaria de ingeniería. Actualizar los clientes corregidos es la tarea inmediata. Verificar la ejecución, limitar la autoridad y preservar las pruebas son los requisitos a más largo plazo.
Los equipos que utilizan Claude Code, Codex, Copilot o Gemini CLI deberían inventariar ahora sus versiones y plugins instalados. Deberían comparar las fijaciones esperadas con los commits resueltos y documentar cualquier riesgo específico del proveedor que siga sin respuesta.
