El 10.0 de Entra ID no fue explotado

El 20 de agosto Microsoft publicó CVE-2026-69836, una falla de ejecución remota de código en Entra ID con puntaje 10.0, el máximo de la escala. El aviso salió marcado como explotado en la vida real. El 21 de agosto Microsoft revisó el mismo aviso y anotó el cambio en el historial: "Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only."

Entra ID es el sistema de identidad detrás de Microsoft 365 y Azure. Es la puerta por la que entra todo el mundo en la empresa, así que un 10.0 ahí es la clase de titular que hace que alguien un viernes a la tarde pregunte qué hay que parchear. La respuesta es nada, y el motivo es más útil que la noticia.

El 10.0 lo asignó Microsoft, no NVD. Al 22 de agosto la entrada en NVD sigue en estado Undergoing Analysis, que significa que NVD todavía no publicó su propia evaluación. Cuando el número lo pone el fabricante y no NVD, los puntajes de fallas distintas no son estrictamente comparables.

Por qué no hay nada que parchear

Entra ID es un servicio que corre en la infraestructura de Microsoft. La falla se corrigió del lado de Microsoft antes de que se publicara el aviso. No hay paquete de actualización, no hay artículo de KB y no hay opción de configuración que cambiar.

El aviso lo dice en su sección de preguntas: "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."

Desde junio de 2024 Microsoft publica CVE de sus servicios en la nube aunque el cliente no tenga que instalar nada. Antes, una falla así se corregía en silencio y nadie se enteraba. La política es mejor que la anterior y tiene un efecto secundario: la lista de CVE de Microsoft ahora mezcla dos cosas que se leen igual y se responden distinto.

Un CVE de servicio en la nube no es una alerta: es un informe de algo ya cerrado.

A quién NO le toca

A ninguna PyME que use Microsoft 365, que es lo mismo que decir a nadie que esté leyendo esto. No hay versión afectada que revisar, porque no corrés vos ninguna versión de Entra ID. No hay indicadores de compromiso que buscar, porque Microsoft no publicó ninguno. Y no hay nada que cerrar.

Hay un límite en lo que se puede verificar. Que la falla no fue explotada es la evaluación de Microsoft sobre su propio servicio, y un cliente no tiene forma independiente de confirmarla. No se publicó telemetría ni detalle técnico. Lo que sí se puede confirmar desde afuera es lo otro: que el aviso cambió, cuándo cambió y que la falla no está en el catálogo de explotación activa de CISA.

Cómo comprobar el estado real de un CVE de Microsoft

Son cuatro chequeos, sirven para cualquier CVE de Microsoft y no dependen de que nadie haya actualizado un titular.

El aviso, en crudo. La guía de actualizaciones de Microsoft tiene una API pública que devuelve el estado sin pasar por la página:

curl -s "https://api.msrc.microsoft.com/sug/v2.0/en-US/vulnerability/CVE-2026-69836"

Los campos que deciden son tres: exploited, publiclyDisclosed y customerActionRequired. En este caso devuelven No, No y false.

El historial de revisiones. La misma respuesta trae el arreglo revisions. Ahí figura la revisión 1.1 del 21 de agosto con el texto de la corrección. Un aviso que cambió de versión es un aviso que hay que releer.

El catálogo de explotación activa. Si una falla se está explotando contra organizaciones reales, termina en el catálogo de CISA con fecha de vencimiento. El archivo se consulta directo:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | grep CVE-2026-69836

Sin resultado, al 22 de agosto.

El puntaje, con su autor. En NVD figura quién asignó el número. Si dice secure@microsoft.com, lo puso Microsoft. El vector temporal que publicó Microsoft termina en E:U/RL:O/RC:C: código de explotación no probado, corrección oficial disponible, informe confirmado.

Los cuatro juntos llevan menos tiempo que leer la nota que los resume.

Qué hacer, en orden

1. Con esta falla, nada. Cerrala como leída.
2. Guardá el procedimiento de los cuatro chequeos. Es lo que convierte el próximo titular con puntaje máximo en una decisión de dos minutos.
3. Separá tus CVE en dos listas. Los productos que corrés vos exigen ventana de parcheo; los servicios contratados exigen leer el aviso. Confundirlos gasta el poco tiempo que hay. La tanda de Zimbra, TrueConf y MLflow del 19 al 21 de agosto es de la primera lista y sí tenía plazo.
4. Revisá qué depende de tu proveedor de identidad. Si Entra ID autentica el correo, los archivos y tres aplicaciones más, eso es concentración de riesgo aunque esta falla no haya sido explotada. La pregunta que importa es qué pasa el día que el servicio no responde, y ahí entra tener copia propia de Microsoft 365.
5. Reforzá la identidad por donde sí se ataca. Contra el proveedor de identidad los incidentes reales de una PyME casi nunca son un 10.0 en la nube: son credenciales robadas y sesiones secuestradas. El mecanismo está en cómo funciona el robo de sesión que saltea el MFA, y qué falta cuando ya tenés segundo factor, en ya tenés MFA y no alcanza.

Los términos están definidos en el glosario y el orden general de prioridades, en la guía de ciberseguridad para PyMEs de LATAM.

Preguntas frecuentes

Entonces, ¿el 10.0 era falso?

No. El puntaje describe qué tan grave sería la falla si alguien la explotara: sin autenticarse, sin interacción del usuario y con impacto total. Eso no cambió. Lo que se corrigió es otra cosa: si alguien la explotó. Gravedad potencial y explotación real son dos campos distintos del mismo aviso, y el titular los fundió en uno.

¿Por qué Microsoft publica un CVE si no hay nada que hacer?

Por transparencia declarada. Desde junio de 2024 emite CVE de servicios en la nube aunque el cliente no tenga que instalar nada, con el argumento de que compartir las fallas encontradas y resueltas permite que la industria aprenda. La contrapartida es la que se vio acá: avisos sin acción posible que circulan con el mismo formato que los que sí la exigen.

Si mi proveedor de seguridad me mandó una alerta por esto, ¿qué le respondo?

Que el aviso fue corregido el 21 de agosto y que el campo de acción del cliente está en falso, con el enlace al aviso. Si la alerta llegó después de esa fecha sin mencionar la corrección, es señal de que el proveedor replica titulares sin verificar la fuente. Para un cliente que te pregunta a vos, el criterio para responder está en cómo responder un cuestionario de seguridad.

¿Conviene depender de un solo proveedor de identidad?

Depende de con qué se compara. Alternativas como Okta mueven la concentración de lugar, no la eliminan: seguís teniendo un proveedor que autentica todo. Lo que sí reduce el daño es que la identidad no sea el único control, que exista copia de los datos fuera del mismo proveedor y que el segundo factor resista el robo de sesión.