La pila de agentes tiene un problema de 1998

En la última semana de junio de 2026 apareció un pequeño grupo de CVE contra las herramientas de agentes de IA, dos de ellas en el mismo cliente de agente de escritorio, ambas fallas de autorización, una alojada justo dentro de un callback OAuth de MCP. Leída por separado, cada una es una falla de severidad media que un mantenedor parchea en un fin de semana. Leídas juntas, el grupo es una señal, y la señal es estructural: el ecosistema de agentes de IA acumula superficie de ataque más rápido de lo que acumula la cultura de seguridad para defenderla. Eso no es una falta moral de ningún proyecto en particular. Es exactamente la condición en la que estaba la web alrededor de 1998, cuando un lenguaje se volvió masivo con valores predeterminados inseguros, las credenciales estaban en todas partes y la base instalada crecía más rápido de lo que cualquiera podía endurecerla. Las herramientas que guardan tus llaves y ejecutan tu shell se publican con una madurez de seguridad de 1998 frente a un modelo de amenazas de 2026.

TL;DR

• Cherry Studio, un popular cliente de escritorio para agentes de IA, recibió dos CVE el 29 de junio de 2026: una falla de autorización incorrecta en su servidor de callback OAuth de MCP (CVE-2026-13524) y una elusión de autorización en una API de precarga (CVE-2026-13534).¹²
• El patrón no es exclusivo de una aplicación. Las propias herramientas de referencia de MCP publicaron fallas críticas de ejecución remota de código en 2025: mcp-remote con CVSS 9,6 (CVE-2025-6514) y el MCP Inspector de Anthropic con CVSS 9,4 (CVE-2025-49596).³⁴
• Las herramientas de agentes están estructuralmente más expuestas de lo que jamás estuvieron las aplicaciones web: guardan credenciales, ejecutan código por diseño y se ubican dentro de tus fronteras de confianza (IDE, shell, navegador) en lugar de detrás de ellas.
• El conocimiento para prevenir estas fallas ya existe. La especificación de MCP documenta en detalle las clases de ataque del diputado confundido y del flujo OAuth; la cultura para aplicarlo en cada integración que avanza a toda velocidad todavía no se propaga.⁵
• La web de 1998 maduró solo después de que los gusanos volvieron cara la inseguridad. El ecosistema de agentes aún no tiene una función forzante equivalente, y los mismos modelos que hoy encuentran estas fallas pueden escribir la que llegue a serlo.

El grupo, en concreto

Cherry Studio es un cliente de escritorio multiplataforma que se promociona como un «estudio de productividad con IA, con chat inteligente, agentes autónomos y más de 300 asistentes», con soporte explícito para servidores de Model Context Protocol. Es justo el tipo de herramienta del que trata este ensayo: un agente orientado al consumidor que administra tus claves de API, ejecuta integraciones locales y sale a la red en tu nombre.

El 29 de junio de 2026, VulDB publicó dos avisos en su contra. CVE-2026-13524 es una falla de autorización incorrecta (CWE-285) en el MCP OAuth Local Callback Server, en src/main/services/mcp/oauth/callback.ts, en las versiones 1.9.0 a 1.9.6. El texto es directo: «La manipulación del argumento code conduce a una autorización incorrecta». Obtiene un CVSS 3.1 de 5,6, media.¹ CVE-2026-13534 es una elusión de autorización (CWE-639) en la API de precarga CherryIN, hasta la versión 1.9.7 inclusive, con una puntuación de 5,0.² Ninguna es un titular. Ambas son el error de autorización silencioso que comete un equipo al avanzar rápido sobre una superficie nueva para todos.

La primera es la señal reveladora. Un callback OAuth en un cliente MCP es una frontera de confianza de manual: el punto en el que un servidor de autorización externo devuelve un código a tu máquina y tu máquina decide si confiar en él. Manejarlo mal no es una clase de falla exótica y novedosa. Es aquella a la que el propio documento de seguridad de la especificación de MCP dedica más tinta.

Descarté dos CVE vecinas de la misma ventana, porque el grupo tiene que ser real: CVE-2026-13533 corresponde a agentejo Cockpit CMS, un gestor de contenidos en PHP y no un framework de agentes, y CVE-2026-13543 no pudo verificarse en absoluto. Unos pocos ejemplos sólidos valen más que una lista inflada.

Por qué las herramientas de agentes están estructuralmente peor

Una aplicación web clásica de 1998 era insegura, pero vivía detrás de una frontera. Corría en un servidor dentro del cual tú no estabas, su radio de daño era la base de datos y la sesión, y una brecha le daba al atacante los datos de la aplicación.

Una herramienta de agente invierte esa geometría. Corre en tu máquina o dentro de tu IDE, guarda credenciales de larga duración hacia tu nube y tus repositorios, y ejecuta código como función central en lugar de como exploit. No hay una frontera detrás de la cual ubicarse, porque la herramienta es la frontera, y es porosa por diseño.

Simon Willison nombró el peligro con precisión en junio de 2025 con el «trío letal» (lethal trifecta): un agente se vuelve explotable cuando combina «acceso a tus datos privados», «exposición a contenido no confiable» y «la capacidad de comunicarse hacia el exterior» de un modo que permite robar esos datos.⁷ Todo agente capaz tiene los tres por defecto, porque leer tus secretos, ingerir contenido influido por un atacante y hacer solicitudes salientes son sus funciones, no sus fallas. El trío no es un caso extremo. Es la configuración de partida.

Esa es la diferencia estructural. A la aplicación web de 1998 había que engañarla para que filtrara los datos de una sola frontera. El agente de 2026 llega precableado con todas las capacidades que necesita una cadena de exfiltración, y lo único que separa una entrada maliciosa de tus credenciales es si la herramienta trazó bien sus fronteras internas de confianza. La falla del callback de Cherry Studio es lo que se ve cuando una de esas fronteras queda trazada un poco mal.

La amplificación de MCP

Model Context Protocol es el tejido conectivo de la pila de agentes de 2026, y multiplica la superficie de una manera muy concreta: cada servidor MCP es una nueva integración privilegiada, casi siempre escrita a las apuradas, que el modelo puede invocar. Agregar uno no tiene fricción. Auditarlo, sí. La base instalada de integraciones le saca ventaja a la población de gente que lee su código.

Las herramientas de referencia demuestran que esto no es un problema de proyectos aficionados. En julio de 2025, JFrog reveló CVE-2025-6514, una inyección de comandos del sistema operativo en mcp-remote, un conector que usan Claude Desktop, Cursor y Windsurf, que un servidor malicioso dispara con una URL authorization_endpoint manipulada durante el flujo OAuth: crítica, CVSS 9,6.³ Ese mismo mes, Tenable reveló CVE-2025-49596, una falla de ejecución remota de código de 9,4 en el propio MCP Inspector de Anthropic, donde la ausencia de una verificación de autenticación permitía que un sitio web malicioso alcanzara un puerto local y, mediante rebinding de DNS, ejecutara comandos arbitrarios.⁴

Dos de las cuatro CVE de este ensayo son fallas del flujo OAuth en herramientas MCP: una en el servidor de callback, otra en el descubrimiento de endpoints. Eso no es coincidencia. OAuth en un cliente de agente es una frontera que se falla una y otra vez, y la especificación lo dice en voz alta. El documento «Security Best Practices» de MCP, fechado el 18 de junio de 2025, dedica su sección más larga al «problema del diputado confundido» (confused deputy) y exige que los servidores proxy implementen consentimiento por cliente, validen el parámetro OAuth state y hagan coincidir exactamente las URI de redirección.⁵ Eso se publicó un año antes de que Cherry Studio lanzara su falla de callback. La brecha no es de conocimiento. Es la distancia entre el apéndice de seguridad de una especificación y la integración mediana escrita el martes pasado.

El prompt injection vuelve la amplificación cualitativamente peor que cualquier cosa que enfrentara la web vieja. Willison acuñó el término en septiembre de 2022, al escribir «Propongo que el nombre obvio para esto debería ser prompt injection», por analogía con la inyección SQL: instrucciones confiables y entrada no confiable concatenadas en una sola cadena que luego un motor interpreta.⁶ Para un agente, los datos son un vector, no solo el código. Una página web envenenada, un archivo con trampa, la descripción hostil de una herramienta: cualquier byte que el modelo lea puede llevar una instrucción. La especificación de MCP es tajante al respecto y advierte que un servidor malicioso puede convertir al cliente en un intermediario para la exfiltración de datos.⁵ Eso no se parchea escapando la entrada, porque la entrada es lenguaje natural y el intérprete es un modelo.

La analogía de 1998, con precisión

La analogía tiene que sobrevivir a la verificación de datos o es apenas una sensación, así que aquí está la época, con exactitud.

PHP 3 salió en junio de 1998 y puso un lenguaje web dinámico en millones de manos con un valor predeterminado que hoy se lee como temerario: la entrada externa, proveniente de la cadena de consulta, las cookies o el servidor, se registraba directamente en el ámbito global. register_globals estaba activado, y una variable controlada por un atacante podía volverse en silencio una variable en la que tu código confiaba. La corrección tardó cuatro años. PHP 4.2.0, publicado en abril de 2002, cambió el valor predeterminado, y el anuncio de la versión lo dice sin rodeos: «Las variables externas (del entorno, la solicitud HTTP, las cookies o el servidor web) ya no se registran en el ámbito global de forma predeterminada».⁸ La otra muleta que definió la época, las magic quotes, aplicaba addslashes para fingir seguridad frente a la inyección SQL sin la sustancia, y sobrevivió años a register_globals antes de que el proyecto por fin la eliminara. Valores predeterminados inseguros, una ilusión de seguridad, un retraso de varios años hasta que la cultura se puso al día. Esa era la capa de aplicación de la web joven.

La cultura no llegó sola. Fue forzada. El 19 de julio de 2001, el gusano Code Red explotó un desbordamiento de búfer en el servidor web IIS de Microsoft y, según el conteo de CAIDA, «más de 359.000 computadoras fueron infectadas con el gusano Code-Red (CRv2) en menos de 14 horas».⁹ El 25 de enero de 2003, el gusano Sapphire/Slammer golpeó un desbordamiento de búfer en Microsoft SQL Server, se empaquetó en paquetes de 376 bytes e «infectó a la mayoría de los hosts vulnerables que podían encontrarse en menos de diez minutos», el gusano de propagación más rápida de la historia hasta ese momento.¹⁰ Aquellos fueron gusanos de infraestructura, no fallas de PHP, y no voy a mezclarlos. Lo que importa es la forma de la década: valores predeterminados inseguros en todas las capas, y una cultura de seguridad que maduró solo después de que la inseguridad se volvió visceral y públicamente cara. Lo seguro por defecto fue una lección que la industria pagó en gusanos.

Lleva eso a 2026 y la correspondencia incomoda. Valores predeterminados inseguros: clientes de agentes que confían en los códigos de callback y se saltan las verificaciones de consentimiento. La ilusión de seguridad: un aviso de permiso sobre un token con alcance admin:*. La base instalada que explota: un servidor MCP para todo, agregado con un clic, auditado por nadie. Lo que el ecosistema todavía no tiene es el gusano. Tiene los valores predeterminados de 1998 y el perfil de blanco de 2001, y está esperando su función forzante.

La postura del operador

No tienes el lujo de esperar a la cultura. Usas estas herramientas hoy, así que trazas las fronteras que el ecosistema todavía no trazó por ti. El marco que uso es el trío como lista de verificación operativa: para cualquier agente, pregunta qué puede leer, qué puede ejecutar y qué puede exfiltrar, y pon una barrera determinista en cada punto.

La columna de barreras no es aspiracional. Es determinista, y el determinismo es el punto. Los hooks se disparan en eventos del ciclo de vida con códigos de salida que el modelo no puede discutir, y las reglas de permiso se evalúan antes de que una herramienta corra, no después. Esa es la capa donde «el agente no debería hacer X» se convierte en «el agente no puede hacer X», y es la única capa a la que una carga de prompt injection no puede convencer con palabras. Cuando no puedes confiar en la entrada, y tampoco puedes confiar en que el modelo se vigile a sí mismo frente a esa entrada, aplicas la regla en la frontera que el modelo no controla.

Un segundo control se lee como una función de productividad, pero en realidad es de seguridad. Cuando un agente compila su trabajo en un plan revisable antes de ejecutarlo, revisar ese plan es una revisión de seguridad. Un script de flujo de trabajo de cuarenta líneas que nombra cada herramienta que llamará y cada archivo que tocará es un modelo de amenazas que lees en un minuto. No puedes auditar diez mil decisiones en vivo; sí puedes auditar el plan que las generaría, antes de que gaste nada.

Y mantén la asimetría a la vista: la misma capacidad que produce estas CVE también las encuentra. Un investigador de Anthropic usó un agente de código y un script de diez líneas para sacar a la luz una vulnerabilidad del kernel de Linux de 23 años de antigüedad y 22 CVE de Firefox. La herramienta que tienes en el escritorio es un escáner de vulnerabilidades apuntado a tu propia pila, si lo apuntas. Los defensores pueden automatizar el descubrimiento hoy y están construyendo la capa de triaje ahora mismo. Esa es la única ventaja que la web de 1998 no tuvo.

Actualización del 24 de agosto: el registro desde la publicación

Este artículo sostenía que el grupo de junio era una señal estructural, no mala suerte. Siete semanas de registro desde entonces:

La cola larga de MCP produce un flujo constante de CVE. En una sola semana de mediados de agosto, tres servidores MCP comunitarios recibieron CVE: inyección de código en el REPL de Python de Jij-MCP-Server (CVE-2026-19964), ejecución de comandos mediante manipulación de argumentos en android-mcp-server (CVE-2026-19978) y falsificación de solicitudes del lado del servidor en mcp-florence2 (CVE-2026-19984).¹¹¹²¹³ Todas de severidad media —dos activables de forma remota, la tercera local al host en el que corre el agente— y todas de las clases clásicas: inyección, exec sin sanear, SSRF, cayendo en herramientas que se ejecutan con los privilegios de un agente. Este es el escenario que la sección sobre la amplificación de MCP sostenía que era estructural —una cola larga de integraciones pequeñas, cada una un mcp-remote en potencia— y que ahora llega puntual.

No es solo la cola comunitaria. Azure SRE Agent —el agente de operaciones propio de Microsoft— recibió CVE-2026-62830 el 7 de agosto: autorización faltante que habilita una elevación de privilegios por red, puntuada como 9,9 crítica.¹⁴ El argumento estructural nunca trató sobre mantenedores aficionados; trata sobre lo que son las herramientas de agentes.

La investigación ofensiva alcanzó a la cadena de suministro. ElasticBack demostró una puerta trasera condicional plantada en un único documento de skill de agente, y presenta las skills como «una cadena de suministro emergente en la que una sola skill envenenada puede comprometer de forma persistente a todos los agentes que la instalan».¹⁵ Y la respuesta del ecosistema a la distribución, Agent Plugins 1.0, salió dejando los permisos y la procedencia en manos del cliente y sin ninguna capa de firma: la capa de empaquetado llegó antes que la de seguridad, el mismo orden que este artículo sostenía que define a toda la pila: primero se publica la capacidad, la cultura de seguridad viene rezagada.

El pronóstico de abajo queda sin editar.

La posición

Esto es lo que creo que va a pasar, lo bastante específico como para estar equivocado. El ecosistema de agentes tendrá su momento Code Red antes de tener su cultura de seguridad, porque ese es el orden en que la web lo hizo. La función forzante será con mayor probabilidad una carga de prompt injection autopropagada que se mueva entre agentes a través de servidores MCP compartidos, o un evento de exfiltración masiva de credenciales que se remonte a una sola integración popular y poco auditada. Será barata de construir, porque los mismos modelos que encuentran fallas de kernel pueden escribirla, y la advertencia de que «viene una gran ola» nunca fue solo sobre la defensa.

Después de que ocurra, lo seguro por defecto deja de ser opcional. Los clientes MCP saldrán con los diálogos de consentimiento activados por defecto, las audiencias de tokens validadas y callbacks que rechazan las URI de redirección que no coinciden, del mismo modo en que PHP terminó saliendo con register_globals desactivado. Las capas de permisos pasarán de opt-in a denegación por defecto. Las integraciones que sobrevivan serán las que trataron el apéndice de seguridad de la especificación como la especificación misma.

La parte incómoda es el calendario. A la web le llevó aproximadamente de 1998 a 2005 interiorizar lo seguro por defecto, con años entre gusanos para pensar. La pila de agentes se compone más rápido, con un blanco de mayor valor en la máquina de cada desarrollador y una cadena de herramientas de atacante que mejora con cada generación de modelos. El problema de 1998 es real. La única pregunta abierta es si actuamos sobre la analogía antes de que el gusano escriba el final, o después.

Conclusiones clave

• Aplica la auditoría del trío a cada agente. Anota qué puede leer, ejecutar y exfiltrar cada herramienta, y luego confirma que hay una barrera determinista en cada fila. Una capacidad sin barrera es tu exposición, y el lugar donde caerá la próxima carga.
• Pon los servidores MCP en lista de permitidos; trata cada parámetro de comando como ejecución no confiable. Agregar una integración es un clic y auditarla no lo es, así que restringe el registro a una lista revisada. Dos de las cuatro CVE de aquí fueron fallas del flujo OAuth en clientes MCP: el handshake es una frontera, no una formalidad.
• Convierte el momento del plan en la puerta de revisión. Haz que los agentes compilen su intención en un plan revisable y léelo como un modelo de amenazas antes de la ejecución. Un script que nombra sus herramientas y sus archivos se audita en un minuto; diez mil llamadas de herramientas en vivo, no.
• Apunta el escáner a ti primero. La capacidad que produce estas CVE también las encuentra. Corre barridos de seguridad asistidos por agentes sobre tu propio código y tus dependencias antes de que alguien más corra los suyos sobre ti.

Preguntas frecuentes

¿Son seguros los servidores MCP?

No por defecto, y no de manera uniforme. MCP es un protocolo; su seguridad depende de cómo lo implemente cada servidor y cada cliente. Las divulgaciones de 2025 contra mcp-remote (CVSS 9,6) y el MCP Inspector de Anthropic (CVSS 9,4) muestran que incluso las herramientas de referencia salieron con fallas críticas de RCE.³⁴ La especificación documenta las principales clases de ataque —diputado confundido, passthrough de tokens, SSRF, compromiso del servidor local— y prescribe mitigaciones concretas.⁵ Trata cada servidor como una integración privilegiada: corre solo los que consideras confiables o que auditaste, ponlos explícitamente en lista de permitidos y asume que cualquier servidor al que te conectes puede influir en tu agente.

¿Qué es el prompt injection?

El prompt injection ocurre cuando un atacante cuela instrucciones en la entrada no confiable que lee un sistema de IA, y el modelo las sigue como si vinieran de ti. Simon Willison acuñó el término en septiembre de 2022 por analogía con la inyección SQL: instrucciones confiables y entrada no confiable concatenadas en un mismo prompt que el modelo luego interpreta, sin forma fiable de distinguir qué parte era la del atacante.⁶ Para los agentes es especialmente peligroso porque los datos se vuelven un vector, y escapar caracteres no lo arregla porque el intérprete es un modelo de lenguaje.

¿Qué es el trío letal?

Es el nombre que Simon Willison dio, en junio de 2025, a las tres capacidades que juntas vuelven explotable a un agente: acceso a tus datos privados, exposición a contenido no confiable y la capacidad de comunicarse hacia el exterior.⁷ Un agente con las tres puede ser manipulado por contenido inyectado para leer tus secretos y enviárselos a un atacante. La mayoría de los agentes capaces tiene las tres por defecto, y por eso la jugada es proteger cada capacidad en vez de esperar que el modelo se resista.

¿Cómo aseguro un agente que se ejecuta en mi computadora?

Empieza por la frontera que el modelo no controla. Usa reglas de permiso y hooks que se evalúen antes de que una herramienta corra, para que un prompt comprometido no pueda hablar hasta llegar a una acción que prohibiste. Pon en lista de permitidos las herramientas y los servidores MCP, exige consentimiento antes de que se ejecute un nuevo servidor local, y dale a cada credencial el mínimo privilegio para que un token robado tenga un radio de daño pequeño. Bloquea las solicitudes salientes hacia rangos de IP privadas y link-local para cerrar la vía de exfiltración. Después revisa el plan del agente antes de las operaciones grandes, que es donde se atrapa la inyección que sobrevivió a la frontera de lectura.

Fuentes