CVE-2026-32211: falta de autenticación en Azure MCP Server

¿Qué es esto?

El 2 de abril de 2026, Microsoft publicó CVE-2026-32211, una vulnerabilidad de divulgación de información en Azure MCP Server. La descripción, recogida en la ficha del NVD, es directa: «Missing authentication for critical function in Azure MCP Server allows an unauthorized attacker to disclose information over a network» (falta de autenticación en una función crítica que permite a un atacante no autorizado divulgar información por la red).

La debilidad subyacente se clasifica como CWE-306 — Missing Authentication for Critical Function. En términos llanos, una función que debía exigir que quien llama demostrara su identidad no lo hacía: una solicitud que llega al servidor por la red recupera datos que nunca debió ver. La herramienta MCP de Microsoft expone operaciones sobre recursos en la nube; un punto de acceso MCP que responde a cualquiera es exactamente la «función crítica» a la que se refiere CWE-306.

Esta entrada merece atención no por exótica —es lo contrario— sino por ser una instancia limpia, con nombre y confirmada por el fabricante de la forma más común en que fallan los despliegues de Model Context Protocol: quedan expuestos en una red sin ninguna autenticación por delante.

Cómo funciona

Aquí no hay un payload ingenioso, y deliberadamente no publicamos ninguno. El mecanismo radica en la ausencia de un control, no en la presencia de un truco:

1. Una función queda expuesta en la red. Azure MCP Server responde a solicitudes que devuelven información sobre el entorno al que está conectado.
2. Falta la comprobación de autenticación. Conforme a CWE-306, la función crítica no verifica la identidad de quien llama antes de actuar, de modo que una solicitud no autorizada (según el texto de la CVE) se atiende.
3. Regresa información. El atacante, que nunca se autenticó, recibe datos que la función debía proteger tras una credencial.

La puntuación cuenta algo útil sobre cómo leer una CVE. Microsoft, como autoridad de asignación (CNA), la valoró en 9,1 Crítica, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Los analistas del NVD discreparon en una dimensión y la valoraron en 7,5 Alta, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Ambos coinciden en que es accesible por red (AV:N), sin privilegios (PR:N) ni interacción (UI:N), y filtra confidencialidad (C:H). Difieren solo en la integridad: Microsoft asignó I:H, el NVD I:N. Cuando dos fuentes serias publican dos puntuaciones para el mismo fallo, no es un error que ignorar: es una invitación a leer el vector, no la cifra del titular.

Microsoft etiqueta el problema como una vulnerabilidad de «servicio alojado en exclusiva» (exclusively hosted service). En las convenciones de CVE de Microsoft, esto significa que el componente afectado se ejecuta en la nube de Microsoft y que la corrección se aplica del lado de Microsoft, sin parche que instalen los clientes —la CVE se publica por transparencia—. Eso no vuelve opcional la lección: quien opere un servidor MCP que sí controla hereda el mismo modo de fallo.

Por qué importa

Los servidores MCP se sitúan en un cruce peligroso. Están diseñados para dar a un agente LLM capacidades reales —leer tal recurso, consultar tal sistema—, lo que convierte a un punto de acceso MCP, por construcción, en una pasarela hacia datos y acciones. Coloque uno en una red sin autenticación y habrá construido una API abierta hacia todo lo que pueda alcanzar.

CVE-2026-32211 es un punto dentro de un patrón que este sitio sigue desde la primavera. Un estudio de mayo de 2026 sobre 7973 servidores MCP remotos activos halló que el 40,55 % exponía sus herramientas sin autenticación alguna, y que cada servidor con OAuth probado presentaba al menos un fallo (véase servidores MCP remotos: 40 % sin autenticación). El barrido a escala de Internet cuenta lo mismo del resto de la pila: el fallo recurrente son los valores por defecto permisivos, no bugs exóticos. Y el informe State of Agentic AI Security de OWASP de junio de 2026 sitúa la capa de protocolo y cadena de suministro en el centro, catalogando CVE en lugar de hipótesis. Cuando el propio servidor MCP oficial de Microsoft aterriza en esa lista, el argumento de «esto no le pasa a un fabricante serio» se desvanece.

El encuadre de «divulgación de información» también subestima el riesgo agéntico. Una fuga de solo lectura ya es mala, pero en una cadena de agentes ese mismo alcance no autenticado se convierte en el punto de apoyo que alimenta los pasos siguientes: combine acceso a datos, contenido no confiable y capacidad de actuar y volverá a la tríada letal.

Defensas

Trate cada servidor MCP —alojado o autogestionado— como un servicio autenticado y segmentado en red, nunca como una comodidad puesta en un puerto.

1. Autentique el servidor, no solo el modelo. Exija una identidad de llamante verificada (mTLS, OAuth con validación de tokens o una pasarela que la imponga) antes de ejecutar cualquier función de herramienta. CWE-306 se corrige añadiendo el control que faltaba.
2. No exponga MCP a redes que no lo necesitan. Enlácelo a localhost o a un segmento privado por defecto; coloque todo acceso remoto tras un reverse proxy que termine la autenticación. Esto coincide con las recomendaciones de mitigación de Microsoft para el caso alojado (restringir el acceso de red, situarlo tras un acceso autenticado).
3. Aplique el mínimo privilegio al alcance del servidor. Incluso autenticado, un servidor MCP solo debería tener credenciales acotadas a los recursos estrictamente necesarios para sus herramientas, para que un bypass filtre menos.
4. Inventaríe su superficie MCP. La mayoría de las organizaciones no sabe enumerar los puntos de acceso MCP que corren en su interior. Escanéelos como cualquier otro servicio expuesto y verifique en cada uno el requisito de autenticación —véanse las consideraciones de diseño MCP de la NSA.
5. Lea el vector, fije su propia gravedad. No deje que una sola cifra CVSS guíe el triaje. En CVE-2026-32211, la diferencia entre el 9,1 de Microsoft y el 7,5 del NVD es por completo la cuestión de la integridad: decida cuál se ajusta a su despliegue.

Situación

Elemento	Referencia	Fecha	Notas
CVE-2026-32211 publicada	Microsoft / NVD	2026-04-02	«Missing authentication for critical function in Azure MCP Server» (CWE-306)
Puntuación Microsoft (CNA)	Aviso MSRC	2026-04-02	9,1 Crítica — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Puntuación NVD	Análisis NVD	2026-04-06	7,5 Alta — C:H/I:N/A:N (difiere en la integridad)
Remediación	Convención CVE de Microsoft	—	Etiquetado «servicio alojado en exclusiva»; corrección del lado de Microsoft, sin parche para clientes
Contexto amplio	OWASP / escaneos arXiv	2026-05 a 06	~40 % de los servidores MCP remotos corren sin autenticación

La conclusión no es que Azure MCP Server fuera especialmente descuidado, sino que «despliega el punto de acceso MCP, añade la autenticación después» es un reflejo extendido en toda la industria, y CVE-2026-32211 es la versión de ese error con el nombre de un gran fabricante y un CVSS 9,1. Si opera MCP en algún sitio, la pregunta que zanjar hoy es simple: ¿cuál de sus servidores responderá a un desconocido?

Este artículo resume información de vulnerabilidad pública, divulgada por el fabricante, con fines defensivos y educativos. No reproduce código de explotación.