La pila de agentes tiene un problema de 1998

En la última semana de junio de 2026, un pequeño grupo de CVE cayó sobre las herramientas de agentes de IA; dos de ellos en el mismo cliente de agente de escritorio, ambos fallos de autorización, y uno ubicado justo dentro de un callback OAuth de MCP. Leído por separado, cada uno es un bug de severidad media que un mantenedor parchea en un fin de semana. Leídos en conjunto, 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 un defecto 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 por todas partes y la base instalada crecía más rápido de lo que nadie podía fortalecerla. Las herramientas que guardan tus claves y ejecutan tu shell se lanzan con la madurez de seguridad de 1998 frente a un modelo de amenazas de 2026. {.answer-block}

TL;DR

• Cherry Studio, un popular cliente de agente de IA de escritorio, recibió dos CVE el 29 de junio de 2026: un fallo de autorización indebida en su servidor de callback OAuth de MCP (CVE-2026-13524) y un bypass de autorización en un API de precarga (CVE-2026-13534).¹²
• El patrón no se limita a una sola aplicación. Las propias herramientas de referencia de MCP lanzaron fallos críticos 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 sitúan dentro de tus límites de confianza (IDE, shell, navegador) en lugar de detrás de ellos.
• El conocimiento para prevenir estos bugs ya existe. La especificación de MCP documenta en detalle las clases de ataque de confused deputy y de flujo OAuth; la cultura para aplicarlo en cada integración de rápido movimiento aún no se propaga.⁵
• La web de 1998 maduró solo después de que los gusanos hicieran costosa la inseguridad. El ecosistema de agentes aún no tiene un detonante equivalente, y los mismos modelos que ahora encuentran estos bugs pueden escribir el que se convierta en él.

El grupo, en concreto

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

El 29 de junio de 2026, VulDB publicó dos avisos en su contra. CVE-2026-13524 es un fallo de autorización indebida (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 lenguaje es claro: “La manipulación del argumento code conduce a una autorización indebida.” Obtiene una puntuación de 5,6 en CVSS 3.1, media.¹ CVE-2026-13534 es un bypass de autorización (CWE-639) en el API de precarga de CherryIN, hasta la versión 1.9.7, con una puntuación de 5,0.² Ninguno es un titular. Ambos son el error silencioso de autorización que comete un equipo que avanza rápido sobre una superficie nueva para todos.

El primero es el indicio revelador. Un callback OAuth en un cliente de MCP es un límite de confianza de manual: el punto donde un servidor de autorización externo devuelve un code a tu máquina y tu máquina decide si confiar en él. Manejarlo mal no es una clase de bug nueva ni exótica. Es aquella a la que el propio documento de seguridad de la especificación de MCP dedica más tinta.

Descarté dos CVE vecinos de la misma ventana, porque el grupo tiene que ser real: CVE-2026-13533 es 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 en peor posición estructural

Una aplicación web clásica de alrededor de 1998 era insegura, pero vivía detrás de un límite. Se ejecutaba en un servidor dentro del cual tú no estabas, su radio de impacto 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. Se ejecuta en tu máquina o dentro de tu IDE, guarda credenciales de larga duración para tu nube y tus repos, y ejecuta código como una función central en lugar de como un exploit. No hay ningún límite detrás del cual resguardarse, porque la herramienta es el límite, y es poroso por diseño.

Simon Willison nombró el peligro con precisión en junio de 2025 con la “trifecta letal”: un agente se vuelve explotable cuando combina “el acceso a tus datos privados”, “la exposición a contenido no confiable” y “la capacidad de comunicarse externamente” de una forma que puede robar esos datos.⁷ Todo agente capaz tiene las tres por defecto, porque leer tus secretos, ingerir contenido influido por atacantes y hacer peticiones salientes son sus funciones, no sus fallos. La trifecta no es un caso límite. Es la configuración de base.

Esa es la diferencia estructural. A la aplicación web de 1998 había que engañarla para que filtrara los datos contenidos en un solo límite. El agente de 2026 llega precableado con todas las capacidades que necesita una cadena de exfiltración, y lo único que hay entre una entrada maliciosa y tus credenciales es si la herramienta trazó correctamente sus límites internos de confianza. El bug del callback de Cherry Studio es lo que se ve cuando uno de esos límites se traza un poco mal.

La amplificación de MCP

El Model Context Protocol es el tejido conectivo de la pila de agentes de 2026, y multiplica la superficie de una forma específica: cada servidor de MCP es una nueva integración privilegiada, normalmente escrita a toda prisa, que el modelo puede invocar. Añadir uno no tiene fricción; auditarlo, sí. La base instalada de integraciones está superando a la población de personas que leen su código.

Las herramientas de referencia muestran que esto no es un problema de proyectos de aficionados. En julio de 2025, JFrog reveló CVE-2025-6514, una inyección de comandos del sistema operativo en mcp-remote —un conector usado por 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, un fallo de ejecución remota de código de 9,4 en el propio MCP Inspector de Anthropic, donde una comprobación de autenticación ausente permitía que un sitio web malicioso alcanzara un puerto local y, mediante DNS rebinding, ejecutara comandos arbitrarios.⁴

Dos de los cuatro CVE de este ensayo son fallos de flujo OAuth en herramientas de MCP: uno en el servidor de callback, otro en el descubrimiento de endpoints. Eso no es una coincidencia. OAuth en un cliente de agente es un límite que se maneja mal una y otra vez, y la especificación lo dice en voz alta. El documento de mejores prácticas de seguridad de MCP, fechado el 18 de junio de 2025, dedica su sección más extensa al “problema del confused deputy”, y exige que los servidores proxy implementen consentimiento por cliente, validen el parámetro state de OAuth y hagan coincidir exactamente las URI de redirección.⁵ Eso se publicó un año antes de que Cherry Studio lanzara su bug 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 media escrita el martes pasado.

La inyección de prompts (prompt injection) hace que la amplificación sea cualitativamente peor que cualquier cosa a la que se enfrentó la web antigua. Willison acuñó el término en septiembre de 2022, cuando escribió “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 un motor luego interpreta.⁶ Para un agente, los datos son un vector, no solo el código. Una página web envenenada, un archivo con trampa, una descripción de herramienta hostil: cualquier byte que el modelo lea puede transportar una instrucción. La especificación de MCP es tajante al respecto, y advierte que un servidor malicioso puede convertir al cliente en un proxy para la exfiltración de datos.⁵ Eso no se puede parchear con escapado de entradas, 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 no es más que una impresión, así que aquí está la época, con exactitud.

PHP 3 se lanzó en junio de 1998 y puso un lenguaje web dinámico en manos de millones con un valor predeterminado que hoy se lee como temerario: la entrada externa —de la query string, 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 convertirse silenciosamente en una en la que tu código confiaba. La solució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 declara sin rodeos: “Las variables externas (del entorno, la petición HTTP, las cookies o el servidor web) ya no se registran en el ámbito global por defecto.”⁸ La otra muleta que definió la época, las magic quotes, ejecutaba addslashes para fingir seguridad frente a la inyección SQL sin la sustancia, y sobrevivió a register_globals durante años antes de que el proyecto finalmente la eliminara. Valores predeterminados inseguros, una ilusión de seguridad, un retraso de varios años antes de que la cultura se pusiera al día. Esa era la capa de aplicación de la web joven.

La cultura no llegó por sí 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 recuento 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 atacó 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 diez minutos”, el gusano de propagación más rápida de la historia hasta ese momento.¹⁰ Esos fueron gusanos de infraestructura, no bugs de PHP, y no voy a confundir ambas cosas. El punto 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 volviera visceral y públicamente costosa. La seguridad por defecto fue una lección que la industria pagó con gusanos.

Traslada eso a 2026 y la correspondencia resulta incómoda. Valores predeterminados inseguros: clientes de agente que confían en los códigos de callback y se saltan las comprobaciones de consentimiento. La ilusión de seguridad: un aviso de permiso sobre un token con alcance admin:*. La base instalada que explota: un servidor de MCP para todo, añadido con un clic, auditado por nadie. Lo que el ecosistema aún no tiene es el gusano. Tiene los valores predeterminados de 1998 y el perfil de objetivo de 2001, y está esperando su detonante.

La postura del operador

No puedes darte el lujo de esperar a la cultura. Ejecutas estas herramientas ahora, así que eres tú quien traza los límites que el ecosistema todavía no ha trazado por ti. El marco que uso es la trifecta como lista de verificación operativa: para cualquier agente, pregúntate qué puede leer, qué puede ejecutar y qué puede exfiltrar, y coloca una protección determinista sobre cada cosa.

La columna de protección no es aspiracional. Es determinista, y el determinismo es la clave. Los hooks se disparan en eventos del ciclo de vida con códigos de salida que el modelo no puede rebatir, y las reglas de permiso se evalúan antes de que una herramienta se ejecute, 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 que un payload de inyección de prompts no puede sortear con labia. Cuando no puedes confiar en la entrada, y no puedes confiar en que el modelo se vigile a sí mismo respecto a esa entrada, aplicas el control en el límite que el modelo no controla.

Un segundo control parece 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 no pierdas de vista la asimetría: la misma capacidad que produce estos CVE también los encuentra. Un investigador de Anthropic usó un agente de programación y un script de diez líneas para sacar a la luz una vulnerabilidad del kernel de Linux de 23 años y 22 CVE de Firefox. La herramienta que tienes en el escritorio es un escáner de vulnerabilidades apuntado a tu propia pila, si tú lo apuntas. Quienes defienden pueden automatizar el descubrimiento hoy y están construyendo la capa de triaje ahora. Esa es la única ventaja que la web de 1998 no tuvo.

La posición

Esto es lo que creo que 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 lo hizo la web. El detonante será, muy probablemente, un payload de inyección de prompts que se autopropaga y se mueve entre agentes a través de servidores de MCP compartidos, o un evento masivo de exfiltración de credenciales que se remonte a una sola integración popular y poco auditada. Será barato de construir, porque los mismos modelos que encuentran bugs de kernel pueden escribirlo, y la advertencia de “una gran ola en camino” nunca fue solo sobre la defensa.

Cuando eso ocurra, la seguridad por defecto deja de ser opcional. Los clientes de MCP se lanzarán con los diálogos de consentimiento activados por defecto, las audiencias de los tokens validadas, callbacks que rechazan las URI de redirección que no coinciden, del mismo modo que PHP terminó lanzándose con register_globals desactivado. Las capas de permisos pasan de ser opcionales a denegar 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 la cronología. La web tardó aproximadamente de 1998 a 2005 en interiorizar la seguridad por defecto, con años entre gusano y gusano para pensar. La pila de agentes se acumula más rápido, con un objetivo 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.

Puntos clave

• Haz la auditoría de la trifecta en cada agente. Anota qué puede leer, ejecutar y exfiltrar cada herramienta, y después confirma que hay una protección determinista en cada fila. Una capacidad sin protección es tu exposición, y el lugar donde aterriza el próximo payload.
• Usa listas de permitidos para los servidores de MCP; trata cada parámetro de comando como ejecución no confiable. Añadir una integración es un clic y auditarla no lo es, así que restringe el registro a una lista revisada. Dos de los cuatro CVE de aquí fueron bugs de flujo OAuth en clientes de MCP: el handshake es un límite, no una formalidad.
• Convierte la fase de planificación en el punto de revisión. Haz que los agentes compilen la intención en un plan revisable y léelo como un modelo de amenazas antes de ejecutar. Un script que nombra sus herramientas y archivos es auditable en un minuto; diez mil llamadas a herramientas en vivo no lo son.
• Apunta el escáner hacia ti primero. La capacidad que produce estos CVE también los encuentra. Haz barridos de seguridad asistidos por agentes sobre tu propio código y dependencias antes de que otro haga los suyos sobre ti.

Preguntas frecuentes

¿Son seguros los servidores de MCP?

No por defecto, y no de forma 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 lanzaron fallos críticos de RCE.³⁴ La especificación documenta las principales clases de ataque —confused deputy, token passthrough, SSRF, compromiso del servidor local— y prescribe mitigaciones concretas.⁵ Trata cada servidor como una integración privilegiada: ejecuta solo aquellos en los que confías o que hayas auditado, ponlos en una lista de permitidos de forma explícita y da por hecho que cualquier servidor al que te conectes puede influir en tu agente.

¿Qué es la inyección de prompts?

La inyección de prompts ocurre cuando un atacante cuela instrucciones dentro de 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 solo prompt que el modelo luego interpreta, sin una forma fiable de distinguir qué parte era la del atacante.⁶ Para los agentes es especialmente peligrosa porque los datos se convierten en un vector, y el escapado no puede arreglarlo porque el intérprete es un modelo de lenguaje.

¿Qué es la trifecta letal?

Es el nombre que dio Simon Willison, en junio de 2025, a las tres capacidades que juntas hacen que un agente sea explotable: el acceso a tus datos privados, la exposición a contenido no confiable y la capacidad de comunicarse externamente.⁷ Un agente con las tres puede ser manipulado por contenido inyectado para que lea tus secretos y se los envíe a un atacante. La mayoría de los agentes capaces tienen las tres por defecto, y por eso la jugada es proteger cada capacidad en lugar de esperar que el modelo resista.

¿Cómo aseguro un agente que se ejecuta en mi máquina?

Empieza por el límite que el modelo no controla. Usa reglas de permiso y hooks que se evalúen antes de que una herramienta se ejecute, para que un prompt comprometido no pueda abrirse paso con labia hasta una acción que prohibiste. Pon en listas de permitidos las herramientas y los servidores de MCP, exige consentimiento antes de que se ejecute un nuevo servidor local y asigna a cada credencial el mínimo privilegio para que un token robado tenga un radio de impacto pequeño. Bloquea las peticiones salientes a rangos de IP privados y link-local para cerrar la vía de exfiltración. Después, revisa el plan del agente antes de operaciones grandes, que es donde se atrapa la inyección que sobrevivió al límite de lectura.

Fuentes