Fijar la versión del servidor MCP no fija lo que se ejecuta

Hay una frase que se dice mucho y que es falsa: «he fijado la versión del servidor MCP, así que ejecuto siempre el mismo código». El 10 de noviembre Corelight publicó el laboratorio que la desmonta, y el hallazgo es más incómodo que un simple «os habéis anclado mal». Midieron todos los servidores MCP que se lanzaban igual en un mismo puesto de trabajo y la conclusión está escrita sin anestesia: «It wasn't one server. Every MCP server which was launched in the same way on that workstation showed the same pattern, whether it was pinned to a release tag, an exact PyPI version, or an exact Git commit». Un servidor comunitario anclado a su etiqueta de release: 19 construcciones en cinco semanas, 15 entornos distintos y 23 de 69 paquetes cambiados de versión. Otro de ese mismo puesto, anclado a un commit: 19 construcciones, 17 entornos.

Escribimos esto con el matiz por delante: nosotros usamos agentes y servidores MCP, y los vamos a seguir usando. Esto no es un artículo de «la IA es peligrosa, no la toques». Es un artículo sobre una cosa mucho más aburrida y mucho más seria: que un servidor MCP es un proceso que se arranca en el puesto de alguien, con las credenciales de ese alguien, y que su código puede cambiar sin que nadie haya tocado una línea de configuración. Eso en cualquier otro contexto tendría un nombre y un procedimiento. Aquí todavía no.

El mito: «he puesto una versión»

La mecánica es simple de explicar y por eso duele. Los servidores MCP se arrancan casi siempre con un lanzador de un paso: npx en el mundo Node, uvx en el mundo Python. Tú escribes en la configuración del cliente algo del estilo uvx --from git+https://github.com/<owner>/<server>@<tag> <server> y te quedas tranquilo porque ahí hay una etiqueta. Lo que fija esa etiqueta es el paquete de arriba. Las dependencias de ese paquete —y las dependencias de sus dependencias— se vuelven a resolver contra el registro público en el momento del arranque. Corelight lo dice en una línea que conviene leer dos veces: «pinning a package's version doesn't necessarily pin the packages it depends on».

Y conviene decir que no fue por descuido del mantenedor, porque es la parte que más desarma. El autor del servidor comunitario había hecho justo lo que hay que hacer: fijó exactamente sus siete dependencias directas y publicó un fichero de bloqueo con hashes. Lo que pasó es que el lanzador instalaba desde las dependencias declaradas del paquete y no desde el fichero de bloqueo, así que los aproximadamente 60 paquetes de debajo se resolvían frescos contra PyPI en cada arranque. En el otro servidor, el anclado a commit, la deriva llegó al punto de que el marco de trabajo MCP sobre el que estaba construido corría dos versiones mayores por delante de la que figuraba en el fichero de bloqueo del propio proyecto. Anclaste la parte que se ve. La parte que se ejecuta iba por libre.

Los números, en una tabla

La última fila es la buena noticia y hay que decirla: congelar funciona. 457 arranques, misma lista de paquetes, cero sorpresas. Esto no es un problema sin solución; es un problema con una solución que casi nadie aplica porque la documentación de la que copias y pegas no la enseña.

No es un laboratorio: es lo que hay publicado

Un laboratorio es un laboratorio. Lo que lo convierte en un problema de sector es un censo del 13 de octubre de 2026 sobre 2.999 repositorios públicos de GitHub que publican habilidades de agente, manifiestos de plugin o configuración de servidor MCP. De ellos, 346 configuran un servidor MCP local. Y de esos 346, 159 (el 46,0 %) arrancan al menos uno sin versión fijada: 100 (28,9 %) lanzan un paquete npm vía npx sin versión exacta, 63 (18,2 %) piden directamente latest, y 38 (11,0 %) ejecutan un paquete Python sin versión. De propina, 2.459 de los 2.999 (82,0 %) no tienen SECURITY.md: no hay dónde avisar si encuentras algo.

Y aquí viene la parte que nos parece más reveladora, porque no es culpa de nadie en concreto y por eso nadie la arregla. Desde el 13 de octubre de 2026 hay una incidencia abierta en el repositorio de la propia especificación MCP señalando que la guía rápida oficial se contradice con la guía de seguridad oficial: los ejemplos de arranque usan npx -y sin versión, mientras que la guía Local Server Security dice textualmente «Install a specific version rather than latest». A fecha de hoy la incidencia sigue abierta, con acuerdo entre los participantes sobre qué hay que cambiar y sin cambio fusionado. El 18,2 % de repositorios que piden latest no se inventaron ese patrón: lo copiaron de donde tocaba copiarlo.

La deriva no es el problema. El permiso sí.

Que un entorno cambie de un día para otro, por sí solo, es una molestia de reproducibilidad. Lo que lo convierte en un asunto de seguridad es dónde vive ese proceso. Cuando un servidor MCP arranca, carga sus dependencias dentro del mismo proceso, y ese proceso lleva encima lo que lleve encima el usuario que lo lanzó: tokens de API, ficheros del usuario, rutas de red. La frase de Corelight es seca y es exacta: «An MCP server acts for a user, so it's often set up with that user's credentials and, as this workstation showed, an administrator's credentials reach a lot». Y el alcance no es hipotético: uno de los servidores que midieron era el MCP oficial de un fabricante de seguridad, añadido después, con permiso amplio de lectura y escritura sobre la plataforma de ese fabricante, y declaraba sus dependencias directas sin límite superior de versión.

Súmale la ventana. El mismo artículo recuerda que, en una de las oleadas de la campaña Shai-Hulud que alcanzó PyPI en junio de 2026 —«including MCP-themed packages», precisa el artículo—, se publicaron seis versiones maliciosas en menos de un minuto y se pusieron en cuarentena en treinta minutos. Media hora. Si tu puesto resuelve dependencias frescas 162 veces por semana, tu exposición no se mide en días de parcheo: se mide en si justo te tocó arrancar dentro de esa media hora. Esto ya lo hemos contado desde otro ángulo cuando un 10.0 llevaba el nombre de un producto y el fallo era de su intérprete: lo que te rompe casi nunca es el paquete que elegiste, sino el que vino detrás.

Y cuando uno de estos servidores tiene un agujero

Hay un caso con fecha y con número, y vale la pena contarlo entero porque enseña otra cosa. El 5 de noviembre de 2026 se publicó CVE-2026-123022 contra AgentScope: inyección de comandos del sistema en la llamada subprocess.Popen del fichero src/agentscope/mcp/_config.py, en el componente MCP Workspace API. El registro del CVE dice «hasta la 2.0.11» y lo puntúa en 7,3 (CVSS 3.1) y 6,9 (CVSS 4.0). El aviso original de quien lo reportó, publicado el 14 de octubre de 2026, habla de versiones ≤ 2.0.4 y lo puntúa en 9,8. Dos lecturas del mismo fallo con casi tres puntos de diferencia.

La diferencia de puntuación no nos interesa. Lo que nos interesa es por qué el aviso lo llama «no autenticado», y está escrito en el propio código: el extremo /workspace/mcp solo comprobaba que la cabecera X-User-ID no estuviera vacía, con un comentario que lo confiesa —«Temporary header-based identity; will be replaced by JWT auth»—. Es decir, mandas una petición con una cabecera que te inventas, metes /bin/sh en el campo command de una configuración MCP, y el servidor lanza el proceso. Y aquí es donde hay que ser preciso, porque es fácil dar esto por cerrado y no lo está: la propuesta de cambio 3448, abierta el 23 de octubre de 2026, añade una lista blanca opcional de comandos stdio que rechaza con un 403 lo que no encaje antes de lanzar el proceso. Sigue abierta, es opt-in, y su propio autor la marca como parcial —referencia la incidencia en lugar de cerrarla— porque no toca la autenticación por cabecera, que se trata en otro sitio. El aviso del investigador, por su parte, sigue registrando «Patched versions: None». La lección no es «AgentScope es malo»: la lección es que la pieza que levanta procesos estaba detrás de una autenticación que su propio autor había etiquetado como provisional, y que eso vivía dentro de la superficie que tú estás añadiendo a tu red.

Lo que hacemos nosotros, en orden

Nada de esto es exótico. Es el mismo trabajo que hacemos con cualquier otra cosa que se ejecuta en una red que gestionamos, aplicado a una pieza nueva que todavía no está en los procedimientos de casi nadie.

• Inventario primero, siempre. Qué servidores MCP se ejecutan, en qué puestos, lanzados por quién y con qué credenciales encima. Si la respuesta es «no lo sé», ese es el trabajo de esta semana y no el de la que viene.
• Instalación congelada por defecto. Fichero de bloqueo con hashes y el lanzador obligado a usarlo; npm ci en lugar de npx -y; en contenedor, imagen fijada por digest y no por etiqueta. Es la fila de 457 arranques con lista idéntica.
• Identidad propia para el agente. Cuenta separada, permisos acotados a lo que necesita y caducidad. El agente no trabaja con las credenciales del administrador porque le viene bien; trabaja con las suyas, que alcanzan menos.
• Solo lectura donde se pueda. La mayoría de servidores MCP que la gente usa a diario consultan más que escriben. Si el servidor admite modo de solo lectura, se activa.
• Mirarlo en la red, que es donde se ve. El propio artículo da la pista de detección y es buena: ráfagas de conexiones a GitHub, PyPI y npm desde puestos de trabajo, sesiones TLS cortísimas (de 0,1 a 1,5 segundos) y originadas por el asistente, no por un servicio programado. Eso sale en los registros de DNS y TLS que ya tienes.

Y el punto que más cuesta vender, porque es el que obliga a cambiar una costumbre: asume que lo que hay dentro del proceso ya se ha leído. Es exactamente el mismo razonamiento que aplicamos cuando escribimos que hay que dar por descifradas todas las variables de entorno de una plataforma que ejecuta tu código. Un servidor MCP es una plataforma que ejecuta código de terceros en el puesto de tu gente. Las reglas no cambian porque la pieza sea nueva y tenga buena prensa.

Cuándo NO hace falta nada de esto

Porque si no lo decimos, esto se lee como una venta de miedo. Si el servidor MCP corre en un portátil personal, contra un repositorio de juguete, sin credenciales de la empresa y sin ruta hacia ninguna red corporativa, congelar la instalación es ceremonia. Que corra con latest y que se actualice solo; es más cómodo y no estás arriesgando nada que importe. La línea que separa un caso del otro no es el tamaño de la empresa ni el entusiasmo por la IA: es si ese proceso tiene credenciales y alcance. En cuanto los tiene —una cuenta de administrador, un token de la nube, acceso a un repositorio de producción—, pasa a jugar en la liga del resto de software privilegiado y se le aplica lo mismo.

La pregunta incómoda

Si alguien de tu equipo te pidiera instalar en su puesto un programa que (a) se actualiza solo desde internet sin avisar, (b) corre con sus credenciales de administrador y (c) puede lanzar procesos, tendrías una conversación. Puede que acabaras diciendo que sí, pero habría conversación, y quedaría escrita. Eso es exactamente lo que ya está instalado, y en la mayoría de sitios entró sin conversación porque venía con la palabra «agente» delante. Que la respuesta siga siendo sí nos parece razonable. Que no haya habido conversación, no.

Nosotros llevamos esa conversación por escrito cuando montamos automatización e IA en una empresa: qué agente, qué servidor, qué credencial, qué alcance y quién lo revisa. Y el principio de debajo es el de siempre en Zero Trust: el agente no es una herramienta del administrador, es una identidad más, y como tal tiene su cuenta, su permiso mínimo y su registro. No vendemos ningún servidor MCP ni ningún modelo; montamos el perímetro alrededor.

Fuentes (consultadas el 11-11-2026): las cifras de deriva de entornos (19 construcciones / 15 y 17 entornos, 23 de 69 paquetes, 23 de 35 servidores, 162 y 457 arranques), las citas en inglés, la oleada de Shai-Hulud y la guía de detección en red son de «The Supply-Chain Risk Hiding in Your MCP Servers», de James Lagermann (Corelight), publicado el 10-11-2026. El censo de 2.999 repositorios públicos —346 con servidor MCP local, 159 sin versión fijada (46,0 %), 63 con latest (18,2 %), 2.459 sin SECURITY.md— es del estudio independiente agent-skills-state-2026, instantánea del 13-10-2026, con método y datos publicados bajo CC BY 4.0. La contradicción entre la guía rápida y la guía Local Server Security está en la incidencia 3431 del repositorio de la especificación MCP, abierta el 13-10-2026 y sin cambio fusionado a día de hoy. Aviso de procedencia: el censo y la incidencia 3431 son de la misma persona, así que cuentan como una fuente y no como dos que se corroboran. Los datos de AgentScope proceden del registro de CVE-2026-123022 (publicado el 05-11-2026, «hasta la 2.0.11», 7,3 en CVSS 3.1 y 6,9 en CVSS 4.0) y del aviso original del investigador del 14-10-2026 (≤ 2.0.4, 9,8, cabecera X-User-ID, «Patched versions: None»); la propuesta de cambio 3448 (23-10-2026) sigue abierta y es parcial. Donde dos fuentes no coinciden lo decimos, en vez de elegir la cifra que queda mejor. Foto de portada de Shixart1985, CC BY 2.0, vía Wikimedia Commons.