Volver al Blog

El parche que no es tuyo: qué haces con el CVE-2026-69836 de Entra ID

Jaula de rejilla metálica cerrada con candado en una sala de datacenter compartida, vista desde fuera

El jueves 20 de agosto Microsoft publicó una ficha de seguridad con la puntuación máxima: CVE-2026-69836, ejecución remota de código en Entra ID. El viernes, la prensa del sector abrió con «explotado en ataques». Ese mismo viernes, sin nota de prensa ni titular, Microsoft revisó la ficha. La versión 1.1 dice, palabra por palabra: «Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.»

Un cambio meramente informativo. De acuerdo. Pero lo interesante de este CVE no es el vaivén de una casilla, que pasa y no es noticia. Lo interesante es lo que queda cuando el polvo se asienta: una vulnerabilidad crítica en la capa que autentica a toda tu empresa, que tú no has parcheado, que no puedes comprobar y que no va a aparecer en ningún informe de vulnerabilidades que entregues este trimestre. Y aun así, hay trabajo tuyo aquí. Solo que no es el que crees.

Lo que dice la ficha (y cómo leerla tú mismo)

La Security Update Guide de Microsoft tiene una API pública, sin clave y sin registro. No hace falta esperar a que alguien te lo resuma: la fuente primaria son dos líneas de terminal.

curl -s "https://api.msrc.microsoft.com/sug/v2.0/en-US/vulnerability/CVE-2026-69836" \
  | jq '{exploited, customerActionRequired, baseScore, temporalScore,
         revisions: [.revisions[] | {version, revisionDate, unformattedDescription}]}'

Lo que devuelve, resumido:

  • Título: «Microsoft Entra ID Remote Code Execution Vulnerability». CWE-502, deserialización de datos no confiables.
  • Publicada el 20-ago-2026. Revisión 1.1 el 21-ago-2026, la que corrige Exploited a No.
  • baseScore: 10.0 · temporalScore: 8.7 · publiclyDisclosed: No.
  • customerActionRequired: false. Este es el campo que lo cambia todo.

Si gestionas inquilinos de terceros, esto son veinte líneas de cron, no una suscripción a un servicio de threat intel. Y tiene una ventaja sobre cualquier resumen: el campo revisions te cuenta cuándo el fabricante ha cambiado de opinión, que es exactamente el dato que ningún titular arrastra después.

El 10.0 y la letra pequeña del vector

El vector completo es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C. Traducido: por red, complejidad baja, sin credenciales y sin que nadie tenga que hacer clic en nada. Pero lo que lo empuja hasta el 10.0 redondo es S:C, scope changed: el impacto se sale del componente vulnerable. En un servicio de identidad multi-inquilino, esa letra es la que da respeto de verdad, mucho más que la cifra.

La cola del vector es la que baja el temporal a 8.7: E:U (no consta código de explotación), RL:O (arreglo oficial disponible) y RC:C (confirmado). El índice de explotabilidad de Microsoft, además, marca este CVE como «Exploitation Less Likely». De esa etiqueta ya escribimos hace dos días a propósito de otro fallo, y el matiz de entonces sigue valiendo: describe una probabilidad, no una promesa. Aquí, además, la etiqueta importa menos de lo habitual, porque el plazo de parcheo no lo decides tú.

Un CVE sin versión, sin KB y sin parche

La FAQ de la ficha responde a la pregunta obvia —«¿por qué no hay enlaces a una actualización?»— con esta frase: «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.»

Conviene decirlo claro, porque no todo es queja: esto es Microsoft haciendo lo correcto. Desde junio de 2024 publica CVE de vulnerabilidades críticas de sus servicios en la nube aunque el cliente no tenga que hacer absolutamente nada. Antes de ese cambio, un fallo así se arreglaba en silencio y nadie de fuera se enteraba jamás. Que exista una ficha, con su CWE, su vector y su historial de revisiones, es una mejora real sobre el estado anterior del mundo.

El efecto secundario, en cambio, no es de Microsoft: es tuyo. Tu gestión de vulnerabilidades funciona con producto, versión y parche. Este CVE no tiene ninguna de las tres cosas. No hay una versión afectada que buscar en el inventario ni un KB que confirmar como instalado. Es una vulnerabilidad crítica que, operativamente, se comporta como una noticia.

La pregunta que sí es tuya: ¿te habrías enterado?

La ficha no dice desde cuándo existía el fallo ni cuándo se corrigió. Solo dice que ya está mitigado. Eso deja una ventana de exposición de duración desconocida en algún punto del pasado, y una pregunta muy concreta encima de la mesa: si algún día hubiera que responder «¿nos afectó?», ¿con qué la responderías?

Con los registros de actividad de Entra ID. Y su retención por defecto, según la documentación de Microsoft, es esta:

Registro Entra ID Free P1 P2
Auditoría 7 días 30 días 30 días
Inicios de sesión 7 días 30 días 30 días
Inicios de sesión de riesgo 7 días 30 días 90 días
Registros de actividad de Graph No disponible (solo P1/P2) No se retienen si no los exportas

Siete días. Ese es el horizonte de lo que ves en el portal de Entra con licencia Free, que son muchos más inquilinos de los que la gente supone. Y hay un detalle que se lleva por delante el plan B de mucha gente: la retención no es retroactiva. La documentación es explícita en que, al subir de Free a premium, solo ves lo que aún esté dentro de la ventana de siete días; lo que ya caducó no se recupera. Comprar la licencia el día del sobresalto no te devuelve el mes pasado.

Matiz importante, y juega a tu favor: esa tabla es la del portal de Entra. El registro de auditoría unificado de Microsoft Purview es otra cosa y no depende de tu licencia de Entra. Ahí, los eventos de inicio de sesión aguantan 180 días con Audit (Standard), y la política por defecto de Audit (Premium) retiene un año los registros de la carga de trabajo AzureActiveDirectory — eso sí, solo para los usuarios con licencia E5 o complemento equivalente; los demás se quedan en 180 días. Traducido: tu memoria real es casi seguro mayor que la de la tabla. Pero vive en otro portal, bajo otra licencia y con otra herramienta de consulta. Que exista no sirve de nada el día que hay prisa si nadie del equipo sabe que está ahí.

Que quede claro lo que no estamos diciendo: no estamos insinuando que a nadie le hayan entrado por aquí. La ficha dice que no hubo explotación y no tenemos ningún motivo para dudarlo. Lo que decimos es otra cosa, y es independiente de este CVE en concreto: el día que una de estas casillas se corrija en el sentido contrario, la respuesta a «¿nos afectó?» no la tiene Microsoft. La tienes tú, repartida entre dos portales, y con una fecha de caducidad que casi nadie ha mirado.

El checklist que sí depende de ti

Nada de esto es una reacción a este CVE. Es lo que hace que el siguiente te pille en otra posición:

  • 1Saca los registros de Entra a donde mandes tú. Los diagnostic settings del inquilino los envían a Log Analytics, a una cuenta de almacenamiento o a un Event Hub si quieres llevarlos a un SIEM de terceros. A partir de ahí la retención la decide tu criterio (o tu normativa), no tu licencia.
  • 2Inventaria los service principals y los registros de aplicación, con sus credenciales y sus caducidades. Es el sitio donde se queda a vivir quien pasa por la capa de identidad, y el sitio que casi nadie mira. Es el mismo trabajo de higiene del que hablábamos en el directorio con más fichas que empleados.
  • 3Revisa los permisos consentidos, y sobre todo los de aplicación frente a los delegados. Un permiso de aplicación no necesita que ningún usuario inicie sesión para seguir funcionando.
  • 4Cuenta tus administradores globales de verdad, no los que crees tener. Y ten una cuenta rompe-cristales documentada, excluida de las políticas que podrían dejarte fuera, y vigilada precisamente por eso.
  • 5El acceso condicional es el control que sigue siendo tuyo: se aplica a cada petición de acceso pase lo que pase por dentro.

Y ahora la parte honesta, porque si no la decimos nosotros la dirá el primero que lea la ficha con atención: ninguno de estos cinco puntos habría impedido el CVE-2026-69836. El fallo estaba dentro del servicio de Microsoft, no en tu configuración. Ninguna política de acceso condicional detiene una deserialización insegura en el código del proveedor. Esta lista no sirve para evitar el fallo; sirve para poder responder después, que es una cosa distinta y, en la práctica, la única que estaba en tu mano.

Lo que NO vamos a hacer con esto

  • No te vamos a vender una auditoría de este CVE. No hay nada que auditar: el fallo estaba en el lado del proveedor y ya no está. Quien te llame esta semana ofreciéndote revisar tu exposición al CVE-2026-69836 te está vendiendo humo con número de serie.
  • Tampoco te vamos a decir que te montes tu propio directorio. Sería la conclusión fácil y sería mala: operar identidad propia, con su alta disponibilidad, su parcheo y su gente de guardia, sale peor para casi todo el mundo. La nube no es el problema.
  • Y no vamos a fingir que el reparto de responsabilidades es un diagrama. Es, en la práctica, la lista de preguntas que puedes contestar tú solo. Todo lo que quede fuera de esa lista es confianza — legítima, pero confianza. Del otro lado de esa misma frontera hablábamos cuando el buscador de Microsoft 365 dejó de funcionar y el SLA no lo cubría.

En corto

El CVE-2026-69836 no te pide nada. No hay parche que aplicar, ni ventana que negociar, ni versión que perseguir por el inventario. Por eso es un buen día para mirar lo otro: cuánta memoria tiene tu inquilino, quién tiene credenciales dentro de él y cuántas de las preguntas que te haría un cliente —o un juez— puedes contestar sin llamar a nadie. Ese trabajo no caduca cuando se corrige una casilla. Nuestro enfoque de Zero Trust y de Microsoft 365 empieza justo ahí: por lo que puedes demostrar, no por lo que te prometen.

Fuentes (primarias, consultadas el 22-ago-2026): la ficha del CVE-2026-69836 —puntuaciones, vector, CWE-502, campos exploited y customerActionRequired, texto de la FAQ e historial de revisiones 1 y 1.1— en la Security Update Guide de Microsoft y su API pública (api.msrc.microsoft.com/sug/v2.0); la política de publicar CVE de servicios en la nube sin acción del cliente, en «Toward greater transparency: Unveiling Cloud Service CVEs» (MSRC, junio 2024); los plazos de retención y la advertencia de que no son retroactivos, en la referencia de retención de datos de Microsoft Entra (Microsoft Learn); los 180 días de Audit (Standard) y el año que la política por defecto de Audit (Premium) retiene la carga de trabajo AzureActiveDirectory para usuarios E5, en las políticas de retención de auditoría de Microsoft Purview.

¿Sabes cuántos días de registro guarda tu inquilino de Entra ID?

En everyWAN desplegamos y aseguramos entornos de Microsoft 365: MFA, acceso condicional y Secure Score. Si no sabes responder a la pregunta de arriba, es un buen sitio por donde empezar — y sin vendernos una licencia por el camino, porque no somos resellers de nadie.

Hablar con everyWAN

Etiquetas:

Compartir:

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN