Microsoft corrige una falla de CVSS 10.0 sin autenticación en Azure AI Foundry

El 17 de septiembre de 2026, Microsoft publicó CVE-2026-85889, la «Azure AI Foundry Elevation of Privilege Vulnerability», con una puntuación base CVSS v3.1 de 10.0. El aviso la clasifica como CWE-306, falta de autenticación para una función crítica: una función crítica dentro de Azure AI Foundry se distribuyó sin comprobación de autenticación, y un atacante en la red podía usarla para elevar privilegios sin credencial alguna.

Lectura relacionada: Microsoft planea triplicar sus centros de datos hasta 38 gigavatios en 2032 · SK Hyper cifra en 350.000 millones de dólares los primeros 5 gigavatios de su despliegue de IA.

El vector, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, está en su peor valor en cada métrica relevante. El ataque es alcanzable por red y de baja complejidad, no exige privilegios ni interacción del usuario, y conlleva impacto alto en confidencialidad, integridad y disponibilidad. El componente de alcance es el que más importa para evaluar el radio de daño. Un alcance modificado significa que el impacto cruza una frontera de seguridad en lugar de quedarse dentro de la propia cuenta del atacante, lo que en una nube multiinquilino apunta a la frontera entre los inquilinos y la propia plataforma.

Según Microsoft, la falla ya está corregida. El aviso afirma que se mitigó «por completo» del lado del servidor, que no hay ninguna acción para los usuarios del servicio y que la CVE se publicó por transparencia. No hay parche que descargar. Microsoft acreditó al investigador de seguridad Rémy Marot (@R_Marot) por el reporte, y la cobertura de The Hacker News señala que no hay evidencia de explotación en el mundo real. Como Azure AI Foundry es un servicio exclusivamente alojado, la corrección vivió y murió dentro de la infraestructura de Microsoft, invisible para los clientes.

La vulnerabilidad en términos sencillos

CWE-306 describe un error concreto y poco vistoso: una función que debería exigir un llamador autenticado acepta uno no autenticado. El fallo no es un truco de corrupción de memoria ni una cadena de configuraciones erróneas. Es la ausencia de un inicio de sesión donde correspondía uno.

La consecuencia se deriva directamente de lo que podía hacer la función desprotegida. En una falla de elevación de privilegios, la comprobación ausente permite a un llamador actuar como si tuviera permisos que nunca se le concedieron. Combinado con un vector de ataque de red y sin privilegios requeridos, la lectura práctica es que cualquiera que pudiera dirigir una petición al endpoint afectado podía alcanzar operaciones privilegiadas dentro de la plataforma. El alcance cambiado de la CVSS indica que esas operaciones no se limitaban a la frontera de autorización del atacante.

Por eso un 10.0 no es exageración aquí. Una puntuación de 10.0 se reserva para fallas que son remotamente alcanzables, trivialmente explotables y plenamente destructivas para la confidencialidad, integridad y disponibilidad del objetivo. La falta de autenticación en una función de control accesible por red cumple todo eso a la vez.

Por qué un plano de control de IA es una superficie de identidad de primer nivel

Azure AI Foundry es la plataforma empresarial de Microsoft para crear, desplegar y gobernar agentes y modelos de IA. Esa descripción subestima lo que es en términos de seguridad. Foundry es un plano de control. Orquesta otro código, aloja despliegues de modelos y datos de entrenamiento, y se conecta a fuentes de datos empresariales y sistemas posteriores mediante credenciales que los clientes configuran. Quien puede actuar dentro de ella puede actuar sobre muchas cosas que importan al negocio.

Una falla que concede acceso sin autenticación a una función privilegiada de Foundry es, por tanto, comparable a entregar a un atacante las llaves de un usuario privilegiado de la plataforma. El análisis de Mallory describe el alcance potencial sin rodeos: un atacante podría obtener capacidades comparables a las de un usuario privilegiado de Foundry, exponiendo o modificando potencialmente modelos de IA, datos de entrenamiento, recursos empresariales conectados y sistemas posteriores integrados con aplicaciones de Foundry.

Ese es el núcleo del argumento para tratar las API de gestión de IA como una superficie de identidad de primer nivel. Los equipos de identidad llevan años endureciendo los inicios de sesión humanos y, más recientemente, las cuentas de servicio y las identidades de carga de trabajo. Los planos de gestión más nuevos para IA son más jóvenes, a menudo tienen permisos amplios y permanentes sobre datos y cómputo, y con frecuencia están conectados a automatizaciones que pocas personas auditan a mano. Cuando una plataforma puede llamar a otros sistemas en su nombre, su propia autenticación es tan sensible como las credenciales que guarda.

La superficie de ataque también difiere de una aplicación tradicional. No hay perímetro que defender ni regla de firewall del lado del cliente que hubiera detenido una petición que llegara a un endpoint alojado por Microsoft. La función vulnerable era alcanzable por red por diseño, lo normal en una API en la nube, y la comprobación ausente era lo único que separaba a un llamador de operaciones privilegiadas.

Qué resuelve y qué no resuelve «totalmente mitigada, sin acción del cliente»

La frase es honesta y debe leerse por lo que es. Microsoft encontró el problema, lo corrigió en sus servidores y publicó la CVE para que el registro no guarde silencio ante una falla de severidad máxima. Esa es la transparencia para la que se diseñó el programa CVE, y es mejor que la alternativa de parchear en silencio y no decir nada.

Para el cliente medio, la consecuencia operativa es de verdad ligera. No hay nada que desplegar, ninguna versión que cotejar contra un inventario, ninguna ventana de mantenimiento. Un inquilino que no hace nada ya está operando contra el backend corregido.

Lo que la frase no resuelve es la verificación. Cuando un proveedor parchea software, un cliente puede confirmar la versión, ejecutar un escáner o comprobar un hash de compilación. Cuando un servicio alojado se corrige del lado del servidor, nada de eso está disponible. La única prueba del cliente es la palabra del proveedor y, si dispone de la telemetría, una revisión de lo que ocurrió en su cuenta antes y durante la ventana de remediación. Esa brecha no es una crítica a la respuesta de Microsoft. Es una propiedad estructural de consumir garantías de seguridad de un servicio que no se controla.

Hay un segundo límite. Microsoft ha divulgado pocos detalles técnicos sobre qué función se vio afectada o cómo era alcanzable la comprobación ausente. El aviso nombra la clase de debilidad y la puntuación, pero no el endpoint. Un informe de inteligencia de amenazas en threat.wiki y rastreadores independientes completan el vector y la lectura multiinquilino, pero el registro público aún no permite a un equipo externo reconstruir la falla. Sin ese detalle, el verdadero radio de daño no es plenamente cognoscible a partir del registro público, y nadie puede decir con precisión a qué habría podido llegar un atacante que usara la falla antes de la corrección.

La corrección le corresponde a Microsoft. La prueba de que nada ocurrió en su cuenta le corresponde a usted.

El patrón más amplio entre plataformas de IA

CVE-2026-85889 no llegó sola. Apareció en un lote de correcciones de alta severidad de Microsoft en torno al 16 y 17 de septiembre de 2026 que también incluyó una falla de inyección de comandos en M365 Copilot, CVE-2026-85885, puntuada 9.9; una falla de autorización en Azure Database for PostgreSQL, CVE-2026-85878, puntuada 9.9; y una falla en Azure Cosmos DB, CVE-2026-87701, puntuada 9.6. Los avisos de Microsoft de cada una afirman que se mitigaron del lado del servidor sin acción del cliente, y las entradas de Copilot y Cosmos DB repiten el enfoque de transparencia usado para la falla de Foundry. Una entrada separada de Microsoft en la misma ventana, la actualización de Windows 26H1 KB5129194, abordó un doble liberado en el Modo Kernel seguro, registrado como CVE-2026-85921. Ese último punto es una actualización convencional y no una corrección oculta en la nube, y los lectores deberían tomar el empaquetado de toda la lista como un encuadre, no como una única declaración de Microsoft.

El informe de inteligencia de amenazas sitúa CVE-2026-85889 en un patrón más estrecho: es la tercera falla de severidad casi máxima o máxima este mes en una plataforma cuya tarea es orquestar otro software, tras un 9.8 en Bifrost y un 9.8 en Orkes. Esa agrupación es el encuadre del informe, no una afirmación de Microsoft, pero apunta a algo real. Las herramientas que se sitúan en medio de una pila de software, orquestando modelos, agentes, flujos de trabajo y sistemas conectados, son exactamente donde un solo error de autenticación produce un radio de daño desproporcionado. Cuando se compromete el orquestador, todo lo posterior hereda el problema.

Es una clase de software joven. Los marcos de agentes, las pasarelas de modelos y las capas de orquestación han crecido rápido, y muchos fueron construidos por equipos cuya prioridad era la capacidad y la velocidad, no el endurecimiento que las plataformas más antiguas acumularon durante una década de escrutinio. La lección de la infraestructura tradicional, que los planos de control merecen las garantías de identidad más fuertes porque guardan las llaves de todo lo demás, aún no ha sido absorbida del todo por la ola de herramientas de IA. El lote de Microsoft recuerda que los mismos modos de fallo migran: falta de autorización, inyección de comandos, control de acceso inadecuado, todos reaparecen en sistemas nuevos.

Qué observar

Tres cosas marcarán cómo se recuerde este incidente.

La primera es si Microsoft publica más detalle técnico. Una clase de debilidad y una puntuación bastan para una entrada CVSS, pero no para que los defensores modelen su exposición. Si más adelante se describe la función afectada, los equipos podrán razonar si su automatización la tocó durante la ventana previa a la corrección. Hasta entonces, la posición honesta es que el registro público está incompleto.

La segunda es si la telemetría posterior a la corrección revela actividad inusual. Microsoft dice que no hay evidencia de explotación, y esa afirmación debe tomarse al pie de la letra. Aun así, una falla de red sin autenticación que existió durante un periodo desconocido antes de la divulgación es justo el caso para el que se pensó una revisión retrospectiva de registros. Las organizaciones que operan Foundry en producción deberían buscar llamadas privilegiadas anómalas a la API, asignaciones de roles inesperadas y conexiones nuevas a almacenes de datos o recursos externos.

La tercera es la dirección de la propia plataforma. A medida que más empresas ponen agentes a cargo de trabajo real, la postura de identidad y autorización de los planos de control que los ejecutan se vuelve una cuestión de gobernanza tanto como de seguridad. Los reguladores y auditores empiezan a preguntar quién aprobó a qué puede llegar un sistema de IA. Una brecha de autenticación de severidad máxima en una plataforma que orquesta ese acceso es el tipo de hallazgo que acelera esas conversaciones.

Para los lectores que siguen la seguridad en la nube, la instrucción práctica es pequeña y duradera. Trate el plano de gestión de IA como un nivel de identidad. Eso significa asignaciones de roles de mínimo privilegio, revisión de permisos permanentes, registro de operaciones privilegiadas y el hábito de revisar esos registros siempre que un proveedor anuncie una corrección del lado del servidor que usted no puede inspeccionar. La corrección le corresponde a Microsoft. La certeza de que no ocurrió nada en su cuenta le corresponde construirla a usted, y depende de registros que conserve antes de que llegue la divulgación.

Portada: «Microsoft Redmond Campus redevelopment aerial view, Sept. 2021» de Atomic Taco, vía Wikimedia Commons, con licencia CC BY-SA 2.0 (recortada a 16:9).