La falla que puso en jaque a los agentes de código más usados

Si tu equipo programa con ayuda de un agente de IA, probablemente le instaló plugins: piezas adicionales que alguien más construyó y que extienden lo que la herramienta puede hacer, de la misma forma en que instalas una aplicación en tu teléfono. Para confiar en que esa pieza no fue alterada después de que alguien la revisó, estas herramientas usan una especie de huella digital del código exacto que se aprobó — en la jerga del oficio, un hash. Mientras la huella coincida, la herramienta asume que el contenido no cambió.

El 17 de septiembre, tres investigadores de la firma de seguridad AIR Security —Or Nevo, Dor Granat y Niv Hoffman— publicaron un hallazgo llamado Plugin4Shell: una forma de hacer que esa verificación de huella pase, aunque el contenido detrás sí haya cambiado. Afecta a cuatro de los agentes de código más usados del momento — Claude Code, Codex, GitHub Copilot y Gemini CLI —, todos construidos sobre el mismo supuesto que la falla rompe.

No es una vulnerabilidad exótica que solo le importe a un equipo de seguridad. Si alguien en tu negocio usa una de estas cuatro herramientas con plugins de terceros, el tema te toca directamente — y la parte más incómoda es que, en dos de las cuatro herramientas, no hizo falta que nadie se equivocara para quedar expuesto.

Qué significa “ejecución de código” para tu negocio

El nombre técnico completo de este tipo de falla es “ejecución remota de código” — alguien de fuera logra que una máquina que no es la suya corra instrucciones que esa persona escribió, no tu equipo. No es sinónimo de que tu negocio ya haya sido atacado: es la puerta que haría posible el ataque, si alguien decidiera usarla contra un repositorio de plugins concreto.

Lo relevante para quien no programa es qué puede hacer alguien una vez que esa puerta está abierta: leer archivos que había en esa máquina, incluidas credenciales guardadas o código propio de tu negocio, o usar esa misma máquina como punto de partida para llegar a otros sistemas conectados a ella. La gravedad no depende de qué tan grande sea tu empresa — depende de qué tenía acceso la máquina donde corría el agente.

Qué es un plugin, para quien no programa

Si en tu negocio nadie escribe código directamente, es fácil pensar que esto no te aplica. Vale la pena entender el concepto un momento, porque cada vez más negocios contratan desarrollo — propio o externo— apoyado en estos agentes, y la pregunta “¿qué plugins tienen instalados?” empieza a ser tan razonable como preguntar qué aplicaciones tiene instaladas el celular de la empresa.

Un agente de código como los cuatro que menciona esta pieza llega, de fábrica, con un conjunto de capacidades básicas. Un plugin es una pieza que alguien más —otro desarrollador, otra empresa— construyó para añadir algo que el agente no traía: una conexión a una base de datos particular, un formato de reporte específico, una forma de hablar con un sistema interno. Se instala una vez y, salvo que se configure lo contrario, se actualiza solo cuando su autor publica una versión nueva. Esa conveniencia —instalar una vez, dejar que se mantenga sola— es precisamente lo que Plugin4Shell convierte en punto de entrada.

Cómo funciona, sin tecnicismos

La huella digital de un plugin es, en el fondo, un nombre larguísimo y único que identifica una versión exacta del código. La herramienta la usa para pedir “dame precisamente esta versión, ni una letra distinta”. Lo que encontraron los investigadores es que, en tres de las cuatro herramientas, alguien que controla el repositorio del plugin puede crear un atajo — una rama — cuyo nombre se parece lo suficiente a esa huella como para que la herramienta tome el atajo en vez del código original. El atajo puede apuntar a cualquier cosa, incluido código malicioso, y la herramienta lo instala reportando que todo salió bien.

Gemini CLI tiene una variante propia del mismo problema, con un mecanismo distinto pero el mismo resultado: un atajo con un nombre reservado, pensado para apuntar siempre a lo último que se descargó, puede redirigirse para que apunte a contenido distinto del que efectivamente se pidió, sin que la herramienta lo note.

La parte que la vuelve zero-click —sin que nadie haga clic en nada— es que Claude Code y Codex actualizan sus plugins solos, en segundo plano, por diseño. Si el repositorio ya está comprometido antes de esa actualización automática, la máquina de cualquier persona del equipo puede terminar ejecutando el código alterado la siguiente vez que la herramienta revise si hay una versión nueva — sin que esa persona haya hecho nada distinto a lo de todos los días.

Quién ya tiene parche y quién no

Anthropic y OpenAI corrigieron la falla en sus herramientas después de la divulgación: Claude Code en la versión 2.1.179, Codex en la 0.146.0. Quien tenga una versión posterior a esas ya no debería ser vulnerable a este mecanismo específico.

GitHub Copilot y Gemini CLI seguían sin un parche de cliente confirmado al momento de escribir esto. Un vocero de GitHub declaró que “GitHub no permite que los usuarios creen nombres de rama o etiqueta que se parezcan a hashes de commit” y que “esta mitigación asegura que la vulnerabilidad reportada no se pueda explotar en GitHub”. Los investigadores de AIR Security disputan el alcance de esa respuesta: Copilot también admite mercados de plugins alojados en otras plataformas, como Bitbucket, donde esa protección de nombres no existe — así que la mitigación cierra un camino, pero no el problema de fondo.

La diferencia práctica entre “ya tiene parche” y “solo mitigado en un entorno” importa para decidir qué tan urgente es el paso 1 del checklist más abajo: si tu equipo usa Copilot con plugins que viven fuera de GitHub, o Gemini CLI con cualquier plugin de terceros, el nivel de urgencia es el mismo que si no hubiera respuesta alguna todavía.

Esa diferencia de opinión —entre “ya lo resolvimos” y “solo lo resolvieron a medias”— es exactamente el tipo de cosa que no deberías dar por sentada sin revisarla tú mismo. La sección de fuentes de esta pieza tiene los enlaces para que sigas el hilo con quien administre estas herramientas en tu equipo.

Vale también reconocer la parte que sí funcionó: los investigadores siguieron el proceso habitual de divulgación responsable, dando aviso a los cuatro proveedores antes de publicar el hallazgo, y dos de ellos —Anthropic y OpenAI— tuvieron parche listo para cuando la información se hizo pública. Eso es lo que se espera que pase cuando el sistema funciona bien. Que los otros dos todavía no lo tengan es la parte que queda pendiente, no una señal de que el proceso completo haya fallado.

Por qué esto no es un caso aislado

Los cuatro agentes afectados compiten entre sí, tienen equipos de ingeniería distintos y ni siquiera comparten el mismo lenguaje de programación en su código base. Lo que comparten es un supuesto de diseño: que una huella verificada es suficiente garantía, sin revisar también si el nombre que la acompaña podría confundirse con otra cosa. Ese tipo de supuesto compartido —no un error de una sola empresa— es lo que hace que una sola investigación tumbe a cuatro productos distintos el mismo día.

Para un negocio que apenas está incorporando agentes de código a su operación, la lección no es “desconfía de todo esto”. Es que un ecosistema de plugins de terceros trae los mismos riesgos que cualquier cadena de proveedores: conviene saber qué está instalado, quién lo aprobó y qué tan rápido se entera tu equipo cuando algo así se publica.

El paralelo más cercano es el de cualquier cadena de suministro de software: una pieza de código que nadie de tu equipo escribió, pero de la que tu operación termina dependiendo. Ese riesgo no lo inventó la inteligencia artificial —lleva años siendo uno de los puntos más débiles del desarrollo de software en general—, pero los agentes de código lo multiplican porque instalan y actualizan esas piezas más rápido y con menos supervisión humana en el camino que la que había cuando cada actualización pasaba por una persona revisándola a mano.

Eso no convierte a estas herramientas en algo que evitar. Las cuatro siguen siendo, hoy, más productivas que programar sin ayuda para la enorme mayoría de las tareas. Lo que cambia es que gobernar qué se instala y cómo se actualiza deja de ser un detalle de configuración y pasa a ser, igual que elegir con quién trabajas, una decisión de negocio.

Cuándo esto no te sirve

Si tu equipo no usa ninguna de las cuatro herramientas. Plugin4Shell es específico a Claude Code, Codex, GitHub Copilot y Gemini CLI. Si programas sin asistencia de IA, o con una herramienta distinta, esta falla en particular no te toca — aunque el hábito de revisar plugins de terceros sigue siendo bueno en general.

Si nunca instalas plugins de terceros. Usar solo lo que la herramienta trae por defecto, sin extensiones de otros desarrolladores, cierra buena parte de la puerta que esta falla necesita para abrirse.

Si ya actualizaste y ya revisaste el checklist. En ese punto, seguir esta noticia día a día deja de sumar. Vale más poner una fecha de revisión y volver entonces.

Si el desarrollo lo lleva por completo un proveedor externo. Cuando quien programa para tu negocio es una agencia o un freelancer, el checklist de esta pieza es una pregunta que le haces a esa persona, no una tarea que tú mismo ejecutas. Pedir la respuesta por escrito sigue siendo tuyo.

Qué hacer el lunes

Paso 1 (15 minutos). Pregunta en el equipo qué agente de código usa cada quien y en qué versión. Si nadie sabe la versión exacta, ese es el primer problema, antes que Plugin4Shell.

Paso 2 (20 minutos). Para Claude Code y Codex, confirma que la versión instalada sea igual o posterior a la que corrigió la falla. Para GitHub Copilot y Gemini CLI, revisa el aviso oficial más reciente del proveedor antes de asumir nada.

Paso 3 (10 minutos). Lista los plugins de terceros que tiene instalados cada persona. Cualquiera que nadie recuerde haber aprobado, se queda fuera hasta que alguien lo revise con calma.