Um pesquisador de segurança afirma que a Microsoft corrigiu discretamente uma vulnerabilidade no Azure Backup for AKS depois de rejeitar seu relato e impedir a emissão de um CVE.
No relatório, o pesquisador descreve uma falha crítica de escalonamento de privilégios que permitia obter acesso de cluster-admin a partir da função de baixo privilégio “Backup Contributor”.
A Microsoft contesta a acusação.
A empresa afirmou que o comportamento era esperado e que “nenhuma mudança no produto foi feita”, apesar de o pesquisador ter documentado novas verificações de permissão e tentativas de exploração malsucedidas após a divulgação, o que sugere um patch silencioso.
O pesquisador de segurança Justin O'Leary descobriu a falha em março deste ano e a reportou à Microsoft em 17 de março.
O Microsoft Security Response Center (MSRC) rejeitou o relato em 13 de abril, alegando que o problema só envolvia obter privilégios de cluster-admin em um cluster no qual “o invasor já possuía acesso de administrador”.
Para O'Leary, essa caracterização distorce completamente o ataque.
“Isso está factualmente incorreto”, afirma o pesquisador.
“A vulnerabilidade permite que um usuário sem nenhum privilégio no Kubernetes obtenha cluster-admin.
O ataque não exige acesso prévio ao cluster.
Ele concede esse acesso.”
O'Leary também diz que a Microsoft descreveu a submissão ao MITRE como “conteúdo gerado por IA”, algo que, segundo ele, não tratava do mérito técnico do relatório.
Depois da rejeição, O'Leary levou o caso ao CERT Coordination Center, que validou a vulnerabilidade de forma independente em 16 de abril e, segundo o pesquisador, atribuiu o identificador VU#284781.
O CERT/CC havia programado a divulgação pública para 1º de junho de 2026, mas isso nunca ocorreu.
Em 4 de maio, funcionários da Microsoft teriam contatado o MITRE recomendando que o CVE não fosse atribuído, novamente com o argumento de que o problema exigia acesso administrativo prévio.
Mais tarde, o CERT/CC encerrou o caso sob as regras de hierarquia da CNA, deixando, na prática, a Microsoft, que é uma CNA, com a autoridade final sobre a emissão de CVEs para seus próprios produtos.
O Azure Backup for AKS usa Trusted Access para conceder privilégios de cluster-admin às extensões de backup dentro dos clusters Kubernetes.
Segundo O'Leary, a falha permitia que qualquer pessoa com apenas a função Backup Contributor em um cofre de backup acionasse esse relacionamento de Trusted Access sem já possuir permissões no Kubernetes.
Com isso, um invasor poderia habilitar o backup em um cluster AKS-alvo e fazer com que a Azure configurasse automaticamente o Trusted Access com privilégios de cluster-admin.
A partir daí, seria possível extrair segredos por meio de operações de backup ou restaurar cargas maliciosas no cluster.
O'Leary classificou o problema como uma vulnerabilidade de Confused Deputy, identificada como CWE-441, em que as fronteiras de confiança entre o Azure RBAC e o Kubernetes RBAC interagiam de forma a contornar os controles de autorização esperados.
A Microsoft foi contatada para esclarecer se a empresa considera a descoberta uma vulnerabilidade de segurança válida.
Segundo o site, um porta-voz da Microsoft disse: “Nossa avaliação concluiu que isso não é uma vulnerabilidade de segurança, mas sim um comportamento esperado que exige privilégios administrativos já existentes no ambiente do cliente.
Portanto, nenhuma mudança no produto foi feita para resolver este relato e nenhum CVE ou pontuação CVSS foi emitido.”
No entanto, após a divulgação de seu relatório neste mês, O'Leary observou que o caminho original de ataque deixou de funcionar.
“O comportamento atual retorna erros que não existiam em março de 2026”, afirma.
Segundo O'Leary, o Azure Backup for AKS agora exige que o Trusted Access seja configurado manualmente antes que o backup possa ser habilitado, revertendo o comportamento anterior, no qual a Azure fazia essa configuração automaticamente.
Ele também observou verificações adicionais de permissão que não existiam durante seus testes originais em março.
Agora, o MSI do cofre exige permissões de Reader tanto no cluster AKS quanto no grupo de recursos dos snapshots, enquanto o MSI do cluster AKS exige permissões de Contributor no grupo de recursos dos snapshots.
Em outras palavras, a vulnerabilidade parece ter sido corrigida, mas a Microsoft não emitiu um comunicado público nem notificou os clientes.
Sem um CVE ou um aviso oficial, as equipes de defesa têm pouca visibilidade sobre a janela de exposição ou sobre o cronograma de correção.
“Organizações que concederam Backup Contributor entre uma data inicial desconhecida e maio de 2026 estiveram expostas a escalonamento de privilégios”, escreveu o pesquisador.
“Sem um CVE, as equipes de segurança não conseguem acompanhar essa exposição.
O patch silencioso protege os fornecedores, não os clientes.”
O caso expõe um problema estrutural sem solução simples.
Nos últimos anos, tornaram-se comuns as disputas entre pesquisadores de segurança e grandes fornecedores sobre gravidade, explorabilidade e divulgação, especialmente à medida que os programas de divulgação de vulnerabilidades passaram a lidar com um volume crescente de relatos.
Alguns mantenedores de projetos open source também têm reclamado publicamente que relatos auxiliados por IA estão sobrecarregando os sistemas de bug bounty e triagem de segurança, dificultando que descobertas legítimas recebam atenção em tempo hábil.
Casos em que grandes empresas de tecnologia ignoraram a correção de falhas válidas, apesar de contatos repetidos de diferentes pesquisadores, também não são raros.
Sem uma estrutura que realinhe os incentivos de todas as partes, a divulgação responsável corre o risco de se tornar um exercício burocrático que não serve a ninguém, menos ainda às organizações deixadas expostas no escuro.
Publicidade
Conheça a Solyd One, e tenha acesso a todos os cursos de segurança ofensiva da Solyd, todas as certificações práticas, incluindo a SYCP, 2 CTFs anuais com prêmios de até 30 mil reais, dezenas de laboratórios realísticos, suporte, comunidade e muito mais. Saiba mais...