Ethical Hacking News
A recent discovery by security researcher Justin O'Leary highlights a critical vulnerability in Azure Backup for AKS that was initially rejected by Microsoft. Despite this, changes have been made to the service's configuration, suggesting an attempt to mitigate the issue. However, the lack of transparency and communication from Microsoft raises concerns about its approach to security reporting and customer awareness. The case underscores the need for better practices in responsible disclosure and the importance of continuous monitoring and patching.
A vulnerability in Azure Backup for AKS (Azure Kubernetes Service) was initially rejected by Microsoft's Security Response Center, despite being discovered by security researcher Justin O'Leary. The issue lies at the intersection of Azure Role-Based Access Control (RBAC) and Kubernetes RBAC, allowing a user with zero Kubernetes permissions to gain cluster-admin access via exploited Trusted Access configuration. Microsoft rejected the initial report, claiming the issue only involves obtaining cluster-admin on a cluster where an attacker already holds administrator access, misrepresenting the attack entirely. The vulnerability was later validated by CERT Coordination Center (CERT) and assigned a tracking identifier, VU#284781, confirming Azure Backup for AKS suffers from a Confused Deputy vulnerability. Microsoft reportedly recommended against CVE assignment or public disclosure of the issue, suggesting it may not consider it critical enough. After the report was made public, Microsoft changed its behavior by requiring manual configuration of Trusted Access and adding additional permission checks, reversing the earlier automated configuration. Despite this change, Microsoft has neither issued a public advisory nor notified its customers about the vulnerability, raising questions about transparency and responsible disclosure practices.
In a recent revelation, security researcher Justin O'Leary has come forward to expose a critical vulnerability in Azure Backup for AKS (Azure Kubernetes Service) that was initially rejected by Microsoft's Security Response Center. The issue lies at the intersection of Azure Role-Based Access Control (RBAC) and Kubernetes RBAC, which can lead to privileged escalation when utilizing Trusted Access to grant backup extensions cluster-admin privileges within Kubernetes clusters.
According to O'Leary, this vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin access. The attack does not require existing cluster access; it grants it by exploiting the Azure Backup for AKS configuration, which automatically configures Trusted Access with cluster-admin privileges upon enabling backup on a target AKS cluster. This exploit can lead to unauthorized access and control over critical systems within an organization's Kubernetes environment.
O'Leary discovered this vulnerability in March and reported it to Microsoft on March 17. However, after the initial submission, Microsoft rejected his report, arguing that the issue only involves obtaining cluster-admin on a cluster where "the attacker already held administrator access." This characterization misrepresents the attack entirely, as it highlights the potential for privilege escalation through an unsecured Trusted Access relationship.
Following this rejection, O'Leary escalated the issue to CERT Coordination Center (CERT), which independently validated the vulnerability and assigned it a tracking identifier, VU#284781. The validation process confirmed that Azure Backup for AKS indeed suffers from a Confused Deputy vulnerability (CWE-441), where trust boundaries in RBAC interact in a manner that bypasses expected authorization controls.
In response to O'Leary's findings, Microsoft reportedly contacted MITRE recommending against CVE assignment, stating that the issue required pre-existing administrative privileges within the customer's environment. This stance suggests that Microsoft may not consider this vulnerability critical enough for a CVE (Common Vulnerability and Exposure) designation or public disclosure.
However, in a surprising turn of events, O'Leary observed that the original attack path no longer works after his report was made public. Azure Backup for AKS now requires Trusted Access to be manually configured before backup can be enabled, reversing the earlier behavior where Azure configured it automatically. Furthermore, additional permission checks were added, including Reader permissions on both the AKS cluster and snapshot resource group for the vault MSI, while the AKS cluster MSI requires Contributor permissions on the snapshot resource group.
Despite this change in behavior, Microsoft has neither issued a public advisory nor notified its customers about the vulnerability. This lack of transparency raises questions about Microsoft's approach to security reporting and customer awareness. It also highlights a structural problem with responsible disclosure practices, where the interests of vendors (in this case, Microsoft) often seem to outweigh those of their customers and the broader cybersecurity community.
The case underscores the ongoing challenges in effective vulnerability disclosure and the need for better communication channels between researchers, vendors, and consumers of security products. It also emphasizes the importance of continuous monitoring and patching, especially when critical vulnerabilities like this one are ignored or downplayed by major players.
In conclusion, the Azure Backup for AKS vulnerability represents a complex example of how seemingly minor configuration settings can be exploited to compromise even the most secure systems. While Microsoft's actions have been interpreted as dismissive and vendor-centric, it is essential to recognize that the root cause lies in a deeper systemic issue – one that demands attention from all stakeholders involved in cybersecurity.
Related Information:
https://www.ethicalhackingnews.com/articles/Azure-Backup-for-AKS-Vulnerability-A-Case-of-Exploited-Expectation-ehn.shtml
https://www.bleepingcomputer.com/news/security/microsoft-rejects-critical-azure-vulnerability-report-no-cve-issued/
https://m.youtube.com/watch?v=qvd_xSVVvAE
Published: Sat May 16 16:21:47 2026 by llama3.2 3B Q4_K_M
