Microsoft disclosed CVE-2026-33105 on April 3, 2026 — a critical improper authorization vulnerability in Azure Kubernetes Service that carries the maximum CVSS score of 10.0. The flaw exists in how AKS validates role-based access control (RBAC) enforcement for certain Kubernetes API requests, allowing an attacker to escalate from a standard user to full cluster administrator.

If you run AKS clusters, stop reading and start patching.

What Happened

The vulnerability is rooted in how AKS handles Kubernetes API requests related to cluster role bindings and service account permissions. Under specific conditions, the RBAC enforcement layer fails to correctly validate authorization checks, allowing an attacker to manipulate these requests and bind themselves to the cluster-admin ClusterRole — or create new privileged service accounts — without having the permissions to do so.

The attack surface is the Kubernetes API server itself. An attacker with any level of authenticated access to the cluster (even a minimally privileged namespace-scoped role) can craft API requests that exploit the authorization gap. The result is full administrative control over the cluster, including the ability to read secrets, deploy workloads, modify network policies, and pivot to other Azure resources via managed identities.

There are conflicting reports on whether the vulnerability requires prior authentication. Microsoft’s advisory classifies it as requiring authenticated access, but some researchers have noted scenarios where the bypass may be reachable from unauthenticated contexts depending on cluster configuration — particularly clusters with anonymous auth enabled or overly permissive API server access.

Technical Details

  • CVE: CVE-2026-33105
  • CVSS: 10.0 (Critical)
  • Attack vector: Network
  • Attack complexity: Low
  • Privileges required: Low (potentially None in misconfigured clusters)
  • User interaction: None
  • Component: Azure Kubernetes Service RBAC enforcement layer
  • Impact: Complete cluster compromise — confidentiality, integrity, and availability

The flaw is classified as CWE-285 (Improper Authorization). The core issue is that certain API paths related to ClusterRoleBinding and ServiceAccount resources do not pass through the full RBAC evaluation chain. This means requests that should be denied by the API server’s authorization webhook are instead processed and applied.

Who Is Affected

Any organization running Azure Kubernetes Service clusters. The vulnerability affects the AKS control plane’s RBAC implementation, meaning this is not something you can fix by patching your node images or updating your application containers. This requires a control plane update pushed through Azure’s update channels.

The scope of exposure is significant. AKS is one of the most widely deployed managed Kubernetes platforms, and RBAC is the primary authorization mechanism for virtually every production cluster. If you are running AKS with RBAC enabled (which is the default), you are potentially affected.

Multi-tenant clusters are at the highest risk. Any tenant with even minimal API access could escalate to control the entire cluster, accessing other tenants’ secrets, workloads, and network resources.

Mitigation

Patch immediately. Microsoft has released security updates for CVE-2026-33105 through the standard Azure Update Manager. Apply the update to all AKS clusters without delay.

While you’re patching:

  1. Audit cluster role bindings. Look for any unexpected ClusterRoleBinding or RoleBinding resources created recently. Pay special attention to bindings that reference the cluster-admin role or grant wildcard permissions.

    1

    kubectl get clusterrolebindings -o json | jq '.items[] | select(.metadata.creationTimestamp > "2026-03-15") | {name: .metadata.name, role: .roleRef.name, subjects: .subjects}'

  2. Review API server audit logs. Look for unusual RBAC-related API calls — particularly create or update operations on clusterrolebindings and serviceaccounts from unexpected users or service accounts.

  3. Restrict API server access. If you haven’t already, enable authorized IP ranges for the API server to limit who can reach it at the network level. This reduces the attack surface regardless of the RBAC bypass.

  4. Disable anonymous authentication. Ensure --anonymous-auth=false is set if your cluster configuration allows it, to close the potential unauthenticated attack path.

  5. Check managed identity permissions. If an attacker achieved cluster-admin, they may have used node-level managed identities to pivot into other Azure resources. Review Azure Activity Logs for suspicious resource access originating from AKS node resource groups.

The Bigger Picture

A CVSS 10.0 on a managed Kubernetes service’s authorization layer is about as bad as it gets for cloud infrastructure. RBAC is the trust boundary that everything else in a Kubernetes cluster depends on — network policies, secret management, workload isolation, admission control. When the authorization layer itself is broken, every other security control built on top of it becomes unreliable.

This is also a reminder that managed Kubernetes doesn’t mean the control plane is someone else’s problem. You still need to monitor for anomalous RBAC changes, maintain audit logging, and have the operational muscle to push control plane updates quickly when critical patches drop.

Patch your clusters. Audit your bindings. Check your logs.

References