Um pesquisador de segurança alega que a **Microsoft** corrigiu discretamente uma vulnerabilidade no **Azure Backup** para AKS após rejeitar seu relatório e impedir a emissão de um CVE. O relatório do pesquisador descreve uma falha crítica de escalonamento de privilégios que permitia acesso de administrador de cluster a partir da função de "Colaborador de Backup" de baixa permissão. A Microsoft contesta a alegação, informando ao BleepingComputer que o comportamento era esperado e que "nenhuma alteração no produto foi feita", apesar do pesquisador documentar novas verificações de permissão e tentativas de exploração falhas após a divulgação, o que sugere um patch silencioso. ## CERT Concorda que é um Bug, Mas Microsoft Bloqueia CVE O pesquisador de segurança **Justin O'Leary** descobriu a falha de segurança em março e a relatou à **Microsoft** em 17 de março. O Centro de Resposta de Segurança da Microsoft (MSRC) rejeitou o relatório em 13 de abril, alegando que o problema envolvia apenas a obtenção de acesso de administrador de cluster em um cluster onde "o invasor já possuía acesso de administrador", uma caracterização que O'Leary afirma que representa totalmente mal o ataque. "Isso está factualmente incorreto", afirma o pesquisador. "A vulnerabilidade permite que um usuário sem permissões Kubernetes obtenha acesso de administrador de cluster. O ataque não requer acesso de cluster existente - ele o concede." O'Leary acrescenta que a Microsoft descreveu a submissão ao **MITRE** como "conteúdo gerado por IA", algo que, segundo ele, não abordou os méritos técnicos do relatório. Após a rejeição, O'Leary escalou o problema para o **CERT Coordination Center**, que validou independentemente a vulnerabilidade em 16 de abril e, de acordo com o pesquisador, atribuiu a ela um identificador, VU#284781:  O **CERT/CC** inicialmente agendou a divulgação pública para 1º de junho de 2026, mas essa divulgação nunca aconteceu. Em 4 de maio, funcionários da Microsoft teriam contatado o **MITRE** recomendando contra a atribuição de CVE, argumentando novamente que o problema exigia acesso administrativo pré-existente:  O **CERT/CC** posteriormente encerrou o caso sob as regras da hierarquia CNA, deixando efetivamente a **Microsoft** (que é uma CNA) com a autoridade final sobre a emissão de CVE para seus próprios produtos. ## Como o Ataque Funcionava O **Azure Backup** para AKS usa Acesso Confiável para conceder privilégios de administrador de cluster às extensões de backup dentro de clusters Kubernetes. De acordo com O'Leary, a falha permitia que qualquer pessoa com apenas a função de Colaborador de Backup em um cofre de backup acionasse esse relacionamento de Acesso Confiável sem ter permissões Kubernetes prévias. Um invasor poderia habilitar o backup em um cluster AKS alvo, fazendo com que o Azure configurasse automaticamente o Acesso Confiável com privilégios de administrador de cluster. A partir daí, um invasor poderia extrair segredos por meio de operações de backup ou restaurar cargas de trabalho maliciosas no cluster. O'Leary classificou o problema como uma vulnerabilidade de **Confused Deputy** (CWE-441), onde os limites de confiança do RBAC do Azure e do RBAC do Kubernetes interagiram de uma maneira que contornou os controles de autorização esperados. ## Microsoft Diz que Nenhuma Mudança Foi Feita, Comportamento Diz o Contrário O BleepingComputer contatou a Microsoft para entender se a gigante da tecnologia considerava essa descoberta uma vulnerabilidade de segurança válida. Um porta-voz da Microsoft disse ao BleepingComputer: "Nossa avaliação concluiu que esta não é uma vulnerabilidade de segurança, mas sim um comportamento esperado que requer privilégios administrativos pré-existentes dentro do ambiente do cliente. Portanto, nenhuma alteração no produto foi feita para abordar este relatório e nenhum CVE ou pontuação CVSS foram emitidos." No entanto, após a divulgação de seu relatório este mês, O'Leary observou que o caminho de ataque original não funciona mais. "O comportamento atual retorna erros que não existiam em março de 2026", afirma ele: ERRO: UserErrorTrustedAccessGatewayReturnedForbidden "A ligação de função de Acesso Confiável está faltando/foi removida" De acordo com O'Leary, o **Azure Backup** para AKS agora requer que o Acesso Confiável seja configurado manualmente antes que o backup possa ser habilitado, revertendo o comportamento anterior onde o Azure o configurava automaticamente. Ele também observou verificações de permissão adicionais que estavam ausentes durante seus testes originais em março. O MSI do cofre agora requer permissões de Leitor no cluster AKS e no grupo de recursos de snapshot, enquanto o MSI do cluster AKS requer permissões de Colaborador no grupo de recursos de snapshot. Em outras palavras, a vulnerabilidade parece ter sido corrigida, mas a **Microsoft** não emitiu um aviso público nem notificou os clientes. ## O Problema de Visibilidade para Defensores Sem um CVE ou aviso, os defensores têm pouca visibilidade sobre a janela de exposição ou o cronograma de remediação. "Organizações que concederam a função de Colaborador de Backup entre uma data de início desconhecida e maio de 2026 foram expostas a escalonamento de privilégios", escreve o pesquisador. "Sem um CVE, as equipes de segurança não podem rastrear essa exposição. Patches silenciosos protegem fornecedores, não clientes." O caso destaca um problema estrutural sem solução fácil. Disputas entre pesquisadores de segurança e grandes fornecedores sobre gravidade, explorabilidade e divulgação tornaram-se comuns nos últimos anos, especialmente à medida que os programas de divulgação de vulnerabilidades enfrentam volumes crescentes de relatórios. Alguns mantenedores de código aberto também reclamaram publicamente que relatórios assistidos por IA estão sobrecarregando os sistemas de caça a bugs e triagem de segurança, tornando mais difícil para descobertas legítimas receberem atenção oportuna. Casos em que grandes empresas ignoraram a correção de falhas válidas, apesar de contatos repetidos por diferentes pesquisadores, também não são incomuns. Sem um framework que realinhe os incentivos para 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 - muito menos às organizações deixadas expostas no escuro.  ## A Lacuna de Validação: Pentest Automatizado Responde a Uma Pergunta. Você Precisa de Seis. Ferramentas de pentest automatizadas entregam valor real, mas foram criadas para responder a uma pergunta: um invasor pode se mover pela rede? Elas não foram criadas para testar se seus controles bloqueiam ameaças, se suas regras de detecção disparam ou se suas configurações de nuvem se sustentam. Este guia abrange as 6 superfícies que você realmente precisa validar. [Baixe Agora](https://hubs.li/Q048zztN0)