SHA Pinning no es verificación: Plugin4Shell y el primer RCE de cadena de suministro de agentes de IA

925 skills de plugins ya han sido secuestradas de sus mantenedores originales, y esas skills alcanzan a 134.000 agentes. El 17 de septiembre de 2026, AIR Security divulgó Plugin4Shell — la primera vulnerabilidad de cadena de suministro del ecosistema de agentes de IA: una ejecución remota de código (RCE) de cero clics que afecta a Claude Code, OpenAI Codex, GitHub Copilot y Google Gemini CLI, todos a través de la misma comprobación omitida. El mecanismo es una única aserción de git que todos los agentes afectados se saltan: el agente comprueba el commit SHA fijado por el marketplace pero nunca verifica que el árbol de trabajo aterrizó realmente en ese commit. Un atacante que controla el repositorio de un plugin nombra una rama con el SHA de 40 caracteres fijado, la convierte en la rama predeterminada del repositorio, y el agente instala código controlado por el atacante mientras reporta una instalación limpia en el commit fijado (Cyber Security News; Help Net Security).

Esto importa a cualquier equipo que ejecute agentes de programación contra sistemas de producción porque el pin era el control. Las organizaciones que van más allá de un marketplace comunitario — revisando el código de los plugins, fijando las instalaciones a un commit revisado — confiaban en el pinning de SHA como su salvaguarda, y Plugin4Shell lo anula silenciosamente: la revisión pasa, el pin se escribe, y se ejecuta código diferente (AIR). Este artículo cubre las cuatro cosas que un Director de Ingeniería necesita antes de la próxima actualización automática de un plugin: el mecanismo en un comando de git, el ataque de cinco pasos desde la adopción benigna hasta el RCE en segundo plano, el marcador de respuesta de los proveedores (dos parcheados, uno sin parche, uno deprecado sin parche), y los ítems de verificación que cierran la brecha para cada artefacto fijado que instalen sus agentes — plugins, servidores MCP y skills.

Conclusiones clave

• Un RCE de cero clics golpeó a los cuatro agentes de programación principales — Claude Code, Codex, GitHub Copilot y Gemini CLI — a través de una única aserción de git omitida — AIR divulgó Plugin4Shell el 17 de septiembre de 2026: los agentes comprueban el commit SHA fijado por el marketplace pero nunca verifican que el checkout resolvió a él (AIR).
• 925 skills ya han sido secuestradas de sus mantenedores, alcanzando a 134.000 agentes — la investigación de SkillJacking de AIR; Plugin4Shell derrota el mecanismo de pinning de SHA construido precisamente para contener estos takeovers de repositorios (AIR).
• Git prefiere una rama nombrada como un hash antes que el hash mismo — una rama que lleva el SHA de 40 caracteres fijado como su nombre, establecida como predeterminada del repositorio, redirige git checkout <sha> a código del atacante; la variante de Gemini CLI eclipsa FETCH_HEAD en su lugar (Cyber Security News).
• El marcador de proveedores se sitúa en 2 parcheados, 1 sin parche, 1 deprecado sin parche — Anthropic corrigió Claude Code en 2.1.179 y OpenAI corrigió Codex en 0.146.0; Microsoft no ha publicado ningún fix para Copilot, y Google deprecó Gemini CLI sin parche, por lo que cada instalación existente sigue expuesta (Help Net Security).
• Una sola aserción cierra ambas variantes: verificar el HEAD resuelto contra el SHA fijado después del checkout — test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort — y debe ejecutarse dentro del agente, porque ningún marketplace puede imponer un pin que no resuelve (AIR).

El diagrama siguiente comprime la divulgación en un minuto: la cadena de ataque de cinco pasos, el marcador de proveedores a tres días, y la aserción que cierra la brecha.

El mecanismo: una aserción, cuatro agentes

El pinning de SHA es el modelo de seguridad del marketplace funcionando como fue diseñado. Un revisor inspecciona un plugin en un commit, el marketplace registra el SHA de ese commit, y se supone que el agente instala exactamente ese código para siempre. El fallo está en el último paso. Todos los agentes afectados ejecutan aproximadamente esta secuencia (AIR):

git clone  ./
git checkout aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   # el SHA fijado

y nunca preguntan si el checkout aterrizó realmente en el commit fijado. Esa omisión es explotable porque git resuelve los nombres antes que los objetos: cuando un nombre es tanto una ref válida como un hash de commit, git prefiere la ref y solo imprime una advertencia refname is ambiguous. El atacante — que ya controla el repositorio upstream — crea una rama cuyo nombre es el SHA fijado exacto de 40 caracteres hexadecimales y la establece como predeterminada del repositorio. Un git clone simple trae esa rama como ref local, git checkout <sha> resuelve a la rama, y el árbol de trabajo queda controlado por el atacante mientras el agente reporta una instalación exitosa en el SHA fijado (Cyber Security News).

Dos condiciones hacen que el truco funcione. Primera: nada bloquea universalmente una rama nombrada como un hash — el propio check-ref-format de git acepta nombres de 40 caracteres hexadecimales, y aunque GitHub los rechaza de plano, Bitbucket y los servidores git autohospedados los permiten — y la propia documentación de Anthropic lista Bitbucket y git autohospedado como backends válidos de marketplace (AIR). Segunda: la rama debe ser la predeterminada del repositorio; una rama no predeterminada llega solo como ref de remote-tracking, y el checkout retrocede al commit real.

Gemini CLI falla de manera diferente. Su secuencia de instalación obtiene el commit fijado y luego hace checkout de FETCH_HEAD:

git clone --depth 1  ./
git fetch origin 41d0bc0a4aeb2fbf797dacea39e876d98c95024b
git checkout FETCH_HEAD

Si la rama predeterminada del repositorio se llama a su vez FETCH_HEAD, el checkout resuelve a esa rama y descarta silenciosamente el commit obtenido (AIR). Comando diferente, misma causa raíz: el agente confía en el nombre que solicitó en lugar de verificar el commit que recibió.

El ataque, de extremo a extremo: cinco pasos desde la adopción hasta el RCE

Ninguna de las dos rutas de ataque requiere controlar el marketplace. AIR demostró ambas:

1. Sembrar. El atacante publica un plugin genuinamente benigno, fijado al commit aaa…aaa. Pasa la revisión.
2. Adopción. Los usuarios lo instalan. Cada instalación queda fijada al commit revisado.
3. Re-fijar. El atacante envía una actualización rutinaria, aún benigna; el marketplace mueve el pin a bbb…bbb.
4. Traición. El atacante crea una rama llamada bbb…bbb, la establece como predeterminada del repositorio y la apunta a código malicioso. El commit fijado puede permanecer intacto.
5. Actualización automática a RCE. El pin cambiado dispara la actualización automática en segundo plano de todos los agentes — comportamiento predeterminado en Claude Code y Codex — el checkout resuelve el nuevo pin a la rama, y el código se ejecuta sin clic, sin aviso y sin reinstalación (AIR).

La ruta alternativa es más rápida: tomar el control del repositorio de un mantenedor legítimo y saltarse el paso de siembra por completo. La investigación complementaria de AIR cuantifica cuán común es eso ya — 925 skills secuestradas de sus mantenedores originales, alcanzando a 134.000 agentes (AIR). Es el tercer acto de una serie: The Story of Skills mostró una skill maliciosa alcanzando 26.000 agentes, y MCPJacking encontró 155 servidores MCP secuestrables en el marketplace oficial mediante dominios expirados, que los investigadores registraron para obtener ejecución remota de prompts en cada agente que confiaba en ellos (AIR). Plugin4Shell es el fallo de frontera del mecanismo que la industria construyó para contener todo esto. El radio de impacto también es mayor que el agente: los plugins y add-ons heredan los permisos del desarrollador que ejecuta el agente — código fuente local, credenciales en la nube, claves SSH, repositorios internos y sistemas de producción (Cyber Security News).

El marcador de proveedores: dos parcheados, uno sin parche, uno deprecado sin parche

La línea temporal de divulgación muestra que la divulgación coordinada funcionó — y dónde se detuvo:

Cuándo	Qué
Mayo 2026	AIR encuentra el fallo, con un PoC funcional contra los cuatro agentes
Junio 2026	Divulgación coordinada a los cuatro proveedores
17 jun 2026	Anthropic confirma el fix en Claude Code 2.1.179
4 ago 2026	Google confirma que no habrá fix — Gemini CLI está deprecado; se pide a los usuarios migrar a Antigravity
12 ago 2026	Codex 0.146.0 de OpenAI verificado como corregido
17 sep 2026	Divulgación pública

Al 18–19 de septiembre, el marcador no cambia: Anthropic parcheado, OpenAI parcheado, Microsoft no ha publicado ningún fix para Copilot, y Google deprecó Gemini CLI sin parche — lo que significa que cada instalación existente de Gemini CLI sigue expuesta indefinidamente (Help Net Security). La respuesta de GitHub — prohibir los nombres de ramas y tags con forma de SHA en su plataforma — no cierra la brecha, porque los marketplaces pueden alojarse en Bitbucket o servidores git autohospedados donde esos nombres siguen siendo legales (Cyber Security News).

El resumen de AIR es el honesto: "The fix has to ship in the agent, and updating is the only complete mitigation where one exists" (AIR). La razón estructural merece reiterarse para conversaciones de adquisición: el pin se resuelve dentro del agente, así que un marketplace no puede imponer la garantía que publicita. El escaneo de subidas del marketplace por parte de los proveedores (Anthropic lanzó Skill/Plugin Scanning el 6 de agosto de 2026) reduce la probabilidad de que un plugin malicioso entre en el marketplace, pero no puede sustituir la verificación del checkout en el agente — el intercambio ocurre después de la revisión, en el momento de la resolución (MCP Security Hardening Checklist). Este es también el exponente de gobernanza: cuatro proveedores, un defecto de diseño compartido, y una respuesta asimétrica de tres días que una organización compradora puede leer como la cadencia de parches de seguridad de un proveedor en miniatura.

Verificación después del checkout: el control que se generaliza

El fix de una línea de AIR cierra ambas variantes (AIR):

test "$(git rev-parse HEAD)" = "" || abort

Los detalles llevan la lección. git rev-parse HEAD resuelve lo que el árbol de trabajo contiene realmente — no el nombre que se solicitó. Esa distinción es exactamente lo que se cuela en la variante FETCH_HEAD de Gemini. Y la comprobación debe ejecutarse dentro del agente, porque el pin se resuelve en el cliente. Un marketplace que verificara después del checkout solo estaría verificando su propio registro; el agente es el componente que debe abortar en caso de discrepancia.

Ese patrón — verificar después de la resolución, no antes — se generaliza a cada control de artefacto fijado en una pila de agentes. Una versión de servidor MCP fijada, una skill fijada, un peso de modelo fijado, un digest de contenedor fijado: cada uno es una afirmación que algún instalador es de confianza para honrar y nadie verifica la resolución. La misma aserción omitida vive dondequiera que ocurre el checkout. Cuatro ítems para trabajar esta semana:

1. Actualizar los agentes que tienen fixes. Claude Code a 2.1.179 o posterior; Codex a 0.146.0 o posterior. Copilot y Gemini CLI no tienen fix — restringe el alcance de esos agentes (sistema de archivos, credenciales, salida de red) hasta que uno llegue, o sigue la ruta de migración del proveedor.
2. Inventariar cada artefacto fijado. Plugins, skills, versiones de servidores MCP, instaladores internos. Para cada uno, confirmar si algún código se salta la aserción de HEAD resuelto — esto incluye tooling interno escrito por tu equipo, no solo agentes de proveedores.
3. Auditar los repositorios de plugins en busca de señales de takeover. Cambios inesperados de ramas, movimientos de rama predeterminada, transferencias de propiedad. Las 925 skills secuestradas fueron tomadas antes de esta divulgación; el takeover de repositorios es el paso de entrada y ya opera a escala (Cyber Security News).
4. Tratar la actualización automática de plugins como un canal de entrega de cadena de suministro, no como una comodidad. Permitir solo los marketplaces y repositorios de los que los agentes pueden extraer; someter los re-pins a re-revisión donde la configuración del agente lo permita. La propiedad de cero clics proviene de la actualización automática — elimina el "cero" y el ataque necesita de nuevo una acción del usuario.

Dos CVE adyacentes, y la exposición persistente

La misma semana produjo dos CVE de servidores MCP que comparten el tema de Plugin4Shell — confianza depositada en un componente que nunca verificó a su llamador. CVE-2026-54618 afecta a Obsidian Web MCP anterior a 0.2.0: el endpoint de autorización OAuth emitía códigos a cualquier llamador sin autenticar al usuario, otorgando a un atacante remoto no autenticado acceso completo de lectura, escritura, búsqueda, movimiento y eliminación a todo el vault, corregido en 0.2.0 (Rapid7; GitHub advisory GHSA-hwhg-mrjc-8g43). CVE-2026-54446 es un fallo de autenticación ausente (CWE-306) en NetLicensing-MCP (Practical DevSecOps). Se suman a los números persistentes del ecosistema que no se han movido en meses: 97M+ descargas mensuales de MCP, 82% de los servidores muestreados vulnerables a path traversal, y solo 8.5% usando OAuth (Practical DevSecOps).

El patrón a través de las tres divulgaciones es el mismo en cada capa de la pila de agentes: un mecanismo de confianza — un pin, un flujo OAuth, un endpoint de servidor — que realiza su comprobación en el momento equivocado o no la realiza. Plugin4Shell es simplemente el primero que cruzó de un producto a todo el ecosistema a la vez.

Lecturas relacionadas

• MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them — la línea base de 12 controles donde encaja esta vulnerabilidad: Plugin4Shell pertenece a la capa de cadena de suministro (controles 5–7), junto a la actualización de Skill/Plugin Scanning
• Shadow AI Agents: 17,800 Add-Ons, 6.7 Million Installations, and the Runtime Control Gap — el inventario y la brecha de control en runtime que determinan si un add-on secuestrado es detectado
• The First MCP CVE on the KEV List Hit Its Federal Deadline: LiteLLM and the Default-Key Vault — el CVE de MCP que alcanzó el estatus de remediación federal, y los seis ítems de verificación de gateway que lo cierran

---

Un distribuidor industrial de tamaño medio ejecuta Claude Code para tooling interno y un agente de adquisiciones que cotiza contra NetSuite y dos catálogos de proveedores. El equipo inventaría cada artefacto fijado en ambas superficies, actualiza Claude Code a 2.1.179, deshabilita la actualización automática en segundo plano de plugins, y añade la aserción de HEAD resuelto a su instalador interno de módulos MCP. Las fuentes de plugins se mueven a una lista permitida de dos repositorios revisados, y el registro de auditoría anota cada re-pin con su diff. El próximo incidente de marketplace se convierte en un salto de versión y una revisión, no en una respuesta a incidentes.

Solicita un build con alcance definido. Una semana de discovery. Recibes un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — construyas con nosotros o no.