Saltar al contenido

Plugin4Shell: anclar por SHA no sirve de nada si nadie comprueba el SHA

Publicado el 18 de septiembre de 2026

Cadena sobre una mesa con un eslabón falso y un candado abierto; al fondo, silueta de una persona de espaldas ante un monitor.

Resumen en una frase: los agentes de código anclan sus plugins a un commit concreto para que nadie te cuele código nuevo, pero luego no comprueban que el código que se han descargado sea el de ese commit. Y como además se autoactualizan, el ataque no necesita que hagas clic en nada.

Qué ha pasado

Un equipo de la startup de seguridad Air —Or Nevo, Dor Granat y Niv Hoffman— publicó el jueves un informe bautizando el fallo como «Plugin4Shell». Lo cuenta The Register. Afecta a los cinco sospechosos habituales: Claude Code, Codex de OpenAI, Gemini CLI, Copilot de Microsoft y GitHub Copilot. El resultado es ejecución remota de código sin interacción del usuario, con todo el alcance que tenga el agente: tus repositorios, tus tokens, tu máquina.

El mecanismo atacado no es el modelo. Es el SHA pinning de los marketplaces de plugins y skills: en vez de apuntar a una rama o a una etiqueta de versión —que cambian—, anclas el plugin al hash inmutable de un commit. Si mañana comprometen el repositorio del plugin, tú sigues ejecutando el código que auditaste. Esa es la idea.

La pega que encontró Air: el agente pide ese commit exacto, pero nunca verifica que el árbol de trabajo haya terminado ahí. Un atacante que controle el repositorio del plugin consigue que la resolución del checkout apunte a su código mientras el anclaje sigue pareciendo respetado. Ellos lo llaman «plugin SHA-pinning bypass». La pista de cómo se hace la da la propia mitigación de GitHub: no permiten crear ramas ni etiquetas cuyo nombre se parezca a un hash de commit.

El estado de los parches, a día de hoy:

  • Anthropic lo corrigió en Claude Code 2.1.179.
  • OpenAI lo corrigió en Codex 0.146.0.
  • Google ha dado por retirado Gemini CLI y ha dicho que no lo va a parchear: recomienda migrar a Antigravity, que según ellos no es vulnerable. Toda instalación existente se queda como está.
  • Microsoft no lo ha corregido. Air dice que les avisó en junio, igual que a los demás, y que no obtuvo respuesta.

GitHub sostiene que a ellos no les afecta por lo de los nombres de rama. Air responde que eso tapa una plataforma, no el problema: los marketplaces pueden alojarse en Bitbucket o donde sea, y Copilot admite esos marketplaces.

Por qué importa

Porque el plugin de un agente de código es una dependencia que casi nadie ha inventariado. No está en tu package-lock.json, no está en tu SBOM, no pasa por tu revisión de terceros. Lo instaló alguien del equipo un martes porque le ahorraba escribir cuatro prompts, y se ejecuta con los permisos de esa persona en su portátil: llaves SSH, token de npm, credenciales de nube, el repositorio entero montado en local. Eso es lo que hay al otro lado del fallo.

Y hay una lección más incómoda, que va mucho más allá de la IA: el anclaje sin verificación es un sello de calidad falso. Pinnear por hash sólo sirve si alguien compara el hash pedido con el hash obtenido. Si no, has cambiado seguridad real por la sensación de tenerla, que es peor que no tener nada, porque dejas de mirar.

Qué haría yo esta semana, por orden:

  1. Actualizar los agentes. Claude Code a 2.1.179 o superior, Codex a 0.146.0 o superior. Es la única mitigación completa donde existe parche. Si alguien del equipo sigue con Gemini CLI, ahí no va a llegar arreglo: toca migrar o quitarle los plugins de terceros.
  2. Inventariar plugins y skills instalados. No los del proyecto: los de las máquinas. Si no sabes responder «qué extensiones tiene instaladas el agente de cada persona del equipo», ese es el trabajo de hoy.
  3. Apagar la autoactualización de plugins donde se pueda. Es lo que convierte un incidente en un cero-clic: cambian el contenido aguas arriba y te llega solo.
  4. Verificar el checkout en tu propia automatización. Si tienes scripts que clonan por hash, después del checkout haz git rev-parse HEAD y compáralo con el hash que pediste. Si no coincide, falla. Son dos líneas y cubren esta clase entera de trucos.
  5. Espejar lo que de verdad uses. Un fork interno del plugin, y cuando quieras subir de versión, miras el diff. Aburrido, sí. Funciona.
  6. Recortar el alcance del agente. El daño de un RCE es exactamente lo que el proceso pueda tocar. Si tu agente de código corre con el token que despliega a producción, el problema no es el plugin.

Qué no cambia

Seamos justos con los matices, que aquí hay varios.

El informe lo firma una empresa que vende protección para agentes de IA en entornos corporativos. Eso no invalida el hallazgo —la cadena está demostrada de punta a punta, apoyada en su trabajo previo de SkillJacking y RepoJacking—, pero sí conviene leerlo sabiendo quién lo publica. En el material no hay ninguna evidencia de explotación real en la naturaleza: es una prueba de concepto, no un incidente en curso.

La mitigación de GitHub tampoco es humo. Si todos tus marketplaces y plugins viven en GitHub, esa vía concreta está cerrada. Lo que dicen los investigadores es que no cubre otras plataformas, y tienen razón; lo que no puedes concluir es que GitHub no haya hecho nada.

Y el dato del 90 % de las Fortune 500 usando Copilot es una cifra de Microsoft sobre adopción de producto, no un recuento de máquinas expuestas. Sirve para entender el tamaño del tablero, no para medir el incendio.

Lo que no cambia, sobre todo, es la naturaleza del problema: esto es un ataque de cadena de suministro de los de siempre, con la novedad de que la cadena ahora entra por una herramienta que instalamos hace seis meses sin pensarlo mucho. La higiene que aplicas a tus dependencias de código aplica igual aquí. Sólo que todavía no la estabas aplicando.

Si quieres que le echemos un vistazo a qué tiene instalado tu equipo, me dices y lo vemos.

Un saludo, Vicente.

Fuente: The Register

¿Te ha surgido una duda leyendo esto?

Pregúntanos. Respondemos aunque no acabes siendo cliente.