Microsoft corrige CVE-2026-85889 en Azure AI Foundry con CVSS 10.0

Microsoft ha publicado correcciones para una falla de seguridad de gravedad máxima en Azure AI Foundry —también conocido como Microsoft Foundry— que, según la compañía, podría permitir a un atacante escalar privilegios. El problema figura como CVE-2026-85889 y Microsoft le asignó una puntuación CVSS de 10.0. En su aviso oficial la empresa describe el fallo como una “falta de autenticación para una función crítica” que permitiría a un atacante no autenticado elevar privilegios a través de la red. La compañía acreditó al investigador Rémy Marot por el hallazgo y afirmó que, por el momento, no hay evidencias de explotación en entornos reales y que no se requiere acción por parte de los clientes porque la mitigación ya se ha desplegado en el servicio.

Qué ocurrió (hechos confirmados): Microsoft catalogó la vulnerabilidad como CVE-2026-85889 (CVSS 10.0) y la corrigió dentro de su plataforma administrada Azure AI Foundry. La corrección ha sido aplicada por Microsoft en el lado del servicio y la compañía indicó explícitamente que no requiere intervención del cliente. El hallazgo fue reportado por el investigador Rémy Marot. Microsoft también ha distribuido parches para varias otras vulnerabilidades críticas en productos cloud y en Windows, entre ellas CVE-2026-85885, CVE-2026-85878, CVE-2026-87701, así como dos vulnerabilidades locales en Windows tratadas en una actualización fuera de ciclo para Windows 11 versión 26H1 (KB5129194).

Cómo funciona técnicamente (explicación basada en la descripción oficial y estimaciones técnicas): la descripción “missing authentication for critical function” indica que existe una ruta de software —probablemente un endpoint de API o una interfaz de gestión interna— que realiza operaciones sensibles sin verificar la identidad o los permisos del solicitante. En plataformas de IA que gestionan modelos, agentes y despliegues, una operación crítica sin autenticación puede permitir acciones como modificar roles, implantar agentes con escalado de privilegios, ejecutar comandos administrativos o emitir tokens con privilegios elevados. Microsoft no ha publicado un exploit público ni detalles pormenorizados del vector exacto; por tanto, la cadena de ataque concreta (qué llamadas, qué parámetros, si se requiere acceso a la red interna o a una interfaz pública) sigue siendo información no confirmada y debe tratarse como estimación técnica.

En términos generales, una vulnerabilidad de este tipo en un servicio gestionado puede permitir a un atacante remoto tomar control de recursos del inquilino afectado (tenants) o manipular cargas de trabajo de IA si el endpoint es accesible desde redes externas o por medio de credenciales comprometidas. Dado que Microsoft afirma que la mitigación se aplicó en el servicio, la ventana de exposición debería ser corta para clientes que no operen instalaciones on‑premises del componente afectado.

A quién afecta: el vector impacta a organizaciones que usan Azure AI Foundry para construir, desplegar o gestionar aplicaciones generativas y agentes. Esto incluye empresas que hospedan modelos, pipelines y agentes orquestados por Foundry y que confían en sus controles de autenticación y autorización. El riesgo real depende de cómo cada cliente haya expuesto servicios y credenciales: entornos con endpoints públicos, políticas de permisos laxas o cuentas de servicio de alto privilegio tienen mayor probabilidad de impacto. Usuarios finales de aplicaciones construidas sobre Foundry no necesariamente están directamente en riesgo si las APIs críticas no fueron invocadas sin autenticación en sus despliegues concretos; no obstante, la posibilidad de acceso de un atacante a la infraestructura subyacente plantea riesgos para datos y procesos.

Consecuencias reales posibles: si la vulnerabilidad hubiese sido explotada antes del parche, un atacante podría haber obtenido privilegios administrativos en recursos gestionados por Foundry, modificar o exfiltrar modelos y datos, desplegar agentes maliciosos o pivotar dentro de la infraestructura cloud. Aunque Microsoft indica que no hay evidencia de explotación, las consecuencias teóricas justifican una revisión post‑evento: auditoría de accesos, verificación de integridad de modelos, y comprobación de despliegues recientes o cambios de configuración sospechosos.

Información confirmada frente a estimaciones e incertidumbres: confirmado — existencia de la CVE, parche aplicado por Microsoft, crédito al investigador y ausencia pública de explotación conocida; también confirmado que Microsoft parcheó otras vulnerabilidades críticas y emitió una actualización fuera de ciclo para Windows 11. Estimado — el mecanismo exacto del exploit (qué función concreta carecía de autenticación), el alcance detallado en cada tenant y si hubo intentos silenciosos de explotación antes del parche. No se deben asumir éxitos de explotación sin evidencia forense.

Qué debe hacer el lector ahora: aunque Microsoft indica que no es necesaria acción por parte de los clientes, hay medidas concretas y verificables que toda organización debería tomar para reducir riesgo residual y detectar actividad anómala. Primero, compruebe las comunicaciones y el centro de notificaciones de Azure para su inquilino y confírmelo con su representante de Microsoft o el administrador del tenant. Segundo, revise los registros de actividad y auditoría de Azure (Azure Activity Log, Azure AD sign‑in logs) en el período anterior y posterior al parche en busca de accesos inusuales, llamadas a APIs administrativas o tokens emitidos fuera de las ventanas normales. Tercero, rote credenciales y claves de servicio de alto privilegio asociadas a Foundry y minimice permisos de cuentas de servicio siguiendo el principio de menor privilegio. Cuarto, asegúrese de que sus soluciones de monitorización (Azure Sentinel, Defender for Cloud, SIEM) estén recolectando telemetría relevante y tenga alertas para creación de roles, concesiones de permisos y despliegues automatizados. Quinto, aplique la actualización fuera de ciclo de Windows 11 (KB5129194) a equipos afectados si mantiene estaciones o servidores con esa versión, y mantenga su programa de parcheo al día para evitar que fallos locales sean encadenados con fallos remotos.

Finalmente, documente y preserve logs en caso de que se requiera una investigación posterior y considere realizar un barrido de seguridad completo de los entornos de Foundry: revisión de modelos y artefactos, comparativa de integridad y verificación de pipelines de CI/CD. Si su organización sospecha que pudo haber sufrido algún compromiso relacionado, active el plan de respuesta a incidentes y contacte con soporte de Microsoft para coordinación forense.

Recursos útiles: para detalles y la notificación oficial consulte los canales de Microsoft Security Response Center y la página del servicio Azure; para seguimiento de amenazas vinculadas a explotación en Windows ver los análisis publicados por empresas de respuesta a amenazas. Más información en: Microsoft Security Response Center, Azure y el perfil del investigador en https://twitter.com/R_Marot. Para inteligencia sobre recientes campañas que usan cadenas de explotación sobre fallos de Windows, consulte a los equipos de investigación de amenazas como Proofpoint y Volexity.