El 17 de septiembre de 2026, Microsoft publicó una corrección fuera de ciclo para una vulnerabilidad en Azure AI Foundry, la plataforma empresarial que miles de compañías usan para construir, desplegar y gobernar aplicaciones y agentes de IA generativa. La severidad es CVSS 10.0, la máxima. La descripción es una sola frase, y conviene leerla despacio: autenticación ausente en una función crítica.
Traducido del idioma de proveedor: un atacante no autenticado en la red podía alcanzar una función crítica de la plataforma sin iniciar sesión y usarla para elevar privilegios. Sin credencial. Sin phishing. Sin interacción del usuario. Solo un endpoint accesible y una comprobación que faltaba.
Microsoft afirma que no hay evidencia de explotación de CVE-2026-85889 en el mundo real y que ya está mitigada por completo del lado del servidor, sin necesidad de acción del cliente. Ambas cosas son casi con seguridad ciertas. Ninguna de las dos es lo interesante.
Lo que Microsoft reveló en realidad
CVE-2026-85889 no llegó sola. En la misma ventana, Microsoft corrigió un racimo de fallas críticas en su ecosistema de nube:
- CVE-2026-85885 (CVSS 9.9): inyección de comandos en Microsoft 365 Copilot, con elevación de privilegios por red.
- CVE-2026-85878 (CVSS 9.9): autorización incorrecta en Azure Database for PostgreSQL, mismo resultado de escalada.
- CVE-2026-87701 (CVSS 9.6): neutralización incorrecta en Azure Cosmos DB, también con escalada de privilegios.
- CVE-2026-69843 y CVE-2026-62874: fallas de severidad máxima en Microsoft Fabric y Azure Billing, ambas con 10.0 según rastreadores independientes.
Esa misma semana, Microsoft cerró un récord de 974 vulnerabilidades en su portafolio durante el Patch Tuesday de septiembre, dos de ellas ya explotadas activamente. Investigadores han encadenado una de ellas, una falla de ALPC en Windows, en un kit de explotación llamado BlueMoon que varios grupos de espionaje usaron junto a dos zero-days de Chrome.
Lee esa lista como una forma, no como incidentes sueltos. Los 10.0 y los 9.9 no están repartidos por el software de escritorio. Se concentran en nubes, plataformas de datos y servicios de IA. Ahí se movió la superficie de ataque empresarial, y ahí aparecen los hallazgos críticos.
"Sin acción del cliente" no significa "sin trabajo del cliente"
La frase significa que el proveedor arregló el servidor que alquilas. No dice nada sobre las consecuencias de tu lado, y ahí es donde la mayoría de los equipos deja de leer.
Una elevación de privilegios sin autenticación en una plataforma de IA es un problema de plano de control. Azure AI Foundry no es un chatbot en una pestaña. Es el lugar donde se despliegan los modelos, donde viven los prompts y los datos de evaluación, donde se conectan las fuentes de datos, donde se definen las identidades de los agentes y los permisos de sus herramientas. Según cómo esté configurado tu tenant, llegar a esa capa puede significar llegar a tus cuentas de almacenamiento, tu Key Vault, tus despliegues de Azure OpenAI o los service principals que sostienen el resto de tu entorno.
"Ya mitigado" responde a la pregunta del proveedor. No responde a la tuya: ¿qué habría expuesto en tu entorno una breve ventana de acceso sin autenticación a esa capa?
Tu plataforma de IA es un plano de control. Trátala como tal
Durante una década hemos tratado los planos de control de IAM, CI/CD y Kubernetes como sistemas Tier-0: revisión de accesos privilegiados, registro de cambios, restricciones de red, procedimientos de emergencia. Las plataformas de IA han crecido hasta esa categoría mientras se gobernaban, en la mayoría de los casos, como un espacio de proyecto.
Esa es la brecha que este aviso debería cerrar. Tres consecuencias prácticas:
- Primero, inventario. No puedes razonar sobre el radio de impacto si no sabes qué tenants, suscripciones y servicios de IA operas. La mayoría de las organizaciones que vemos levantan servicios de IA más rápido de lo que se actualiza su inventario.
- Dibuja el mapa de identidades. Para cada plataforma de IA, lista cada identidad gestionada, service principal y conexión que puede asumir, y cada almacén de datos que puede leer. El radio de impacto no es la plataforma: es ese mapa.
- Sube los planos de control de IA al nivel privilegiado. Administradores nominales, MFA y acceso condicional, registro de sesiones, exposición de red restringida y alertas ante cambios administrativos, igual que harías con un controlador de dominio.
Por qué un 10.0 pesa distinto en una plataforma de IA
Una autenticación ausente es una clase de falla clásica, casi mundana. Lleva años en el diccionario de OWASP. Lo que cambió es el valor de lo que hay detrás de la comprobación.
Hace tres años, una falla sin autenticación en un servicio de analítica era un problema serio dentro de un departamento. Hoy la misma clase de error está delante del sistema que decide qué herramientas pueden invocar tus agentes, qué datos pueden leer y qué credenciales pueden tomar prestadas. La puntuación de severidad no cambió. El activo sí.
Hay un segundo efecto que merece nombre. Las cargas de IA concentran material sensible por diseño: prompts con datos de clientes, conjuntos de evaluación armados con documentos internos, índices de recuperación construidos sobre todo lo que la empresa sabe. Comprometer el plano de control no es una puerta lateral a una aplicación. Es un mapa y una llave del material que alimenta a todas.
Qué estamos diciendo a los clientes esta semana
- Confirma tu exposición y tu postura de versiones. Los servicios en la nube los parchea el proveedor, pero los componentes autogestionados de la misma arquitectura, incluidas las configuraciones de Azure Database for PostgreSQL y Cosmos DB, merecen una revisión deliberada.
- Revisa el diseño de identidad y accesos alrededor de tus cargas de IA. El mínimo privilegio entre la capa de IA y la capa de datos es el control de mayor valor que posees, y sobrevive a fallas que ningún ciclo de parches alcanza.
- Mantén los secretos fuera de los entornos de agentes. Las claves de larga vida convierten una falla de plataforma en un incidente de toda la organización.
- Registra y alerta sobre cambios en el plano de control. Si nadie nota un nuevo service principal, el reloj de la corrección lo mide otra persona.
- Dale un responsable con nombre a cada servicio de IA. Los servicios de IA sin propietario son los que se descubren durante un incidente. Encuéntralos ahora.
La imagen más amplia
Microsoft hizo lo correcto: la corrección fue rápida, el aviso fue claro y la divulgación fue responsable. La parte incómoda es el patrón, no el incidente. Las plataformas de IA ya son infraestructura de producción para finanzas, salud, logística y gobierno en esta región y más allá, y acumulan hallazgos de severidad máxima igual que la infraestructura de nube en sus primeros años.
Los equipos que salgan bien de esta década no serán los que parcheen más rápido, sino los que asuman que la plataforma será comprometida tarde o temprano y diseñen para sobrevivirlo: límites de identidad estrictos, sin credenciales ambientales, propiedad clara y un plano de control que alguien esté mirando de verdad.
Si no sabes con certeza qué podría haber alcanzado un atacante no autenticado a través de tu capa de plataforma de IA, esa es una conversación que vale la pena tener esta semana.
Fuentes
- Microsoft Security Response Center: avisos de CVE-2026-85889, CVE-2026-85885, CVE-2026-85878 y CVE-2026-87701, septiembre de 2026
- The Hacker News: Microsoft Patches CVSS 10.0 Azure AI Foundry Flaw Enabling Unauthorized Privilege Escalation, 18 de septiembre de 2026
- Archivo de CVE Brief, 18 de septiembre de 2026
- Microsoft: notas de servicio del Patch Tuesday de septiembre de 2026