CVE-2026-50481 Azure Active Directory Escalada de Privilégios: O CVSS 9.9 que Você Não Consegue Corrigir

A Microsoft atribuiu ao CVE-2026-50481 Azure Active Directory Escalada de Privilégios (Elevation of Privilege) uma pontuação base CVSS 3.1 de 9.9 em seu release de agosto de 2026 — e não lançou nada para você instalar. É assim que uma CVE crítica de serviço em nuvem se parece do lado do cliente, e é isso que você ainda pode verificar dentro do seu próprio tenant.

CVE-2026-50481 Azure Active Directory Escalada de Privilégios: O Que Se Sabe

A Microsoft publicou a falha em 6 de agosto de 2026. Toda a sua descrição técnica é uma única frase: „Modification of assumed-immutable data (maid) in Azure Active Directory allows an authorized attacker to elevate privileges over a network." O registro do MSRC a classifica como CWE-471, lista Latest Software Release: N/A e traz uma lista de remediações vazia. O campo Customer Action Required diz No.

Essa combinação é a história em si. Um 9.9 no diretório que autentica todo o seu parque Microsoft, e a orientação do fornecedor se resume a "já corrigimos isso".

Eis o que os dois registros oficiais realmente dizem.

Leia o vetor, não apenas o número. PR:L significa que o invasor já está autenticado com privilégios baixos — isso não é uma falha não autenticada exposta à internet, é uma escalada disponível para qualquer um que já tenha um ponto de apoio no seu tenant. S:C (escopo alterado) é o que empurra a pontuação para 9.9: o impacto atravessa os limites do componente vulnerável e alcança outras autoridades de segurança. E:U e RL:O — código de exploração não comprovado, correção oficial disponível — puxam a pontuação temporal para baixo, a 8.6.

Por Que Não Há Nada Para Corrigir

O Azure Active Directory não é um software que você executa. A NVD marca o CVE-2026-50481 como exclusively-hosted-service e o mapeia para o CPE cpe:2.3:a:microsoft:azure_active_directory:- — um produto sem versão, porque existe apenas uma instância em execução, e é a Microsoft quem a opera.

Isso é política deliberada, não um descuido. Em junho de 2024, Lisa Olson, do MSRC, anunciou a mudança: „We are now announcing that we will issue CVEs for critical cloud service vulnerabilities, regardless of whether customers need to install a patch or to take other actions." O post é explícito sobre o marcador: „In the CVE.org record, we will use the exclusively-hosted-service tag to indicate that there is no action required by the customer."

Então uma CVE de nuvem é um aviso de transparência, não uma tarefa. A vulnerabilidade existia no diretório multi-tenant, a Microsoft a corrigiu do lado dela, e a CVE avisa você de que isso aconteceu.

O CVE-2026-50481 não estava sozinho. Analisando o documento oficial de release CVRF de agosto de 2026 da Microsoft, 21 CVEs nesse release trazem Customer Action Required: No. Três delas estão diretamente no plano de identidade:

Para dar uma noção de escala, o Cisco Talos contou 421 vulnerabilidades no release de agosto de 2026, 62 marcadas como críticas, 40 delas de execução remota de código, com exatamente uma explorada ativamente (CVE-2026-68820, uma escalada no WinSock AFD com CVSS 7.0). O Talos lista o CVE-2026-50481 em „Other critical vulnerabilities" — registrada, não destacada. Quem priorizou agosto pela pergunta „o que preciso implantar neste fim de semana" — e foi para onde foi a atenção da maioria das equipes — veja nosso resumo de RCEs em controladores de domínio no Patch Tuesday de agosto de 2026 —, essa CVE não gerou nenhum chamado.

Há um precedente para tratar isso como um erro. O CVE-2025-55241, a falha de Elevation of Privilege do Azure Entra ID que o MSRC publicou em 4 de setembro de 2025, atingiu um CVSS 10.0 completo e também foi lançada com Customer Action Required: No. O padrão já está bem estabelecido: as vulnerabilidades de identidade mais graves da era da nuvem chegam como avisos, não como patches.

O Que a Microsoft Não Publicou

Seja claro quanto ao limite do que se sabe, porque ele é estreito.

A Microsoft não publicou nenhuma cadeia de ataque, nenhum critério de tenant afetado, nenhum indicador de comprometimento, nenhuma janela de exploração, nem qualquer declaração sobre se a falha já foi abusada antes da correção. O único sinal sobre a classe da fraqueza é o mapeamento CWE. A CWE-471 descreve um produto que „does not properly protect an assumed-immutable element from being modified by an attacker" — uma entrada, nas palavras do MITRE, „critical enough to the functioning of the application that it should not be modifiable at all, but it is". O MITRE lista como consequências Modify Application Data e Unexpected State.

Isso mostra o formato da classe de falha. Não mostra qual atributo, claim ou identificador do Azure AD era alterável quando não deveria ser. Quem publica hoje um caminho de exploração específico para o CVE-2026-50481 está extrapolando a partir do CWE — não reportando.

O que você pode fazer é agir sobre o resíduo. Se uma escalada em nível de diretório era alcançável antes da correção do lado do servidor, os vestígios de qualquer uso dela estariam nos próprios logs do seu tenant — não na saída de um scanner.

Detecção

Não existe assinatura para o CVE-2026-50481, e qualquer fornecedor que afirme ter uma está vendendo um palpite. O que você pode fazer é caçar o resultado que a falha permite: privilégio que apareceu sem um caminho de aprovação legítimo. Essa caça vale a pena rodar independentemente desta CVE.

O relógio importa. O Microsoft Entra retém logs de auditoria por sete dias no Entra ID Free e 30 dias no P1 e P2. Os logs de atividade do Microsoft Graph exigem P1 ou P2 e não são retidos a menos que você já os tenha encaminhado para um workspace ou conta de armazenamento. Faça as contas antes de planejar a caça. A divulgação de 6 de agosto de 2026 já está fora da janela de sete dias do Free, então um tenant Free não tem mais nada para consultar. Um tenant P1 ou P2 ainda está dentro da janela de 30 dias — mas só até aproximadamente 5 de setembro de 2026, depois disso essa evidência se perde a menos que tenha sido exportada. Conserte o pipeline primeiro; veja lacunas de retenção de logs e configurações de diagnóstico no Entra ID.

Cada nome de atividade acima é retirado literalmente da referência de atividades de auditoria da Microsoft.

Comece pelas mudanças de role de diretório em toda a sua janela de retenção:

AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService in ("Core Directory", "PIM")
| where ActivityDisplayName has "role"
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName),
         ActorApp  = tostring(InitiatedBy.app.displayName)
| project TimeGenerated, ActivityDisplayName, ActorUser, ActorApp,
          Result, TargetResources, CorrelationId
| order by TimeGenerated desc

Depois passe para a camada de API, onde uma workload identity agindo em nome própria fica visível de um jeito que o trilha de auditoria do diretório sozinha pode não mostrar:

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(30d)
| where RequestMethod in ("POST", "PATCH", "PUT", "DELETE")
| where RequestUri has_any ("/directoryRoles", "/roleManagement",
                            "/servicePrincipals", "/applications")
| where ResponseStatusCode between (200 .. 299)
| project TimeGenerated, RequestMethod, RequestUri, ResponseStatusCode,
          UserId, ServicePrincipalId, AppId, IPAddress, Roles, Scopes, Wids
| order by TimeGenerated desc

Observe o valor do serviço: o Privileged Identity Management é registrado como PIM, não por extenso — o próprio guia de operações de segurança para contas privilegiadas da Microsoft filtra esses eventos com Service = PIM. Escrever por extenso retorna um conjunto de resultados vazio.

A coluna Wids contém as roles de todo o tenant carregadas no token de quem chama, e ServicePrincipalId separa workload identities de usuários interativos — os dois campos que transformam uma parede de chamadas Graph em uma pergunta respondível.

Remediação

Você não pode corrigir a vulnerabilidade. Você pode corrigir o raio de impacto, que é a única variável que você controla em uma CVE de serviço hospedado.

1. Reestabeleça a linha de base dos titulares de roles privilegiadas. Extraia a associação atual de cada role de diretório e compare com uma lista conhecida como boa de antes de 6 de agosto de 2026. Qualquer adição que você não consiga vincular a um registro de mudança é o achado — independentemente de vir ou não desta CVE.

2. Elimine o privilégio permanente. Escaladas PR:L compensam na proporção da quantidade de privilégio permanente disponível. Migre atribuições permanentes para elegibilidade no PIM, com aprovação e MFA na ativação. Nosso guia sobre por que os tenants acumulam Administradores Globais demais cobre a etapa de inventário.

3. Audite identidades não humanas. Service principals com roles de diretório ou permissões de aplicativo do Graph de alto privilégio são o ponto de apoio PR:L mais comum em um tenant moderno, e eles não sofrem phishing, não são rotacionados nem desligados. Veja service principals do Entra com roles de admin com privilégios excessivos.

4. Verifique a integridade do break-glass. Contas de acesso de emergência são excluídas do Conditional Access por design, o que as torna o alvo de maior valor de qualquer escalada. Confirme se credenciais, exclusões e alertas de sign-in ainda correspondem à intenção — lacunas em contas break-glass.

5. Adicione CVEs de nuvem ao seu processo de triagem. Filtre o Security Update Guide pela coluna Customer Action Required, que o MSRC adicionou exatamente para isso. „No action required" é uma declaração sobre patch, não sobre garantia — as 21 CVEs sem ação em agosto de 2026 ainda merecem, cada uma, uma decisão, mesmo que essa decisão seja „registrada, sem exposição".

6. Feche a porta de convidados e externos. PR:L conta qualquer principal autenticado. Contas de convidado obsoletas e configurações de convite B2B sem restrição ampliam o conjunto de contas a partir das quais uma escalada pode começar.

Como a EtcSec Detecta Isso

A EtcSec não consegue detectar uma vulnerabilidade dentro do próprio serviço da Microsoft — ninguém consegue, de fora. O que uma auditoria EtcSec do Entra detecta é a exposição que decide se uma escalada de diretório vira uma nota de rodapé ou um incidente: PA_PERMANENT_ADMIN_ASSIGNMENTS para privilégio permanente que nunca expira, PA_PIM_NOT_ENABLED onde não existe nenhuma fronteira just-in-time, PA_TOO_MANY_GLOBAL_ADMINS para uma Tier 0 superdimensionada, SP_HIGH_PRIVILEGE para service principals com roles de diretório privilegiadas, e AZ_GROUP_PRIVILEGED_CHANGES para grupos privilegiados cujas mudanças de membro ninguém está observando.

Essa é a divisão honesta de trabalho em uma CVE de serviço hospedado. A Microsoft é dona da correção. Você é dono do quanto essa correção importou — e as duas metades dessa frase são auditáveis. Para a sequência completa de revisão, veja como auditar a segurança do Microsoft Entra ID.