La ejecución remota de código en Entra ID que demuestra que la identidad es la nueva superficie de ataque
Una CVE crítica en Microsoft Entra ID expuso el peligro de centralizar la autenticación como perímetro de seguridad. Aunque el parche llegó por el lado del servidor antes de que la mayoría de las organizaciones supieran que existía, la lección más amplia para los arquitectos de cero confianza es innegable.
La vulnerabilidad que demuestra el punto
CVE-2026-69836 es un fallo crítico de CVSS 10.0 en Microsoft Entra ID, la plataforma de identidad en la nube que millones de empresas tratan como su perímetro de seguridad. Un error de deserialización —CWE-502, la pesadilla conocida del procesamiento de objetos no validados— permitió a un atacante ejecutar código arbitrario en la infraestructura de Entra ID sin ninguna autenticación y sin requerir interacción alguna del usuario.
Esa combinación fue lo que impulsó la puntuación al máximo. Explotación remota con cero prerequisitos en un servicio que se sitúa entre cada credencial de usuario y cada carga de trabajo de Microsoft 365, cada recurso de Azure, cada aplicación de terceros conectada. Un atacante que tomara control de la capa de identidad podría pivotar hacia cargas de trabajo en la nube, secuestrar tokens de autenticación o reescribir políticas de acceso en toda una organización.
Microsoft inicialmente marcó la vulnerabilidad como explotada. La última actualización señala que la amenaza ha disminuido —la vulnerabilidad no está siendo aprovechada actualmente en entornos reales—, pero el hallazgo central permanece: el parche fue desplegado por parte de Microsoft antes de que llegara el anuncio, y no hay parches para el cliente, ni artículos KB, ni cambios de configuración que aplicar.
Este es el nuevo normal de los CVE en la nube. No parcheas esto. Microsoft parchea. Tu trabajo es averiguar si alguien intentó explotarla durante la ventana entre el descubrimiento y la corrección.
El problema de diseño en el corazón de esto
La historia aquí es más grande que un solo CVE. Se trata de lo que ocurre cuando construyes tu arquitectura de seguridad alrededor de un único servicio de identidad centralizado y luego descubres que ese servicio es, de hecho, un servicio —con las mismas clases de fallos de software que cualquier otra pila de aplicaciones.
Entra ID fue diseñado para simplificar la gestión de accesos. SSO, políticas de acceso condicional, asignaciones de roles privilegiados, emisión de tokens. Esa simplificación es también lo que hace a esta vulnerabilidad tan estructuralmente peligrosa. Cada inquilino de Microsoft que se autentica a través de Entra ID, cada suscripción de Azure, cada integración de SaaS de terceros que confía en Entra como su proveedor de identidad —todos comparten el mismo backend. Un compromiso exitoso no se mantiene contenido. Se propaga en cascada.
Esta es la tensión fundamental de la arquitectura zero-trust. Puedes hablar de microsegmentación y acceso de mínimo privilegio hasta que tus paneles de monitoreo se pongan azules, pero si la capa de identidad en sí es un punto único de falla con extremos de deserialización explotables, no has eliminado el perímetro. Solo lo has hecho más concentrado.
Robert Fitzpatrick, el investigador de seguridad que reportó el problema a través de divulgación coordinada, encontró exactamente lo que toda cacería de vulnerabilidades de deserialización termina encontrando: un camino de entrada que aceptaba datos no confiables sin la validación adecuada. La corrección se aplicó en la infraestructura de Microsoft. Pero la pregunta arquitectónica permanece sin respuesta.
Qué deben hacer realmente los defensores
No hay parches que desplegar. Eso significa que la guía de remediación de Microsoft aterriza en algún lugar entre lo inútil y lo irónicamente transparente. La compañía recomienda revisar los registros de inicio de sesión de Entra ID, las políticas de acceso condicional y las asignaciones de roles privilegiados en busca de señales de actividad anómala desde antes de que se desplegara la corrección. «Revisar», no «parchear». «Buscar señales», no «detener la hemorragia».
Esta es la realidad operativa de las vulnerabilidades en servicios en la nube. Tu equipo de seguridad no elige cuándo se lanza la corrección. Microsoft eligió el cronograma. Lo que tu equipo puede hacer es mirar hacia atrás con suficiente granularidad para determinar si la ventana de exposición produjo algún compromiso real.
Así es lo que se ve en la práctica. Extrae los registros de inicio de sesión de Entra ID del período anterior al parche y busca patrones que no coincidan con tu línea base. Intentos fallidos de autenticación desde geografías inusuales. Solicitudes de tokens desde aplicaciones inesperadas. Modificaciones de políticas de acceso condicional realizadas fuera de tu ritmo normal de cambios. Asignaciones de roles privilegiados concedidas a cuentas que normalmente no los poseen. Estas son las cosas que importan cuando estás cazando evidencia de explotación en un sistema que no controlas.
La recomendación más amplia es igualmente importante: refuerza el monitoreo alrededor de la infraestructura de identidad en general. Los fallos de deserialización en servicios de autenticación no van a desaparecer. Permanecen como un objetivo de alto impacto porque la recompensa es proporcionalmente masiva —controlar la capa de identidad te da palanca sobre todo lo que viene después.
La iniciativa de transparencia que no cambia nada
Microsoft enmarcó este anuncio bajo su iniciativa «Hacia Mayor Transparencia» para vulnerabilidades de servicios en la nube. La intención es encomiable: dejar de tratar las correcciones de backend como eventos invisibles y en su lugar dar a los clientes visibilidad sobre amenazas que tocaron su entorno. Anteriormente, muchos CVE de servicios en la nube pasaban sin reportarse porque no había nada para que el cliente parcheara.
La transparencia no es lo mismo que la resiliencia. Saber que estuviste expuesto durante una ventana de tiempo no te hace más seguro. Te hace mejor informado sobre haber estado inseguro. La iniciativa es un paso hacia la rendición de cuentas, pero no cambia la asimetría fundamental: Microsoft controla el cronograma de corrección, el cronograma de divulgación y la evidencia con la que tu equipo tiene que trabajar al investigar posibles compromisos.
Las organizaciones que trataron a Entra ID como un fundamento confiable en lugar de un componente sujeto a la misma superficie de vulnerabilidades que cualquier otro servicio ahora enfrentan una revisión de realidad. La infraestructura de identidad es software. Tiene fallos. Es explotada. El cambio de seguridad basada en perímetro a seguridad basada en identidad suponía reducir el radio de explosión. Este CVE demuestra que concentrar la confianza en un único sistema hace lo contrario —la magnifica.
Qué sigue
La vulnerabilidad en sí está parcheada. La explotación en entornos reales que Microsoft inicialmente confirmó ha cesado. Pero la lección arquitectónica apenas está comenzando a calar en la comunidad de seguridad.
Cada organización que construyó su narrativa zero-trust alrededor de Entra ID como la capa de identidad controladora ahora tiene que responder a una pregunta que no anticipó: ¿qué pasa cuando el servicio de identidad es precisamente lo que está siendo atacado? La respuesta, obviamente, es que o diversificas tus dependencias de identidad o aceptas que tu arquitectura de seguridad tiene un punto único de falla catastrófica que no controlas.
Ninguna opción es fácil. La diversificación significa gestionar múltiples proveedores de identidad, renegociar relaciones de confianza, reconstruir políticas de acceso condicional. La aceptación significa vivir con el riesgo e invertir fuertemente en detección —que es exactamente lo que Microsoft le está pidiendo ahora a todos que haga con sus registros de inicio de sesión y auditorías de políticas.
La vulnerabilidad se desvanecerá de los titulares. El problema estructural que expuso no desaparecerá.