El SSRF de Azure MCP Server podría filtrar su token de identidad administrada a una URL

Microsoft publicó CVE-2026-26118 el 10 de marzo de 2026: una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF) en Azure MCP Server Tools, el paquete que permite a los agentes de IA y a los clientes MCP actuar sobre recursos de Azure en lenguaje natural. Un atacante que pueda interactuar con un agente respaldado por MCP podría enviar una URL maliciosa en lugar de un identificador normal de recurso de Azure; el servidor enviaría entonces una solicitud saliente a esa dirección y, en palabras de Microsoft, «podría incluir su token de identidad administrada», entregando al llamador una credencial que nunca debía ver. Microsoft le otorgó a la vulnerabilidad CVSS 8.8 y la calificó como Importante, y los paquetes que incluyen la corrección son 1.0.2 y 2.0.0-beta.17. El aviso no registra explotación ni divulgación pública antes del parche, y no se registra ningún daño real por ello. Este incidente es una entrada en el Orca AI Incident Archive, que contiene el registro completo con sus fuentes citadas, su calificación de gravedad y su evaluación de confianza.

Lo que realmente dice el aviso

El registro del Microsoft Security Response Center es escueto, y casi todos los detalles publicados sobre esta vulnerabilidad proceden de él o de las respuestas de Microsoft a un puñado de preguntas de seguimiento. La descripción completa: «La falsificación de solicitud del lado del servidor (SSRF) en Azure MCP Server permite a un atacante autorizado elevar privilegios a través de una red». El registro CVE reservó el identificador el 11 de febrero de 2026 y lo hizo público el 10 de marzo a las 14:00 UTC; la nota de publicación de Microsoft y la entrada de NVD indican ambos esa fecha. NVD analizó el registro y lo publicó a las 18:18 UTC esa misma tarde. El único aviso de un regulador encontrado para este artículo provino de Marruecos: la unidad maCERT de la DGSSI incluyó CVE-2026-26118 en un boletín fechado el 11 de marzo de 2026, en el que enumeraba Azure MCP Server Tools entre los productos afectados con su propio nivel de riesgo, Importante, sin una puntuación separada y con una referencia a la publicación de Microsoft.

La debilidad se asigna a CWE-918, falsificación de solicitudes del lado del servidor, y la clasificación de impacto es elevación de privilegios. La puntuación base de Microsoft es 8.8 en el vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, con una puntuación temporal de 7.7 en E:U/RL:O/RC:C — el componente E:U significa que Microsoft no conocía código de explotación cuando se estableció la puntuación, y RL:O significa que había una corrección oficial disponible. NVD mantiene la misma puntuación base y la clasifica como Alta; la propia escala de tres niveles de Microsoft la califica como Importante.

Dos campos importan tanto como la puntuación. El registro de Microsoft indica Explotado: No y Divulgado públicamente: No. El registro de decisión SSVC de CISA sobre la entrada de NVD, con marca temporal del 5 de marzo de 2026, coincide en cuanto a la explotación — ninguna — mientras que considera que el impacto técnico es total y automatizable no. El modelo FIRST EPSS situó la probabilidad de explotación en los próximos 30 días en aproximadamente el 1,0 %, en el percentil 62,8, en una extracción fechada el 3 de noviembre de 2026. Se trata de una vulnerabilidad que se encontró y se corrigió, no de una que se sepa que haya sido utilizada.

Cómo un identificador de recurso se convierte en una solicitud saliente

Azure MCP Server es la implementación de Microsoft del Model Context Protocol, la interfaz que los agentes de IA utilizan para llamar a herramientas. Sus herramientas toman los parámetros que un agente proporciona —el nombre de una cuenta de almacenamiento, un identificador de suscripción, el nombre de una base de datos— y los convierten en llamadas a los planos de administración y de datos de Azure. La documentación de Microsoft describe que el servidor se autentica mediante Entra ID usando “sus credenciales de usuario de Azure o una identidad administrada”, con el acceso delimitado por el control de acceso basado en roles de Azure.

El fallo se encuentra en el punto donde un parámetro que debería identificar un recurso de Azure se acepta, en su lugar, como una URL. La propia explicación de Microsoft: un atacante «podría explotar este problema enviando una entrada especialmente diseñada a una herramienta de Azure Model Context Protocol (MCP) Server que acepta parámetros proporcionados por el usuario. Si el atacante puede interactuar con el agente respaldado por MCP, puede enviar una URL maliciosa en lugar de un identificador de recurso de Azure normal». Después, el servidor envía la solicitud adonde se le indicó, en lugar de adonde la herramienta pretendía.

La parte que convierte una molestia en una escalada de privilegios es lo que viaja junto con ella. Microsoft afirma que la solicitud saliente «puede incluir su token de identidad administrada», lo que permite al atacante capturar dicho token «sin requerir acceso administrativo». Un token de identidad administrada es una credencial de portador: quien lo posea puede presentarlo a los servicios de Azure para los que esa identidad está autorizada, hasta que expire. La otra mitad atenuante del mismo párrafo es igual de importante: el atacante obtiene «los permisos asociados a la identidad administrada del servidor MCP» y, en palabras de Microsoft, «no obtiene permisos más amplios a nivel de inquilino o de administrador; solo aquellos vinculados a la identidad administrada comprometida». El radio de impacto es todo aquello que alguien haya concedido a esa identidad, lo cual en la práctica suele ser más de lo que necesitaba una sola herramienta.

Microsoft no nombra la herramienta ni el parámetro afectados, y ninguna de las fuentes revisadas para este artículo lo hace. Esa omisión es en sí misma un detalle: el aviso describe una clase de herramienta —una que acepta parámetros proporcionados por el usuario y puede ser inducida a acceder a una URL— en lugar de un único endpoint.

La corrección, y los paquetes que la incluían

Esto no fue una actualización de Windows. Azure MCP Server Tools se distribuyen como paquete NuGet para .NET, paquete npm y paquete de Python en PyPI, y la corrección consiste en actualizar la versión en la distribución que utilice cada implementación. El aviso de Microsoft enumera los rangos afectados: de 1.0.0 hasta 1.0.2, sin incluir esta última, y de 2.0.0-beta.1 hasta 2.0.0-beta.17, sin incluir esta última, en las distribuciones de NuGet, npm y PyPI.

Las fechas del registro de npm muestran que las compilaciones corregidas ya estaban en el registro antes del aviso. La versión 1.0.2 de @azure/mcp se publicó el 6 de marzo de 2026, cuatro días antes de que el CVE se hiciera público; la 2.0.0-beta.17 se publicó el 6 de febrero de 2026, cinco días antes de que Microsoft reservara el identificador del CVE y un mes antes de que apareciera el aviso. Cualquiera que haya sido la secuencia dentro de Microsoft, el código parcheado no se escribió en respuesta al día de la publicación. NVD y la base de datos de avisos de GitHub coinciden en esos límites superiores. Discrepan ligeramente en el extremo inferior del rango de PyPI —NVD indica 2.0.0-beta.1 y el aviso de GitHub indica 2.0.0b14—, una discrepancia que ambos registros arrastran desde la publicación y que solo afecta hasta dónde debe remontarse una implementación de Python.

El propio aviso se revisó el 20 de marzo de 2026, diez días después de su publicación, con una nota en la que se indicaba que Microsoft había «añadido a la tabla de actualizaciones de seguridad productos que documentan los distintos métodos de empaquetado utilizados para distribuir Azure MCP Server Tools». En otras palabras, la primera versión del aviso nombraba el producto, pero no todos los canales por los que se distribuía, lo cual importa cuando la remediación consiste en «actualizar el paquete» y no en «instalar esta KB».

Qué no está establecido

¿Quién lo encontró? Ni el aviso de Microsoft ni el registro de CVE.org mencionan a quien lo reportó; el campo de créditos del CVE está vacío. Eso no prueba que no se haya reconocido a alguien en privado, solo que no existe un reconocimiento público.

Ninguna explotación. Microsoft no registra ninguna, la evaluación SSVC de CISA coincide, y ninguna de las fuentes revisadas para este artículo describe una identidad comprometida en el mundo real. El campo de daño real del registro es falso, lo cual es coherente con ello. Un EPSS bajo es una previsión, no un hallazgo, y la ausencia de un incidente reportado no es prueba de que no haya ocurrido ninguno.

Si existe un exploit público. Aquí es donde la cobertura secundaria se divide. Una publicación de marzo de 2026 en el blog de Blueinfy afirma que existen “exploits de prueba de concepto públicos, como los de GitHub” y advierte de una “rápida armamentización”, pero no proporciona enlace, carga útil ni guía paso a paso, y no demuestra la vulnerabilidad. El registro de Microsoft indica que la vulnerabilidad no se divulgó públicamente antes del parche. Una búsqueda en repositorios de GitHub del identificador CVE el 4 de noviembre de 2026 devolvió un repositorio —un laboratorio de detección de Microsoft Sentinel publicado el 17 de marzo de 2026, no un exploit—, y la página de vulnerabilidad de Mallory afirma que se examinaron y rechazaron dos exploits candidatos. La afirmación de que hay código de exploit público funcional no está respaldada, según las pruebas disponibles; la afirmación de que nadie lo ha intentado tampoco está probada.

El encuadre. Una página de PolicyLayer, un sitio de resúmenes de incidentes de un proveedor, reencuadra CVE-2026-26118 como una cadena de ejecución remota de código no autenticada que culmina en la toma total del inquilino, atribuyéndola a un investigador nombrado y a una demostración en RSAC 2026. Las propias fuentes citadas en esa página llevan títulos de SSRF, sus fechas no concuerdan con la cronología del CVE, y ni el aviso de Microsoft ni la cobertura de SecurityWeek del 10 de marzo describen ejecución de código. Este artículo trata la versión de SSRF y token como la establecida y no repite el encuadre de RCE.

Por qué el token, y no la solicitud, es el hallazgo

La falsificación de solicitudes del lado del servidor es una de las clases de vulnerabilidades más antiguas del software web y, por sí sola, suele ser una forma de alcanzar sistemas a los que el atacante no puede dirigirse directamente. Lo que hace que este registro merezca conservarse es la credencial adjunta a la solicitud. El servidor MCP es un delegado confundido por diseño: posee una identidad para que un agente pueda actuar en nombre de un usuario y, desde el punto de vista del servidor, cada parámetro que pasa un agente es texto influenciado por el atacante. Cuando uno de esos parámetros se convierte en un destino en lugar de un nombre, el delegado lleva su propia autorización al destino.

La documentación de Microsoft precisa dónde se concentra ese riesgo. Describe el servidor local como “destinado estrictamente al uso de desarrolladores dentro de su organización”, mientras que, por separado, publica guías de implementación para servidores remotos autoalojados en Microsoft Foundry y Copilot Studio — las configuraciones en las que una identidad administrada, en lugar del propio inicio de sesión de un desarrollador, suele ser la credencial en juego. La ruta de robo de tokens del aviso se refiere específicamente a la identidad administrada. No afirma que todas las instalaciones hayan estado expuestas, ni dice cuántas lo estuvieron.

La lección general es la que el Estándar de Verificación de Seguridad de IA de OWASP ahora utiliza este caso para enseñar. El capítulo de orquestación de AISVS cita CVE-2026-26118 entre sus ejemplos prácticos y extrae la conclusión de que “los parámetros de las herramientas MCP deben tratarse como controlados por el atacante, y las solicitudes salientes de los servidores MCP deben pasar por las mismas políticas de egreso y origen que se esperan de cualquier otra E/S impulsada por agentes”. Esa es una recomendación de control, no un hallazgo sobre este incidente, pero es la respuesta más concreta que alguien haya publicado a la pregunta de qué debería cambiar.

¿Qué cambió después?

Tres cosas, y ninguna de ellas es dramática. Microsoft distribuyó paquetes corregidos en los tres ecosistemas y revisó el aviso para nombrarlos. El ecosistema de inteligencia de vulnerabilidades lo absorbió sin estridencias: una puntuación EPSS baja y un registro del NVD modificado por última vez el 17 de junio de 2026. Y la comunidad de estándares lo adoptó como caso didáctico, lo que constituye una forma de respuesta más lenta y duradera que un parche.

Para quien todavía esté ejecutando una compilación afectada, la remediación no ha cambiado y no tiene nada de glamorosa: actualice a 1.0.2 o posterior en la línea estable, o a 2.0.0-beta.17 o posterior en la línea de vista previa, en todos los gestores de paquetes que el despliegue utilice. Más allá de eso, la lógica del propio aviso implica tres controles: restringir a qué destinos puede acceder el servidor hacia el exterior, asignar a la identidad administrada solo los roles que sus herramientas realmente necesitan y tratar cualquier parámetro de herramienta que pueda convertirse en una URL como entrada hostil. Ninguno de ellos es necesario para haber sobrevivido a CVE-2026-26118. Cada uno reduciría el valor que el siguiente tendría para un atacante.

Cómo clasifica el archivo este elemento

El registro está archivado como una vulnerabilidad —algo encontrado, no algo que se sepa que haya sido explotado—, con una calificación de confianza A, lo que significa que está bien documentada y que las fuentes primarias concuerdan, y no está marcado como disputado. Su campo de daño real es falso y su participación de IA está confirmada, porque el producto afectado es el puente entre un agente de IA y un plano de control en la nube, en lugar de un servicio de propósito general que casualmente se encuentre cerca. La fecha está registrada con precisión de día, el 10 de marzo de 2026, sin fecha de finalización, porque se trata de un único punto en el tiempo y no de una campaña. La región es global y el indicador de hito es falso.

Un campo se lee de forma distinta a la puntuación publicada. La severidad del archivo se registra como media, en su propia escala; el número que publican tanto Microsoft como NVD es 8.8, al que Microsoft denomina Important y NVD clasifica como High. El resumen del registro comienza con ese 8.8, y la discrepancia es una diferencia de categorización, no de hechos.

Lo que el registro no puede transmitir es cuánto de esta historia es una ausencia. Hay un fallo que entrega una identidad en la nube a quien la pida con la forma incorrecta. Hay una corrección, publicada antes del anuncio. No hay descubridor acreditado, ni herramienta nombrada, ni explotación confirmada, ni forma de que un externo sepa si alguna implementación alojada llegó a ejecutar una compilación vulnerable mientras tenía una identidad poderosa. El aviso es preciso sobre lo que hace el fallo y guarda silencio sobre casi todo lo demás, y ese silencio es lo más útil que se puede observar al respecto.