MSTech Geeks

El 17 de septiembre de 2026, Microsoft parcheó en Azure AI Foundry una vulnerabilidad con la puntuación más alta que existe en el sistema CVSS: 10.0 sobre 10.0. No hiciste nada mal. No hay ningún parche que tuvieras que aplicar tú. Y aun así, si construyes agentes sobre esa plataforma, esto te incumbe más de lo que parece a primera vista.

Un CVSS 10.0 no es habitual. La escala está pensada para que casi nada llegue al máximo: hace falta que el fallo se pueda explotar remotamente, sin autenticación, sin interacción del usuario, y con impacto total sobre confidencialidad, integridad y disponibilidad. El CVE-2026-85889 cumplía las cuatro condiciones.

Qué pasó exactamente

El fallo, catalogado como CWE-306 (ausencia de autenticación en una función crítica), permitía a un atacante sin autenticar escalar privilegios sobre la red dentro de Microsoft Foundry. En cristiano: había una operación sensible de la plataforma que no comprobaba quién la estaba llamando.

Lo descubrió el investigador Rémy Marot, lo informó por el canal responsable de Microsoft, y Microsoft lo corrigió del lado del servidor antes de que hubiera prueba de explotación activa. Ningún cliente tuvo que instalar nada, cambiar configuración ni reiniciar un despliegue. El aviso oficial es explícito en ese punto: no se requiere ninguna acción del cliente.

Si te quedas solo con ese titular, el mensaje parece tranquilizador. Y en parte lo es. Pero hay una segunda lectura que me interesa más que la primera.

No fue un caso aislado de Foundry

El CVE-2026-85889 no llegó solo. Formó parte de un lote de dieciocho vulnerabilidades que Microsoft corrigió en el mismo ciclo de septiembre, y ahí está el dato que a mí me hizo prestar más atención ya que, junto a él, Microsoft parcheó también el CVE-2026-85917, un SSRF (server-side request forgery) dentro del mismoMicrosoft Foundry que igualmente permitía escalar privilegios sobre la red. Dos fallos graves, en el mismo producto, en el mismo ciclo.

Y el resto del lote tampoco era menor: un CVSS 9.9 por inyección de comandos en Microsoft 365 Copilot, un 9.9 más por autorización incorrecta en Azure Database for PostgreSQL, un 9.6 en Azure Cosmos DB. Septiembre de 2026 fue, en términos de superficie de ataque, un mes especialmente duro para la parte de la nube de Microsoft que sostiene IA generativa y agentes.

No lo cuento para generar alarma. Lo cuento porque cambia la pregunta que deberías hacerte. No es «¿tengo que preocuparme por este CVE en concreto?». Es «¿qué parte de mi arquitectura depende por completo de que estos parches lleguen a tiempo, y no tengo ninguna forma de comprobarlo yo mismo hasta que Microsoft publica el aviso?».

La trampa de «no se requiere ninguna acción del cliente»

Esta frase aparece en casi todos los avisos de seguridad de plataformas gestionadas, y normalmente es una buena noticia: significa que no vas a perder una tarde aplicando un parche urgente. Pero tiene una cara menos cómoda. Significa también que durante el tiempo que el fallo estuvo sin corregir, tu capacidad de mitigarlo por tu cuenta era literalmente cero. No había configuración que pudieras endurecer, ni WAF que pudieras ajustar, ni control propio que aplicar. La superficie vulnerable vivía enteramente del lado de Microsoft.

Esto es exactamente el modelo de responsabilidad compartida sobre el que ya escribí al hablar de seguridad en Microsoft Foundry, solo que visto desde el lado incómodo: hay una capa entera de tu stack de IA en la que tu única defensa es confiar en que el proveedor detecte y corrija antes de que alguien lo explote. Aquí funcionó así, con un investigador reportando de forma responsable y Microsoft parcheando en el servidor sin exposición conocida. La próxima vez, nadie te puede garantizar el mismo desenlace.

Lo que esto significa para tu Agent Control Plane

Hace poco hablaba del Agent Control Plane como la respuesta de Microsoft al gobierno de flotas enteras de agentes: identidad con Entra Agent ID, observabilidad y evaluación en Foundry Control Plane, políticas centralizadas en Agent 365. Un CVSS 10.0 justo en la plataforma que sostiene esas tres capas es el mejor caso de estudio posible de por qué ese control plane importa, y de dónde se le acaban las competencias.

Entra Agent ID resuelve quién es cada agente. Foundry Control Plane te da trazas y evaluaciones de lo que ese agente hace. Pero ninguna de las dos capas te protege de un fallo en la infraestructura que las sostiene a ambas. Ese nivel es, por diseño, responsabilidad de Microsoft, y aquí es donde entra la parte que sí depende de ti: cuánto puedes acortar el tiempo entre «algo raro pasó» y «me he enterado», aunque el origen del problema esté completamente fuera de tu control.

Si tienes las trazas de OpenTelemetry activadas en el Control Plane y las evaluaciones de seguridad configuradas como gate, no como simple tendencia, tienes una foto razonable de si algún agente tuyo tuvo un comportamiento anómalo durante la ventana en la que el fallo estuvo activo. Si no las tienes, ese CVSS 10.0 pasó y sigue sin poder decirte nada sobre si te afectó.

Qué hacer aunque técnicamente no tengas que hacer nada

No hace falta pánico ni un comité de crisis por un CVE que ya está cerrado. Pero sí merece una revisión corta, de las que caben en una tarde:

Revisa quién tenía asignado el rol de sponsor en tus identidades de Entra Agent ID durante la ventana de exposición, y confirma que sigue siendo la persona correcta. Comprueba en el Foundry Control Plane si hay trazas con patrones de acceso inusuales en las fechas relevantes, no solo errores evidentes. Y si todavía no tienes las evaluaciones de seguridad configuradas como gate de despliegue, este es tan buen momento como cualquier otro para dejar de posponerlo.

Ninguna de estas acciones habría evitado el CVE-2026-85889. Eso corría por cuenta de Microsoft, y lo resolvió antes de que trascendiera a explotación real. Pero la próxima vulnerabilidad de este calibre en algún componente de tu stack de IA es cuestión de cuándo, no de si, y la diferencia entre enterarte por un aviso oficial tranquilizador o por un incidente real la marca la visibilidad que ya tenías montada antes de que ocurriera.

El verdadero problema no es el CVE, es lo que sabes sobre ti mismo

Si trabajas bajo el marco de la AESIA o del Reglamento Europeo de IA en un sistema de alto riesgo, esta historia tiene una lectura adicional. «El proveedor de la nube tuvo un CVSS 10.0 y lo arregló solo» no es una respuesta válida si algún día tienes que justificar cómo gestionas el riesgo de tu sistema. Tienes que poder demostrar que sabías que el fallo existió, que revisaste si te afectó, y que tienes un proceso para hacerlo la próxima vez. Eso no te lo da la plataforma. Te lo tienes que construir tú, encima de ella.

El CVE-2026-85889 se cerró bien. Descubrimiento responsable, parche del lado del servidor, sin explotación conocida. Es, literalmente, el mejor escenario posible para una vulnerabilidad de máxima severidad. Y aun con ese final feliz, deja clarísimo que en un stack de IA gestionado hay una capa entera que nunca vas a controlar tú.

Lo único que sí puedes controlar es si, cuando algo así vuelva a pasar, tienes forma de saber en minutos si te tocó a ti.