CVE-2026-85889: la falla de CVSS 10 en Azure AI Foundry y las preguntas que debes hacerle a tu proveedor de IA

El 17 de septiembre de 2026 Microsoft publicó el aviso de CVE-2026-85889: una falla con la puntuación de severidad más alta que existe, CVSS 10.0, en Azure AI Foundry, la plataforma donde miles de empresas alojan sus modelos y agentes de IA. No había que aplicar ningún parche porque Microsoft ya había corregido el problema del lado del servidor antes de anunciarlo. Pero el aviso deja una pregunta incómoda para cualquiera que construya sobre una plataforma de IA gestionada: si la falla hubiera sido explotada antes de corregirse, ¿te habrías enterado?

Azure AI Foundry es el catálogo de modelos y el servicio de agentes de Microsoft: ahí se despliegan modelos, se conectan herramientas y corren los pipelines de inferencia para aplicaciones empresariales. Según la página oficial de producto, Foundry es usado por desarrolladores en más de 80.000 empresas, incluido el 80% de las compañías Fortune 500. Una falla de autenticación ahí no es un incidente aislado: es un problema en la capa donde conviven los proyectos de miles de clientes distintos.

Qué pasó exactamente

La causa técnica es CWE-306: falta de autenticación para una función crítica. En términos simples: una función del backend de Azure AI Foundry que debía exigir credenciales antes de ejecutar operaciones privilegiadas, no las exigía. Un atacante sin cuenta, sin clave de API y sin interacción de ninguna persona podía alcanzar esa función por red y escalar privilegios dentro del servicio.

Las características del fallo, confirmadas de forma consistente en varios análisis técnicos, son estas:

• Vector de ataque: red, sin necesidad de acceso previo a la infraestructura del cliente.
• Complejidad de explotación: baja.
• Privilegios requeridos: ninguno.
• Interacción del usuario: ninguna.
• Impacto: alto en confidencialidad, integridad y disponibilidad.

Esa combinación es la que empuja la puntuación a 10.0 en las notas que reportan thehackernews.com y la ficha técnica en VulDB, aunque algún análisis independiente calcula el vector CVSS en 9.8 según cómo interpreta el alcance del cambio de permisos; en cualquier caso, queda en el rango más alto posible de severidad. El hallazgo se acredita al investigador Rémy Marot, quien lo reportó a Microsoft por su proceso de divulgación responsable.

Microsoft confirmó que no hay evidencia de explotación activa antes de la corrección, y que la mitigación se aplicó enteramente en su infraestructura: no hay actualización que el cliente deba instalar, porque Azure AI Foundry es un servicio gestionado y el cambio ocurrió del lado de Microsoft. Esto es justo lo que distingue este caso de otras fallas críticas publicadas la misma semana en productos que sí corren en la infraestructura del cliente: aquí no hay nada que parchear en tu entorno, porque el entorno vulnerable nunca fue el tuyo.

Por qué esto no es "ya se arregló, a otra cosa"

El riesgo real de esta falla no es que siga abierta, porque no lo está. Es lo que revela sobre el tipo de daño posible en una plataforma de IA gestionada cuando la autenticación falla en el lugar equivocado. Según el análisis de la Cloud Security Alliance sobre esta escalada de privilegios, una brecha de autenticación en una plataforma multi-tenant como esta plantea una pregunta de fondo: ¿era técnicamente posible que un atacante cruzara de un proyecto a otro, es decir, que el aislamiento entre clientes distintos se rompiera? Microsoft no ha publicado ese detalle.

El mismo análisis señala tres cosas que un atacante con privilegios escalados en este tipo de plataforma podría hacer, si la ventana de exposición hubiera sido explotada: interferir con la configuración de modelos ya desplegados, acceder a datos de entrenamiento o de inferencia que pasan por el servicio, o manipular la lógica de orquestación que conecta esos modelos con las aplicaciones que los consumen. Ninguna de esas tres requiere que el atacante sepa nada de tu aplicación en particular: solo que alcance la función sin autenticar.

Es la diferencia entre una falla de seguridad en tu código y una falla de seguridad en la plataforma que corre tu código. En la primera, una auditoría de tu propio equipo la detecta. En la segunda, no puedes auditar lo que no operas: solo puedes preguntar y exigir evidencia.

Qué preguntarle a tu proveedor de plataforma de IA

Si tu empresa ya tiene procesos reales corriendo sobre Azure AI Foundry, AWS Bedrock, Vertex AI o cualquier plataforma gestionada equivalente, esta falla es la ocasión de hacer estas preguntas, no de esperar a la siguiente:

1. Aislamiento entre tenants. Pide que el proveedor confirme, por escrito, si un fallo de autenticación en su plano de control podría permitir que un proyecto alcance recursos de otro cliente. Es la pregunta que la Cloud Security Alliance identifica como material para cargas de trabajo reguladas.
2. Auditoría de acceso a artefactos de modelo. Quién puede leer o modificar un modelo desplegado, desde dónde, y si ese acceso queda registrado en un log que tú puedes consultar, no solo el proveedor.
3. Qué pasa si el pipeline de inferencia se manipula. Si alguien altera la configuración de un modelo en producción, ¿tu sistema lo detecta por comportamiento anómalo, o te enteras cuando el cliente final se queja?
4. Ventana de notificación. Qué compromiso contractual tiene el proveedor para avisarte si una falla de plano de control pudo haber afectado tu proyecto específico, no solo un aviso genérico de "ya lo arreglamos".
5. Segmentación de proyectos. Si trabajas con varios equipos o aplicaciones sobre la misma cuenta de la plataforma, revisa que cada proyecto tenga su propio alcance de datos y credenciales, para que un compromiso en uno no abra la puerta a los demás.

Ninguna de estas preguntas depende de que confíes menos en Microsoft. Depende de que el contrato y la arquitectura no asuman que la plataforma nunca va a fallar, porque esta semana quedó documentado que puede fallar con la peor puntuación posible.

Dónde esto no aplica

Si tu empresa usa IA generativa a través de una aplicación de consumo, como un asistente de oficina o un buscador con IA integrada, sin tocar directamente una plataforma como Azure AI Foundry, esta falla no te toca de forma directa: el riesgo vivía en la capa de infraestructura para quienes construyen y despliegan sus propios modelos y agentes ahí, no en el producto final que usa un empleado.

Tampoco es momento de migrar de proveedor de nube por esta falla en particular. Ningún proveedor grande de plataformas de IA está libre de haber tenido o de tener fallas de este tipo; lo que distingue a uno bueno de uno malo no es la ausencia de vulnerabilidades, sino la velocidad de mitigación y la transparencia del aviso, y en este caso Microsoft corrigió y publicó en un plazo razonable sin evidencia de explotación. Cambiar de plataforma por reacción, sin evaluar si la alternativa ofrece mejor aislamiento real, suele cambiar un riesgo ya medido por uno que todavía no se ha evaluado.

Donde sí vale la pena invertir es en el monitoreo propio que no depende del proveedor: alertas sobre cambios inesperados en la configuración de los modelos desplegados, revisión periódica de quién tiene acceso a qué proyecto, y un plan de respuesta que no dé por hecho que la plataforma te va a avisar primero. Si el pipeline de IA que corre en tu operación todavía no tiene esa capa de verificación independiente, esta falla es el argumento concreto para presupuestarla antes de que haga falta por otra razón.

Esto se cruza con un problema que ya tratamos antes: la brecha de gobernanza que nadie está presupuestando en empresas que ya construyeron agentes de IA de verdad. Y si el proveedor de nube entra en tu análisis de riesgo, conviene revisar también qué preguntar antes de firmar tu contrato de nube, aunque el motivo original de ese artículo fuera distinto al de hoy.

Nadie te va a avisar cuándo tu proveedor de IA tenga la siguiente falla de este tipo antes de corregirla. Una revisión de seguridad aplicada a tu operación de IA empieza por mapear qué preguntas de aislamiento y auditoría ya tienen respuesta y cuáles solo tienen una promesa de marketing.

Fuentes

• Microsoft Patches CVSS 10.0 Azure AI Foundry Flaw Enabling Unauthorized Privilege Escalation, The Hacker News
• Critical Microsoft Azure AI Foundry Vulnerability Allows Attackers to Escalate Privileges, Cybersecurity News
• Ficha técnica de CVE-2026-85889, VulDB
• Azure AI Foundry CVE-2026-85889: CVSS 10 Flaw Is Already Mitigated, AICybr
• CSA Research Note: Azure AI Foundry Privilege Escalation 2026, Cloud Security Alliance
• Microsoft Foundry, página oficial de producto