Ocho fallos en los servidores MCP oficiales muestran dónde la herramienta excede el acceso del agente

Un desarrollador prueba un agente en local. El servidor MCP que usa corre sobre HTTP para que una segunda herramienta pueda alcanzarlo, y el shell del desarrollador guarda una clave de nube en una variable de entorno. En otra pestaña del navegador, el desarrollador abre una página web cualquiera. Hasta el 25 de octubre, si ese servidor era el paquete oficial server-everything, la página podía llamar a una herramienta que devuelve las variables de entorno del proceso y leer la clave.

Ningún modelo cometió un error en ese escenario. Las instrucciones, los permisos y los guardrails del agente eran irrelevantes. El propio servidor de herramientas era alcanzable por cualquiera que consiguiera que un navegador enviara una petición.

Ese caso es una de las ocho vulnerabilidades corregidas el 25 de octubre en la versión 2.1.0 del repositorio oficial de servidores del Model Context Protocol, en tres servidores de referencia: filesystem, everything y fetch. Ninguna está en la especificación de MCP. Todas están en la capa que convierte “el agente puede usar esta herramienta” en lo que la herramienta puede tocar de verdad.

Cada corrección restaura un límite que la herramienta debía sostener

Qué protegen las ocho correcciones

	Qué falló	Límite restaurado	Corregido en
filesystem (4 correcciones)	Enlaces simbólicos intercambiados que redirigían escrituras, una comprobación de ruta que recortaba comillas y espacios, enlaces simbólicos con variantes de mayúsculas, tamaños de archivo que se filtraban en los listados de directorio	Los directorios permitidos	2.0.1
everything (1 corrección)	Transportes HTTP y SSE abiertos a cualquier origen web, sin autenticación	La máquina del desarrollador y sus secretos	2.0.1
fetch (3 correcciones)	Nombre de host comprobado de una forma y conectado de otra, direcciones NAT64 que envolvían IP privadas, robots.txt omitido tras las redirecciones	La red interna y las reglas del sitio	2026.10.24

Filesystem es el servidor con más probabilidades de acabar copiado en agentes reales, porque leer y escribir archivos es lo primero que se quiere que haga un agente de código o de documentos. Sus cuatro correcciones giran todas en torno a la misma promesa: el agente trabaja dentro de los directorios que usted configuró y en ningún otro. Una es una condición de carrera en la que un directorio padre sustituido por un enlace simbólico podía enviar una escritura fuera de ellos. Los mantenedores advierten de que esta corrección solo es parcialmente eficaz en Windows y el aviso describe cómo configurar el entorno ante lo que queda. Otra era una comprobación que eliminaba una comilla o un espacio final, de modo que una carpeta hermana con un nombre parecido pasaba como permitida.

Everything es un servidor de pruebas que ejercita todas las funciones de MCP, y por eso tiene una herramienta que vuelca las variables de entorno. El problema no era esa herramienta; era que los transportes HTTP se vinculaban a todas las interfaces de red, aceptaban cualquier origen y no exigían autenticación. El transporte stdio por defecto no se vio afectado. El consejo del aviso (GHSA-mvf5-2qqv-rg3c) se generaliza mucho más allá de este paquete: no ejecute transportes HTTP con credenciales reales en el entorno.

Fetch recupera páginas web para un agente, lo que lo convierte en un riesgo clásico de server-side request forgery: el agente pide una URL y el servidor llega a un sitio al que el agente no debería llegar. Dos de sus correcciones cierran formas de alcanzar direcciones internas haciendo que la dirección comprobada difiera de la dirección a la que se conectó.

La ruta de actualización tiene una trampa

Los servidores TypeScript pasaron de versiones basadas en fechas (como la 2025.9.24) a versiones semánticas en la 1.0.0. Los gestores de paquetes sitúan la 2.0.1 por debajo de todas las versiones 2025.x y 2026.x, así que a un equipo que esté en una versión con fecha no se le ofrecerá la corrección. Tiene que instalar 2.0.1 de forma explícita. El servidor fetch, publicado en PyPI, está corregido en la 2026.10.24.

Esa trampa merece una búsqueda por repositorios, máquinas de desarrollo e imágenes de agentes esta semana, porque los servidores de referencia tienen la costumbre de acabar en producción. Están documentados, son fáciles de arrancar y suelen ser lo primero que usa un prototipo.

Dónde vive realmente el límite de un agente

Ya escribimos que MCP estandariza cómo se conectan los agentes a las herramientas, pero no las gobierna, y que un gateway puede bloquear las herramientas que llama un agente. Esta versión añade la capa de debajo: incluso una llamada a una herramienta permitida es solo tan segura como el servidor que la ejecuta. Un agente autorizado a escribir en /data/reports depende del servidor filesystem para que eso sea cierto. Un agente autorizado a recuperar páginas públicas depende del servidor fetch para que rechace las direcciones internas.

Para los equipos que ejecutan MCP en producción se plantean tres preguntas prácticas:

1. ¿Qué servidores MCP ejecutamos, en qué versiones y quién los actualiza? La mayoría de las organizaciones puede enumerar sus agentes. Pocas pueden enumerar los servidores que hay detrás.
2. ¿Qué hace cumplir el límite si el servidor falla? Un servidor filesystem dentro de un contenedor con solo el volumen permitido montado, o un servidor fetch en un segmento de red sin ruta a las direcciones internas, sobrevive al siguiente error de este tipo.
3. ¿Qué servidores escuchan en un puerto de red? Los servidores stdio heredan la seguridad del proceso que los arranca. Los servidores HTTP necesitan autenticación, comprobación de origen y una dirección de escucha elegida a propósito.

El agente decide qué herramienta llamar. El servidor de la herramienta decide a qué puede llegar esa llamada. Las revisiones de seguridad que se detienen en la primera decisión están revisando medio sistema.