Microsoft Ignora Vulnerabilidade Crítica no Azure, Segundo Pesquisador
Um pesquisador de segurança alega que a Microsoft corrigiu silenciosamente uma vulnerabilidade crítica no Azure Backup for AKS, mas se recusou a reconhecer o problema ou emitir um CVE. A falha permitia a escalada de privilégios em clusters Kubernetes, expondo dados e possibilitando a implantação de cargas maliciosas. A Microsoft nega a existência da vulnerabilidade e não emitiu nenhum aviso.
MundiX News·20 de maio de 2026·3 min de leitura·👁 7 views
O pesquisador de segurança Justin O'Leary afirma que a Microsoft corrigiu discretamente uma vulnerabilidade crítica no Azure Backup for AKS, mas se recusou a reconhecer o problema e a atribuir um identificador CVE.
De acordo com o especialista, o bug permitia a obtenção de direitos de cluster-admin em um cluster Kubernetes, mesmo com uma função de baixo privilégio Backup Contributor. Isso significa que um atacante não precisava de nenhum direito dentro do próprio Kubernetes. O problema afetava o Azure Backup for AKS, um serviço de backup para clusters Kubernetes no Azure. Para funcionar, ele utiliza o mecanismo Trusted Access, que concede às extensões de backup direitos de cluster-admin dentro do cluster.
O'Leary descobriu o bug em março de 2026 e o relatou aos especialistas da Microsoft. No entanto, em 13 de abril, o Microsoft Security Response Center (MSRC) rejeitou o relatório. A empresa afirmou que se tratava de uma situação em que o atacante "já tinha acesso administrativo ao ambiente", portanto, o problema não era uma vulnerabilidade. O pesquisador descreve essa descrição como incorreta. Após a rejeição, o pesquisador entrou em contato com o CERT Coordination Center (CERT/CC). Lá, a existência do problema foi confirmada de forma independente e foi atribuído o identificador VU#284781. Inicialmente, a divulgação pública da vulnerabilidade estava agendada para 1º de junho de 2026, mas a situação mudou.
O'Leary afirma que, em 4 de maio, representantes da Microsoft entraram em contato com a MITRE e recomendaram que o problema não recebesse um identificador CVE, afirmando novamente que sua exploração exigia a obtenção prévia de direitos de administrador. Posteriormente, o CERT/CC fechou o pedido de acordo com as regras da hierarquia CNA: como a Microsoft atua como CNA para seus produtos, a decisão final sobre a emissão de um identificador CVE ficou com a empresa. O próprio O'Leary classificou o problema como Confused Deputy (CWE-441, de acordo com a MITRE), ou seja, uma situação em que a interação entre Azure RBAC e Kubernetes RBAC levou à contornar os controles de autorização esperados. Oficialmente, a Microsoft continua a negar a existência do bug. Em um comentário para a publicação Bleeping Computer, representantes da empresa afirmaram que "nenhuma alteração foi feita no produto" e que o comportamento descrito é padrão. Portanto, a empresa não atribuiu ao problema nem CVE nem uma pontuação CVSS.
No entanto, o próprio pesquisador observa que, após a divulgação do problema, o vetor de ataque original parou de funcionar. Agora, o Azure relata erros como UserErrorTrustedAccessGatewayReturnedForbidden, e o Trusted Access precisa ser configurado manualmente antes da ativação do backup. Anteriormente, isso acontecia automaticamente no Azure. Além disso, verificações de permissão adicionais apareceram, que não existiam durante os testes originais em março. Ou seja, o problema parece ter sido corrigido, mas sem qualquer notificação pública aos clientes. O'Leary enfatiza que, devido à ausência de um CVE e de um boletim de segurança, é difícil para os defensores entender quais sistemas podem ter sido vulneráveis e por quanto tempo permaneceram em risco. "Correções silenciosas protegem os fornecedores, mas não os clientes", resume o especialista.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
O pesquisador de segurança Justin O'Leary afirma que a Microsoft corrigiu discretamente uma vulnerabilidade crítica no Azure Backup for AKS, mas se recusou a reconhecer o problema e a atribuir um identificador CVE.
De acordo com o especialista, o bug permitia a obtenção de direitos de cluster-admin em um cluster Kubernetes, mesmo com uma função de baixo privilégio Backup Contributor. Isso significa que um atacante não precisava de nenhum direito dentro do próprio Kubernetes. O problema afetava o Azure Backup for AKS, um serviço de backup para clusters Kubernetes no Azure. Para funcionar, ele utiliza o mecanismo Trusted Access, que concede às extensões de backup direitos de cluster-admin dentro do cluster.
O'Leary descobriu o bug em março de 2026 e o relatou aos especialistas da Microsoft. No entanto, em 13 de abril, o Microsoft Security Response Center (MSRC) rejeitou o relatório. A empresa afirmou que se tratava de uma situação em que o atacante "já tinha acesso administrativo ao ambiente", portanto, o problema não era uma vulnerabilidade. O pesquisador descreve essa descrição como incorreta. Após a rejeição, o pesquisador entrou em contato com o CERT Coordination Center (CERT/CC). Lá, a existência do problema foi confirmada de forma independente e foi atribuído o identificador VU#284781. Inicialmente, a divulgação pública da vulnerabilidade estava agendada para 1º de junho de 2026, mas a situação mudou.
O'Leary afirma que, em 4 de maio, representantes da Microsoft entraram em contato com a MITRE e recomendaram que o problema não recebesse um identificador CVE, afirmando novamente que sua exploração exigia a obtenção prévia de direitos de administrador. Posteriormente, o CERT/CC fechou o pedido de acordo com as regras da hierarquia CNA: como a Microsoft atua como CNA para seus produtos, a decisão final sobre a emissão de um identificador CVE ficou com a empresa. O próprio O'Leary classificou o problema como Confused Deputy (CWE-441, de acordo com a MITRE), ou seja, uma situação em que a interação entre Azure RBAC e Kubernetes RBAC levou à contornar os controles de autorização esperados. Oficialmente, a Microsoft continua a negar a existência do bug. Em um comentário para a publicação Bleeping Computer, representantes da empresa afirmaram que "nenhuma alteração foi feita no produto" e que o comportamento descrito é padrão. Portanto, a empresa não atribuiu ao problema nem CVE nem uma pontuação CVSS.
No entanto, o próprio pesquisador observa que, após a divulgação do problema, o vetor de ataque original parou de funcionar. Agora, o Azure relata erros como UserErrorTrustedAccessGatewayReturnedForbidden, e o Trusted Access precisa ser configurado manualmente antes da ativação do backup. Anteriormente, isso acontecia automaticamente no Azure. Além disso, verificações de permissão adicionais apareceram, que não existiam durante os testes originais em março. Ou seja, o problema parece ter sido corrigido, mas sem qualquer notificação pública aos clientes. O'Leary enfatiza que, devido à ausência de um CVE e de um boletim de segurança, é difícil para os defensores entender quais sistemas podem ter sido vulneráveis e por quanto tempo permaneceram em risco. "Correções silenciosas protegem os fornecedores, mas não os clientes", resume o especialista.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
