CVE-2026-69836 Entra ID Vulnerabilidad: el RCE CVSS 10.0 sin nada que parchear, pero todo que cazar

CVE-2026-69836 Entra ID Vulnerabilidad: qué pasó y por qué importa

El 20 de agosto de 2026, Microsoft publicó un aviso para CVE-2026-69836, una vulnerabilidad en Microsoft Entra ID que obtuvo una puntuación CVSS perfecta de 10.0. El título oficial es directo: "Microsoft Entra ID Remote Code Execution Vulnerability" (vulnerabilidad de ejecución remota de código en Microsoft Entra ID). Según el propio aviso de Microsoft, la causa raíz es una deserialización de datos no confiables, y el impacto es la ejecución remota de código por parte de un atacante no autenticado a través de la red — sin credenciales, sin interacción del usuario, sin acceso previo requerido.

Para el proveedor de identidad de un tenant, esa combinación es prácticamente lo peor que puede marcar una puntuación. Entra ID es el plano de control que emite cada token, evalúa cada política de Acceso Condicional y controla cada activación de rol privilegiado en un entorno de Microsoft 365 o Azure. Un fallo de ejecución remota de código en ese plano de control, accesible sin autenticación, es sobre el papel una alerta máxima.

Pero también se trata de un CVE de servicio en la nube, y eso cambia las reglas del juego. No hay parche descargable, no hay artículo KB, no hay ventana de mantenimiento. Microsoft corrigió el código vulnerable del lado del servidor antes de que la mayoría de los defensores hubiera siquiera visto el aviso. Ese único hecho — nada que instalar — es exactamente lo que hace que este CVE merezca una lectura atenta en lugar de un simple vistazo.

Dentro del fallo: deserialización CWE-502 y una puntuación CVSS perfecta

Microsoft clasifica CVE-2026-69836 bajo CWE-502, Deserialization of Untrusted Data (deserialización de datos no confiables). En términos simples: en algún punto del servicio Entra ID, los datos entrantes se estaban reconvirtiendo en objetos activos sin validar suficientemente de dónde procedían ni qué contenían. Los fallos de deserialización son una clase bien conocida de primitiva de ejecución remota de código — los atacantes elaboran una carga útil serializada maliciosa que, una vez reconstruida por el código vulnerable, ejecuta lógica arbitraria en lugar de simplemente rehidratar una estructura de datos. Es la misma familia de fallos detrás de algunos de los RCE de Java y .NET más dañinos de la última década, y ahora tiene una entrada en Entra ID.

El vector base CVSS 3.1 publicado por Microsoft es:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Leído de izquierda a derecha, cada métrica alcanza el máximo de severidad: AV:N (vector de ataque: red — accesible desde internet), AC:L (complejidad de ataque: baja — no se requieren condiciones especiales), PR:N (privilegios requeridos: ninguno — no autenticado), UI:N (interacción del usuario: ninguna), S:C (alcance: modificado — el fallo afecta recursos más allá del componente vulnerable), y C:H/I:H/A:H (impacto alto en confidencialidad, integridad y disponibilidad). Esa combinación es lo que produce la puntuación base de 10.0. La puntuación temporal de Microsoft se sitúa en 8.7, reflejando las tres métricas temporales que añade a esa misma cadena de vector — E:U (madurez del código de explotación: no probada), RL:O (nivel de remediación: corrección oficial) y RC:C (confianza del informe: confirmada) — superpuestas sobre ese RCE de red no autenticado.

El vaivén de la explotación: qué corrigió Microsoft — y por qué importa más que la puntuación

Aquí está el detalle que hace que este CVE sea genuinamente instructivo y no solo otro titular de severidad crítica: el historial de revisiones del propio aviso de Microsoft muestra que el estado de explotación cambió al día siguiente.

• Revisión 1.0 — 20 de agosto de 2026: «Information published.» (Información publicada.)
• Revisión 1.1 — 21 de agosto de 2026: «Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.» (Se corrigió el campo Explotado a No. Esta vulnerabilidad no fue explotada en el mundo real. Este es solo un cambio informativo.)

Varios medios que cubrieron la divulgación el 21 de agosto — incluyendo Help Net Security, The Hacker News y The Register — informaron sobre el CVE en un momento en que su estado de explotación todavía estaba cambiando, antes de que Microsoft lo fijara como «Exploited: No». The Register señaló en particular que Microsoft calificó la corrección como «informational only» (solo informativa), y que no se ha publicado en ningún sitio ningún detalle técnico de una cadena de ataque real.

La posición actual y corregida de Microsoft, tal como aparece en el campo Exploit Status del aviso, indica:

Publicly Disclosed: No
Exploited: No
Latest Software Release: Exploitation Less Likely

Por qué no hay parche que aplicar — y por qué eso no es lo mismo que "nada que hacer"

Las preguntas frecuentes de Microsoft sobre CVE-2026-69836 son explícitas respecto al modelo de remediación: «This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.» (Esta vulnerabilidad ya ha sido completamente mitigada por Microsoft. No hay ninguna acción que los usuarios de este servicio deban tomar. El propósito de este CVE es ofrecer mayor transparencia.) El aviso enlaza con el propio explicativo de Microsoft sobre por qué los CVE de servicios en la nube funcionan así, «Toward greater transparency: Unveiling Cloud Service CVEs» (aka.ms/MSRC-Cloud-CVEs).

Ese es un modelo legítimo y cada vez más común para los planos de control SaaS: Microsoft posee el código, Microsoft posee la corrección, y el CVE existe únicamente para que la industria tenga un registro público de que existió un fallo crítico y fue cerrado. El investigador acreditado por el hallazgo, Robert Fitzpatrick, figura en el propio aviso de Microsoft como alguien que reportó junto con Microsoft — esto se detectó y cerró internamente, no por un equipo rojo externo que publicara un exploit funcional.

Nada de esto borra el hecho de que, durante cierta ventana de tiempo, existió en tu proveedor de identidad una primitiva de RCE no autenticada y accesible por red. "Completamente mitigada" describe la vulnerabilidad de aquí en adelante. No dice nada sobre lo que pudo o no haber ocurrido durante la ventana en que estuvo abierta — y aunque Microsoft afirma rotundamente que el fallo "no fue explotado en el mundo real", no publica ni la evidencia ni el alcance detrás de esa conclusión.

Detección: cazar cuando no hay cadena de ataque publicada

Esta es la parte incómoda: Microsoft no ha publicado IOC, ninguna regla de detección específica para este CVE, ni ninguna descripción de cómo se vería un intento de explotación contra este fallo. No hay nada contra lo que hacer coincidir una firma. Eso no significa que la caza sea inútil — significa que debe construirse a partir de lo que un RCE exitoso contra Entra ID probablemente tocaría, y no a partir de un manual proporcionado por el proveedor.

Por qué la retención de registros va primero

Antes de que nada de esto sea posible, tu tenant necesita registros que cubran realmente la ventana. Si la retención de registros de auditoría de Entra ID de tu tenant es corta, todo este ejercicio carece de sentido más allá de unos pocos días atrás.

Extrayendo los datos en bruto

# Extraer los registros de inicio de sesión que cubren la ventana de divulgación/corrección (marcas de tiempo UTC).
# Requiere el permiso AuditLog.Read.All. Los espacios dentro de $filter deben estar codificados
# en porcentaje: curl rechaza una URL que contiene espacios sin codificar antes de enviar nada.
curl -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=createdDateTime%20ge%202026-08-19T00:00:00Z%20and%20createdDateTime%20le%202026-08-22T00:00:00Z"

Introduce la salida en el proceso de revisión de anomalías que ya utilices para los datos de inicio de sesión — el objetivo no es una consulta mágica, sino asegurarse de que la ventana sea realmente consultable.

Remediation: una checklist de controles compensatorios, no un parche

No hay ningún parche del proveedor que desplegar para CVE-2026-69836. Lo que sí puedes hacer es asegurarte de que los controles capaces de detectar las consecuencias de una compromisión del proveedor de identidad — esta u otra futura — estén realmente activados.

Identity Protection y Acceso Condicional

1. Activa una política de riesgo de inicio de sesión en Identity Protection. Sin ella, Entra ID calcula señales de riesgo, pero nada actúa sobre ellas.
2. Respáldala con una política de Acceso Condicional basada en riesgo que refuerce la autenticación o bloquee el acceso cuando el riesgo de inicio de sesión sea elevado, en lugar de depender solo de la puntuación de riesgo. Consulta nuestro desglose de las brechas comunes de cobertura de la política base de Acceso Condicional para ver cómo luce un conjunto de políticas completo.
3. Activa la respuesta automatizada al riesgo para que las sesiones de riesgo se gestionen casi en tiempo real en lugar de esperar a un ciclo de revisión manual — lee más en nuestra guía sobre las políticas de riesgo de Identity Protection en Entra ID.

Registro y revisión continua

4. Extiende la retención de registros de auditoría a una ventana que realmente respalde la caza retrospectiva, y no solo la resolución de problemas del día a día. Nuestro artículo sobre el registro, la retención y la configuración de diagnóstico en Entra ID cubre la configuración práctica.
5. Revisa las entidades de servicio con privilegios elevados y su actividad de inicio de sesión en busca de cualquier cosa inesperada alrededor de la ventana de divulgación — nuestro artículo sobre la detección de anomalías de inicio de sesión de entidades de servicio explica cómo luce una línea base de identidad de carga de trabajo.
6. Suscríbete a las notificaciones de actualización de avisos de MSRC. El estado de explotación de este CVE cambió un día después de su publicación — si solo leíste el titular del día de la divulgación, te perdiste la corrección.

Este no es el primer CVE de Entra ID este año que se publica con "no se requiere ninguna acción del cliente". Cubrimos el mismo patrón de cero parches en CVE-2026-62869, una vulnerabilidad de suplantación de identidad en Entra ID, y de nuevo en CVE-2026-50481, un fallo de elevación de privilegios en Azure Active Directory — un CVSS 9.9 que también se publicó con una lista de remediación vacía y Customer Action Required: No. El patrón se está volviendo rutinario: Microsoft despliega la corrección, y lo único que queda a los tenants es decidir hasta dónde mirar hacia atrás.

Cómo lo detecta EtcSec

La auditoría de Azure de EtcSec no detecta — ni puede detectar — la explotación de un CVE del lado del servicio como CVE-2026-69836; esa visibilidad reside enteramente dentro de la propia infraestructura de Microsoft. Lo que sí verifica son exactamente las brechas que convierten un incidente como este en un punto ciego: si existe o no una política de riesgo de inicio de sesión, si ese riesgo está respaldado por una política de Acceso Condicional basada en riesgo, si las respuestas al riesgo son automatizadas en lugar de manuales, si la retención de registros de auditoría es lo suficientemente larga como para respaldar una caza retrospectiva, y si las entidades de servicio tienen privilegios administrativos sin revisión continua.