CVE-2026-69836 Entra ID Vulnerabilidade: A RCE CVSS 10.0 Sem Nada Para Corrigir e Tudo Para Caçar

CVE-2026-69836 Entra ID Vulnerabilidade: O Que Aconteceu e Por Que Isso Importa

Em 20 de agosto de 2026, a Microsoft publicou um advisory para a CVE-2026-69836, uma vulnerabilidade no Microsoft Entra ID que recebeu a pontuação máxima CVSS 10.0. O título oficial é direto: "Microsoft Entra ID Remote Code Execution Vulnerability". Segundo o próprio advisory da Microsoft, a causa raiz é a desserialização de dados não confiáveis, e o impacto é execução remota de código por um atacante não autenticado pela rede — sem credenciais, sem interação do usuário, sem pré-requisito de acesso.

Para o provedor de identidade de um tenant, essa combinação é praticamente o pior cenário possível em termos de classificação. O Entra ID é o plano de controle que emite todo token, avalia toda política de Conditional Access e libera toda ativação de função privilegiada em um ambiente Microsoft 365 ou Azure. Uma falha de execução remota de código nesse plano de controle, acessível sem autenticação, é um alerta de cinco alarmes no papel.

Mas essa também é uma CVE de serviço em nuvem, e isso muda o jogo. Não há patch para baixar, não há artigo KB, não há janela de manutenção. A Microsoft corrigiu o código vulnerável do lado do servidor antes mesmo que a maioria dos defensores tivesse visto o advisory. Esse único fato — nada para instalar — é exatamente o que torna essa CVE digna de uma leitura atenta, e não de uma passada superficial.

Dentro da Falha: CWE-502 Desserialização e uma Pontuação CVSS Perfeita

A Microsoft classifica a CVE-2026-69836 sob CWE-502, Deserialization of Untrusted Data. Em termos simples: em algum ponto do serviço Entra ID, dados recebidos estavam sendo convertidos de volta em objetos ativos sem validar suficientemente de onde vinham esses dados ou o que continham. Falhas de desserialização são uma classe bem conhecida de primitiva de execução remota de código — atacantes criam um payload serializado malicioso que, uma vez reconstruído pelo código vulnerável, executa lógica arbitrária em vez de apenas reidratar uma estrutura de dados. É a mesma família de falhas por trás de alguns dos RCEs mais danosos em Java e .NET da última década, e agora ela tem uma entrada no Entra ID.

O vetor base CVSS 3.1 publicado pela Microsoft é:

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

Lido da esquerda para a direita, cada métrica maximiza a severidade: AV:N (vetor de ataque: rede — acessível pela internet), AC:L (complexidade do ataque: baixa — nenhuma condição especial necessária), PR:N (privilégios necessários: nenhum — não autenticado), UI:N (interação do usuário: nenhuma), S:C (escopo: alterado — a falha afeta recursos além do componente vulnerável) e C:H/I:H/A:H (alto impacto sobre confidencialidade, integridade e disponibilidade). Essa combinação é o que produz a pontuação base de 10.0. A pontuação temporal da Microsoft está em 8.7, refletindo as três métricas temporais que ela anexa a essa mesma string de vetor — E:U (maturidade do código de exploit: não comprovada), RL:O (nível de remediação: correção oficial) e RC:C (confiança do relatório: confirmada) — sobrepostas à RCE de rede não autenticada.

A Reviravolta na Exploração: O Que a Microsoft Corrigiu — e Por Que Isso Importa Mais Que a Pontuação

Aqui está o detalhe que torna essa CVE genuinamente instrutiva, e não apenas mais uma manchete de severidade crítica: o próprio histórico de revisões do advisory da Microsoft mostra que o status de exploração mudou já no dia seguinte.

• Revisão 1.0 — 20 de agosto de 2026: "Informação publicada."
• Revisão 1.1 — 21 de agosto de 2026: "Corrigido Exploited de Sim para Não. Esta vulnerabilidade não foi explorada em ambiente real (in the wild). Esta é apenas uma alteração informativa."

Vários veículos que cobriram a divulgação em 21 de agosto — incluindo o Help Net Security, o The Hacker News e o The Register — reportaram a CVE em um momento em que seu status de exploração ainda estava indefinido, antes de a Microsoft fixá-lo como "Exploited: No". O The Register, em particular, observou que a Microsoft caracterizou a correção como "apenas informativa", e que nenhum detalhe técnico de uma cadeia de ataque real foi publicado em lugar nenhum.

A posição atual e corrigida da Microsoft, extraída diretamente do campo Exploit Status do advisory, diz:

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

Por Que Não Há Patch Para Aplicar — e Por Que Isso Não É o Mesmo Que "Nada a Fazer"

O FAQ da Microsoft para a CVE-2026-69836 é explícito sobre o modelo de remediação: "Esta vulnerabilidade já foi totalmente mitigada pela Microsoft. Não há ação necessária para os usuários deste serviço. O propósito desta CVE é fornecer maior transparência." O advisory linka para a própria explicação da Microsoft sobre por que as CVEs de serviço em nuvem funcionam assim, "Toward greater transparency: Unveiling Cloud Service CVEs" (aka.ms/MSRC-Cloud-CVEs).

Esse é um modelo legítimo e cada vez mais comum para planos de controle SaaS: a Microsoft é dona do código, a Microsoft é dona da correção, e a CVE existe puramente para que a indústria tenha um registro público de que uma falha crítica existiu e foi fechada. O pesquisador creditado pela descoberta, Robert Fitzpatrick, é listado no próprio advisory da Microsoft como tendo reportado em conjunto com a Microsoft — isso foi encontrado e fechado internamente, não por uma red team externa publicando um exploit funcional.

Nada disso apaga o fato de que, por alguma janela de tempo, uma primitiva de RCE não autenticada e acessível pela rede existiu no provedor de identidade. "Totalmente mitigada" descreve a vulnerabilidade daqui para frente. Isso não diz nada sobre o que pode ou não ter acontecido durante a janela em que ela esteve aberta — e, embora a Microsoft afirme categoricamente que a falha "não foi explorada em ambiente real", ela não publica nem as evidências nem o escopo por trás dessa conclusão.

Detecção: Caçando Quando Nenhuma Cadeia de Ataque Foi Publicada

Esta é a parte desconfortável: a Microsoft não publicou IOCs, uma regra de detecção específica para essa CVE, nem qualquer descrição de como seria uma tentativa de exploração contra essa falha. Não há nada contra o que fazer correspondência de assinatura. Isso não significa que a caça seja inútil — significa que a caça precisa ser construída a partir do que uma RCE bem-sucedida no Entra ID provavelmente tocaria, e não a partir de um playbook fornecido pelo fornecedor.

Por Que a Retenção de Logs Vem Primeiro

Antes que qualquer coisa disso seja possível, seu tenant precisa de logs que realmente cubram a janela. Se a retenção de logs de auditoria do seu Entra ID for curta, todo esse exercício é inútil para qualquer coisa além de alguns dias atrás.

Extraindo os Dados Brutos

# Extrai os logs de sign-in cobrindo a janela de divulgação/correção (timestamps em UTC).
# Requer a permissão AuditLog.Read.All. Os espaços dentro de $filter precisam ser
# codificados em percentual: o curl rejeita uma URL que contenha espaços brutos antes mesmo de enviar qualquer coisa.
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"

Alimente a saída no processo de revisão de anomalias que você já executa para dados de sign-in — o ponto não é uma consulta mágica, é garantir que a janela seja realmente consultável.

Remediação: Uma Checklist de Controles Compensatórios, Não um Patch

Não há patch de fornecedor para implantar para a CVE-2026-69836. O que você pode fazer é garantir que os controles capazes de capturar as consequências de um comprometimento do provedor de identidade — este ou o próximo — estejam de fato ativados.

Identity Protection e Conditional Access

1. Ative uma política de risco de sign-in no Identity Protection. Sem uma, o Entra ID calcula sinais de risco, mas nada age sobre eles.
2. Reforce-a com uma política de Conditional Access baseada em risco que exija autenticação adicional ou bloqueie o acesso quando o risco de sign-in estiver elevado, em vez de depender apenas da pontuação de risco. Veja nosso detalhamento das lacunas comuns de cobertura da política baseline de Conditional Access para entender como é um conjunto completo de políticas.
3. Ative resposta automatizada a riscos para que sessões de risco sejam tratadas quase em tempo real, em vez de esperar por um ciclo de revisão manual — leia mais em nosso guia sobre políticas de risco do Entra ID Identity Protection.

Registro de Logs e Revisão Contínua

4. Estenda a retenção de logs de auditoria para uma janela que realmente suporte investigação retrospectiva, não apenas a solução de problemas do dia a dia. Nosso artigo sobre logs, retenção e configurações de diagnóstico do Entra ID cobre a configuração prática.
5. Revise service principals de alto privilégio e sua atividade de sign-in em busca de qualquer coisa inesperada ao redor da janela de divulgação — nosso artigo sobre detecção de anomalias de login em service principals percorre como é uma baseline de workload identity.
6. Assine as notificações de atualização de advisory do MSRC. O status de exploração dessa CVE mudou um dia após a publicação — se você leu apenas a manchete do dia da divulgação, perdeu a correção.

Essa não é a primeira CVE do Entra ID neste ano lançada com "nenhuma ação do cliente necessária". Cobrimos o mesmo padrão sem patch na CVE-2026-62869, uma vulnerabilidade de spoofing do Entra ID, e novamente na CVE-2026-50481, uma falha de elevação de privilégio do Azure Active Directory — uma CVSS 9.9 que também foi lançada com uma lista de remediação vazia e Customer Action Required: No. O padrão está se tornando rotina: a Microsoft entrega a correção, e a única coisa que resta aos tenants é decidir o quanto vale a pena olhar para trás.

Como a EtcSec Detecta Isso

O audit de Azure da EtcSec não detecta — e não pode detectar — a exploração de uma CVE do lado do serviço como a CVE-2026-69836; essa visibilidade está inteiramente dentro da própria infraestrutura da Microsoft. O que ele verifica são exatamente as lacunas que transformam um incidente como esse em um ponto cego: se existe alguma política de risco de sign-in, se esse risco é reforçado por uma política de Conditional Access baseada em risco, se as respostas a risco são automatizadas em vez de manuais, se a retenção de logs de auditoria é longa o suficiente para suportar uma investigação retrospectiva, e se service principals têm privilégio administrativo sem revisão contínua.