Azure AI Foundry: un fallo de CVSS 10.0 por falta de autenticación

Qué era el CVE-2026-85889 y por qué puntúa 10,0

Microsoft corrigió en septiembre una vulnerabilidad en Azure AI Foundry, su plataforma empresarial para construir y gestionar aplicaciones y agentes de inteligencia artificial generativa, con la puntuación más alta posible: 10,0 sobre 10. El identificador es CVE-2026-85889 y el fallo consiste en la ausencia de autenticación en una función crítica de la plataforma, lo que permitía a un atacante no autenticado elevar privilegios a través de la red.

Por qué la ausencia de autenticación no es un fallo menor

La puntuación de 10,0 se reserva para vulnerabilidades que se pueden explotar de forma remota, sin autenticación y sin interacción del usuario, con impacto total sobre confidencialidad, integridad y disponibilidad. En este caso la causa concreta es menos espectacular de lo que sugiere el número: no hay un fallo de memoria ni una inyección sofisticada, sino una función crítica que no comprobaba quién la llamaba. Ese tipo de error es habitual en servicios que crecen rápido, y es exactamente el motivo por el que las plataformas de IA de los últimos dos años son un terreno nuevo para problemas viejos.

Los otros críticos corregidos en el mismo aviso

El investigador que reportó el fallo fue Rémy Marot. Microsoft publicó las correcciones y confirmó que las vulnerabilidades de servicios en la nube implicadas ya estaban completamente mitigadas en el lado del proveedor, por lo que no se requería ninguna acción por parte de los clientes. No hay indicios de que la vulnerabilidad se haya explotado en ataques reales.

Responsabilidad compartida: qué corrige el proveedor y qué te toca a ti

El aviso no venía solo. Microsoft corrigió otras vulnerabilidades críticas en el mismo movimiento: CVE-2026-85885 en Copilot, con 9,9; CVE-2026-85878 en Azure Database for PostgreSQL, también 9,9; y CVE-2026-87701 en Azure Cosmos DB, con 9,6. El patrón es claro y conviene entenderlo: varias puntuaciones cercanas al máximo, todas en servicios gestionados, todas corregidas sin que el cliente tenga que tocar nada.

Los fallos que se van a explotar no serán del fabricante

Ese último punto es el que más confunde a las empresas, y merece explicación. En un servicio en la nube gestionado, hay dos capas distintas de responsabilidad. La del proveedor cubre la infraestructura y el servicio en sí: eso es lo que Microsoft corrigió, y por eso no hubo acción requerida. La del cliente cubre lo que tú has construido encima, y esa sigue siendo tuya. Los fallos CVE resueltos por el proveedor no te libran de revisar tus propias configuraciones, tus claves, tus permisos y tus datos.

Cómo se revisa de verdad una integración de IA

En plataformas de IA el modelo de responsabilidad compartida tiene una complicación añadida. Un agente o una aplicación construida sobre Azure AI Foundry no es solo código: tiene acceso a datos de la empresa, puede ejecutar acciones y a menudo se le dan credenciales para que haga su trabajo. Cuando el proveedor corrige un fallo de autenticación, el servicio queda arreglado, pero los permisos que decidiste conceder siguen ahí. Un problema de exceso de privilegios no se corrige con un parche del fabricante.

Esto tiene una consecuencia práctica para cualquier empresa que esté desplegando IA con prisa. El fallo que corrigió Microsoft era de la plataforma, pero los que se van a explotar en los próximos dos años en este terreno serán, en su mayoría, de configuración del cliente: identidades de agente con más permisos de los que necesitan, claves de API embebidas en código que acaba en un repositorio, prompts que aceptan entrada de usuarios sin filtrar, y conectores que dan acceso a sistemas internos sin una revisión de por medio.

La revisión de una integración de IA se parece más a una auditoría de identidades y de diseño que a un escaneo de vulnerabilidades. Hay que mirar qué puede hacer el agente, con qué credenciales, sobre qué datos, quién puede hablarle y qué pasa si alguien lo convence de actuar en contra de las instrucciones. Ninguna de esas preguntas las responde un escáner automático, y todas ellas son las que acaban decidiendo si el despliegue es o no un problema.