Falha de autorização 9.9 no Azure SRE Agent poderia ter permitido que um chamador herdasse sua identidade

O CVE-2026-62830 é uma falha de autorização ausente no Azure SRE Agent, o agente com IA da Microsoft para equipes de confiabilidade de sites do Azure, que tria incidentes, consulta telemetria e, quando configurado, executa remediação. A Microsoft divulgou a falha em agosto de 2026 e atribuiu-lhe 9,9 de 10 — Crítica — segundo o CVSS 3.1. Qualquer tenant do Azure que executasse o agente estava no escopo da falha; o arquivo de incidentes não registra nenhuma vítima confirmada nem exploração. A descrição da Microsoft para a falha é uma frase: "A ausência de autorização no Azure SRE Agent permite que um atacante autorizado eleve privilégios pela rede." O serviço foi corrigido no lado do servidor, e a Microsoft diz que os clientes não tinham nada para corrigir. A entrada completa, com suas classificações de gravidade e confiança, está no Orca AI Incident Archive ao lado dos incidentes vizinhos nesta série.

O que a Microsoft publicou e o que deixou de fora

A entrada do Guia de Atualizações de Segurança da Microsoft para a CVE-2026-62830 registra uma elevação de privilégio no Azure SRE Agent, fraqueza CWE-862 (Autorização Ausente), pontuação base de 9,9 e pontuação temporal de 8,6. O vetor — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — descreve um ataque de rede que exige apenas privilégios baixos, nenhuma interação do usuário e produz alto impacto sobre a confidencialidade, a integridade e a disponibilidade. A Microsoft credita a descoberta ao pesquisador de segurança wtm, da Offensi, nos agradecimentos do comunicado.

Duas partes desse vetor contam a história. A métrica de escopo é Changed (S:C), que a própria documentação de métricas da Microsoft define como um caso em que o componente vulnerável e o componente impactado são diferentes e são gerenciados por autoridades de segurança diferentes. As métricas temporais são Unproven (código de exploração não comprovado), Official fix (correção oficial) e Confirmed (confirmado), e é por isso que a pontuação temporal fica abaixo da base.

O FAQ do aviso explica por que existe uma pontuação 9,9 sem link de download: “Essa vulnerabilidade já foi totalmente mitigada pela Microsoft. Não há nenhuma ação a ser tomada pelos usuários deste serviço. O objetivo desta CVE é proporcionar maior transparência.” A Microsoft classifica o produto como um serviço exclusivamente hospedado, motivo pelo qual o registro não traz número de compilação nem intervalo de versões afetadas.

A tabela de explorabilidade é tão clara quanto o FAQ. Divulgado publicamente: Não. Explorado: Não. Avaliação de exploração: Menos provável. O que o aviso não descreve é o fluxo on-behalf-of, a identidade gerenciada ou os runbooks. Também não fornece um intervalo de versões: o CPE é o produto sem versão, e a única versão afetada listada é um traço. Tudo o que um leitor gostaria de saber sobre o mecanismo precisa vir de outro lugar, e esse outro lugar é, em grande parte, a própria entrada do arquivo.

O que o agente é, e por que a sua identidade é aquilo que vale a pena alcançar

Azure SRE Agent não é um chatbot acoplado a um dashboard. A documentação do Microsoft Azure SRE Agent descreve um agente que se conecta a recursos do Azure, ferramentas de observabilidade, plataformas de incidentes e repositórios de código-fonte, coleta sinais, correlaciona implantações, propõe mitigações e — dependendo do modo de execução definido pelo cliente — executa-as. No modo Revisão, um administrador aprova as ações de gravação; no modo Autônomo, o agente as aplica sem esperar. Seu alcance é ampliado por meio de habilidades e runbooks, operações da CLI do Azure, agentes personalizados, ferramentas Python, conectores MCP e hooks de agente.

A mesma documentação declara o fato que torna o CVE interessante: "O agente se autentica com identidade gerenciada e opera sob controle de acesso baseado em funções (RBAC) do Azure." Uma identidade gerenciada é uma identidade do Entra atribuída a um serviço, e o que ela pode fazer é exatamente o que suas atribuições de função permitem. A autoridade do agente, portanto, não é uma propriedade do código do agente, mas das funções atribuídas a essa identidade — que é o limite que uma verificação de autorização ausente deixaria de proteger.

Uma análise técnica separada, a entrada do HackTricks Cloud sobre escalada de privilégios do Azure SRE Agent, descreve a versão estrutural desse problema sem citar a CVE-2026-62830. Ela lista operações de plano de controle que permitem a um chamador direcionar um agente — abrir uma thread, aprovar uma remediação proposta, reassociar a configuração do agente, redirecionar um conector de dados — e enquadra o resultado como um confused deputy: o chamador não precisa das permissões do agente, apenas de uma forma de fazer o agente usá-las. Essa entrada não é sobre esta CVE e não deve ser lida como corroboração dela. Ela é útil pelo mesmo motivo que a pontuação é: mostra onde a autoridade realmente reside.

O mecanismo: o que o arquivo descreve, e o que o fornecedor confirma

A entrada do arquivo descreve a vulnerabilidade como uma falha naquilo que chama de fluxo Scope-Changed OBO (on-behalf-of). Um fluxo on-behalf-of é uma troca de token na qual um serviço troca a credencial de um chamador por um token que lhe permite chamar um serviço a jusante como esse chamador. Se a verificação de autoridade nessa troca falhar, afirma o arquivo, a chamada a jusante pode recorrer à identidade gerenciada com escopo de locatário do próprio agente, em vez da identidade do chamador. Um chamador autenticado, mas com baixos privilégios, herdaria então as permissões da entidade de serviço do agente e poderia modificar runbooks, telemetria e infraestrutura — não apenas o agente, mas todos os recursos do Azure nos quais a identidade gerenciada detém uma função.

Essa descrição é coerente com tudo o que a Microsoft publicou, e não consta naquilo que a Microsoft publicou. O texto do fornecedor confirma três elementos: a verificação de autorização estava ausente, o chamador precisa apenas de privilégios baixos, e o impacto ultrapassa uma fronteira de autoridade de segurança. Ele não confirma a troca de token, a herança de identidade, nem os exemplos de runbook e telemetria. A entrada do arquivo é a fonte desses elementos, e o arquivo é um conjunto de dados secundário, não o fornecedor.

Uma busca por reportagem independente encontra o mesmo parágrafo em mais de um lugar: a manchete sobre o fluxo OBO e o raio de impacto aparece sindicada no forkast.news e no Yahoo Tech, entre outros. A sindicação faz dessa cobertura uma única fonte, não várias. Nenhum veículo analisado para este artigo publicou sua própria telemetria, prova de conceito ou reprodução do mecanismo.

O que está estabelecido, o que é descrito e o que nunca foi afirmado

O arquivo atribui a este registro a nota A — bem documentado, as fontes primárias concordam — e não o marca como disputado. Ele não registra nenhum dano no mundo real. Essa nota diz respeito aos fatos centrais do registro, e estes de fato concordam entre as fontes; não é uma afirmação de que cada frase da entrada tenha sido reproduzida de forma independente.

• Estabelecido pelo fornecedor. CVE-2026-62830 afeta o Azure SRE Agent, é CWE-862 autorização ausente, possui pontuação base CVSS 3.1 de 9,9 e pontuação temporal de 8,6, não exigiu ação do cliente, não foi divulgado publicamente e não foi registrado como explorado.

• Estabelecido por relatórios e enriquecimento de segurança independentes.O resumo de Patch Tuesday de agosto de 2026 da Cisco Talos lista a CVE com o mesmo 9,9 e a mesma fraqueza de autorização ausente, e a coloca sob a avaliação de exploração "menos provável" da Microsoft. A avaliação SSVC da CISA, registrada por meio do NVD, classifica a exploração como nenhuma, a automatização como não e o impacto técnico como total. O enriquecimento do OpenCVE lista uma pontuação EPSS de 0,00778 e registra que a CVE não está no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA.

• Descrito, mas não confirmado de forma independente. A falha na troca de tokens OBO, a herança da identidade gerenciada do agente e as consequências para o runbook, a telemetria e a infraestrutura vêm do verbete do arquivo e da cobertura secundária sindicada. O aviso da Microsoft não os menciona. Eles são a parte mais útil do registro e a parte menos documentada dele.

• Não estabelecido em lugar algum. Nenhuma exploração, nenhuma vítima, nenhuma prova de conceito pública, nenhum número de compilação e nenhum intervalo de versões afetadas. A linha de explorabilidade da Microsoft — divulgada publicamente: Não, explorada: Não, menos provável — é a coisa mais próxima de um relatório de status que existe.

• A cobertura da mídia tradicional está ausente. Buscas por este CVE na imprensa geral de tecnologia e segurança não retornaram nenhum artigo do The Register, BleepingComputer, SecurityWeek ou Help Net Security. Sua presença pública é o alerta do fornecedor, bancos de dados de vulnerabilidades, uma compilação da Patch Tuesday e o artigo sindicado. Para um 9,9, isso é incomum, e é um fato sobre o registro, não um julgamento sobre o risco.

A correção, e as verificações que duram mais do que ela

Como o Azure SRE Agent é um serviço hospedado, a correção foi aplicada do lado da Microsoft. Não há atualização para instalar, nenhum número de build para comparar com um inventário e nenhuma forma de um cliente confirmar de fora que um tenant estava protegido antes de uma determinada data. A posição da Microsoft é que nenhuma ação é necessária e, no que diz respeito à vulnerabilidade em si, essa posição está correta.

A entrada do arquivo acrescenta orientações que o aviso não detalha: auditar atribuições de identidade gerenciada, revisar o RBAC em relação ao que o agente realmente precisa e monitorar escalonamento anômalo de privilégios. Essa orientação é do arquivo, não uma citação da Microsoft.

A consequência prática decorre da arquitetura, e não da recomendação de qualquer fonte, portanto trate-a como inferência. Se a autoridade do agente são suas atribuições de função, então os controles duradouros são o escopo dessas atribuições e a retenção dos logs do plano de controle que mostrariam que elas estão sendo usadas. Uma correção do lado do serviço fecha o caminho; ela não restringe retroativamente uma identidade gerenciada que foi superprovisionada, e não pode ajudar uma organização que não manteve os logs. Ambas as coisas continuam sendo responsabilidade do cliente depois que a CVE é fechada.

Onde se situa no lote de agosto de 2026

O resumo da Talos torna a comparação inevitável. Naquele mês, ele também lista CVE-2026-59118 no Copilot Cowork, uma elevação de privilégio por autorização inadequada com pontuação 9,3, e CVE-2026-56162 no Azure SQL Database, uma elevação de privilégio com pontuação 10,0. A única vulnerabilidade que a Talos relata como explorada na natureza naquele mês não era nenhuma dessas: era CVE-2026-68820, no Windows AFD para WinSock. As entradas de produtos de IA na lista da Talos são falhas de autorização, e essa é a forma específica do risco que este registro documenta.

Nada disso faz do CVE-2026-62830 uma violação. É um CVE de transparência para um serviço que já foi corrigido, publicado para que os clientes possam ver o que estava errado e verificar suas próprias configurações. O valor do registro está na questão de configuração que ele deixa para trás — o que a identidade do agente poderia alcançar, e se alguém teria notado que ela estava sendo usada — não em um patch a agendar.