Kubernetes RBAC in 2026: From nodes/proxy to AKS CVE-10.0 — Three Real Paths to Cluster-Admin

TL;DR

Three Kubernetes privilege escalation paths landed in early 2026, and they all start from permissions your monitoring stack already has. Graham Helton's January disclosure showed that the standard nodes/proxy GET permission — granted by default to most observability tools — is a direct path to cluster-wide RCE. CVE-2026-33105 hit Azure Kubernetes Service in April with a CVSS 10.0 critical rating and a network-attack vector. Kyverno's ConfigMap context loader accepts any namespace with zero validation, breaking multi-tenant isolation by design. The common failure mode: RBAC permissions are evaluated at grant time, not at use time, and most clusters have at least one role whose practical privilege exceeds its intended scope.

Why RBAC Audits Are Worth Doing Right Now

Kubernetes RBAC was designed to be least-privilege by default. In practice, three patterns make every production cluster permissive:

• Operator-shaped charts. Helm charts for monitoring, security, and policy engines often request broad get/list across the cluster because their controllers reconcile cluster-scoped state. The chart values rarely surface the security cost of those grants.
• Aggregated cluster roles. Adding aggregationRule matchers makes role expansion feel automatic, but it also means a new label on a CRD silently widens an aggregated cluster-admin alias.
• Implicit privilege through proxy/exec/portforward. The most-overlooked vector. A role that grants nodes/proxy doesn't look like cluster-admin in the YAML. In practice, it is.

Path 1: nodes/proxy → Cluster-Wide RCE (Graham Helton, January 2026)

Security researcher Graham Helton disclosed in January 2026 that the standard Kubernetes RBAC permission nodes/proxy with the get verb is functionally equivalent to cluster-wide RCE. That permission is granted by default to many observability and monitoring components — Prometheus node exporters, container runtime debuggers, kubelet metrics collectors, and almost every "cluster monitoring" Helm chart that ships with a default ServiceAccount.

The mechanism: nodes/proxy lets the holder forward arbitrary HTTP requests through the API server to the kubelet on each node. The kubelet exposes endpoints for container exec, portforward, log streaming, and metrics. With nodes/proxy GET, an attacker can:

1. Enumerate the kubelets in the cluster via the API server's nodes endpoint.
2. Forward an exec request through the API server to any node's kubelet.
3. Land in any pod on any node — including pods running in kube-system with privileged service accounts (the controller manager, scheduler, etc.).
4. Use those service account tokens to elevate to cluster-admin.

The catch is that nodes/proxy is in the default ClusterRoles for literally every popular monitoring stack. If you compromise a single Prometheus pod, an exec-into-Prometheus container token, or any process that holds a token bound to a role with nodes/proxy, you have cluster-admin within minutes.

Fast audit:

kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name as $r | $r | test("prom|monitor|debug")) | \
         .subjects[]?.name + " → " + .roleRef.name'

Anything that pops out is a candidate for the next audit pass.

Path 2: CVE-2026-33105 — Azure Kubernetes Service (CVSS 10.0)

Published April 3, 2026. CVSS 10.0. An improper authorization flaw in AKS that allows an unauthorized attacker to elevate privileges within the AKS environment over a network. The CVSS 10.0 rating tells the story: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network attack vector. No privileges required. No user interaction. Scope changed (you escalate past your tenant).

Microsoft has not published a complete technical write-up at the time of this post — public disclosure was paired with the patch. The known facts:

• Affected: AKS clusters across multiple regions and AKS versions prior to the April 2 backend rollout.
• Mitigation: AKS auto-rotates control-plane components for managed clusters; the patch landed transparently for most customers. You still need to verify your control-plane version is past the fix line.
• The vector is the AKS managed-control-plane authorization layer, not Kubernetes core RBAC. So this fix is on Microsoft's side; your action is verification.

Verify your AKS cluster:

az aks show --resource-group $RG --name $CLUSTER \
  --query 'currentKubernetesVersion'
# Compare against the AKS release notes for CVE-2026-33105 patched line.

If you run AKS at scale, audit your egress for inbound network attempts during late March / early April 2026 — that's the window where opportunistic exploitation is most likely.

Path 3: Kyverno ConfigMap Context Bypass

Policy engines like Kyverno run with privileged service accounts because they reconcile cluster-wide policy state. Kyverno's ConfigMap context loader accepts any value for configMap.namespace with no validation against the calling tenant's permissions. Result: a namespace admin can use Kyverno's privileged service account to read ConfigMaps in any other namespace, including kube-system.

The exploitation path:

1. An attacker has namespace-admin in tenant-a (legitimate, low-privilege scope).
2. They author a Kyverno policy that uses a configMap context with namespace: kube-system and a name targeting cluster-wide secrets stored as ConfigMaps (kubeadm-config, cluster-info, etc.).
3. Kyverno's controller fetches that ConfigMap using its own privileged service account.
4. The fetched data is exposed to the policy author through the Kyverno reporting / event surface.

For multi-tenant Kubernetes clusters, this is a complete RBAC bypass — the namespace boundary is the trust boundary, and Kyverno's privileged service account erases it.

Detection

1. Audit log queries (high-confidence)

The Kubernetes API server audit log is the canonical detection surface. Three queries catch the classes above:

# Use of nodes/proxy by anything that isn't kube-system
resourceAttributes.resource = "nodes"
  AND resourceAttributes.subresource = "proxy"
  AND user.username NOT match "^system:kube-"

# Direct kubelet exec via API server proxy
requestURI match "/api/v1/nodes/.*/proxy/.*/(exec|portforward)"

# Cross-namespace ConfigMap reads by Kyverno service account
user.username = "system:serviceaccount:kyverno:kyverno"
  AND verb = "get"
  AND objectRef.resource = "configmaps"
  AND objectRef.namespace NOT IN ("kyverno", "<tenant ns where the policy lives>")

2. Falco runtime rules

For pod-side detection of post-exploit behavior:

- rule: Token theft from kube-system service account
  desc: Process inside a pod reads the projected SA token of another pod
  condition: >
    open_read and fd.name pmatch ("/var/run/secrets/kubernetes.io/serviceaccount/token") and
    proc.aname[1] != container.id and
    not proc.name in (kubelet, container_runtime_processes)
  output: "Cross-pod SA token read (proc=%proc.cmdline target=%fd.name)"
  priority: CRITICAL

3. Static analysis of cluster RBAC

Run a one-time audit against your live cluster for the high-leverage patterns:

# Find every binding that grants nodes/proxy
kubectl get clusterroles -o json | \
  jq -r '.items[] | select(.rules[]? | .resources[]? == "nodes/proxy") | .metadata.name' \
  | xargs -I {} kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name == "{}") | .metadata.name + " → " + .roleRef.name'

# Find every aggregated cluster-admin alias
kubectl get clusterrole cluster-admin -o yaml | grep -A 2 aggregationRule

Mitigation

1. Replace nodes/proxy grants with kubelet-direct credentials. Monitoring agents that need node metrics should run as DaemonSets with a node-local kubelet token, not via API-server proxy. The kubelet's read-only port (10255) is already deprecated in favor of authenticated 10250 with proper auth.
2. Patch / verify AKS clusters past the CVE-2026-33105 fix line. If you're not on AKS, this isn't your problem. If you are, check the AKS release notes and your cluster's control-plane version today.
3. Kyverno multi-tenant lockdown: upgrade to Kyverno's post-disclosure patched line (the ConfigMap context loader now validates the target namespace against the policy's tenant scope). Until you've upgraded, restrict Kyverno policies to the kyverno namespace and audit policies for cross-namespace context references.
4. Aggregated role hygiene: any ClusterRole with an aggregationRule should be reviewed quarterly. New CRDs and labels can silently widen the aggregated role.
5. Service account token rotation: Kubernetes 1.30+ supports projected service account tokens with short TTLs. Move all sensitive workload tokens to projected, time-bound tokens. A token that lives 15 minutes is worth less than a token that lives until pod restart.

Frequently Asked Questions

Is my cluster vulnerable to all three of these?

To Path 1 (nodes/proxy) — almost certainly yes if you run any of the popular monitoring stacks on default settings. To Path 2 (CVE-2026-33105) — only if you run AKS, and only if your control-plane version is below the patched line. To Path 3 (Kyverno ConfigMap) — only if you run Kyverno in a multi-tenant configuration before the patched release.

Why is nodes/proxy treated as a normal monitoring permission?

Historical inertia. The permission was added when Kubernetes was a single-tenant tool, and the security implications of API-server-mediated kubelet proxy weren't a load-bearing concern. Helm chart authors copy permission lists between projects. Until early 2026, no widely-distributed audit guidance flagged nodes/proxy as cluster-admin-equivalent. Helton's disclosure changed that.

Will the AKS fix be backported to earlier Kubernetes versions?

AKS-specific fixes don't backport to upstream Kubernetes — the bug was in Microsoft's managed-control-plane authorization layer, not in Kubernetes core. If you self-host (kubeadm, kops, EKS, GKE), you weren't affected by CVE-2026-33105.

How do attackers find these in the first place?

For nodes/proxy: any compromised pod tells the attacker which roles its service account holds (read /var/run/secrets/kubernetes.io/serviceaccount/token, decode the JWT, look at the bound role). For Kyverno: the misuse pattern is documentable from public Kyverno feature docs. For AKS: targeted scanning + tenant enumeration via Azure metadata service. None require novel offensive tooling.

Key Takeaways

• nodes/proxy is cluster-admin-equivalent. Audit every binding that grants it.
• CVE-2026-33105 (AKS, CVSS 10.0) is a patch-now item if you run AKS. Verify the control-plane version.
• Kyverno's ConfigMap context bypass breaks multi-tenant isolation by design until patched.
• Kubernetes RBAC permissions evaluated at grant time, not use time, mean a role's printed scope can be much narrower than its practical privilege.
• The cheapest detection is the API server audit log. The most-leveraged mitigation is killing nodes/proxy grants for non-system service accounts.

Sable Offensive Research conducts authorized Kubernetes RBAC audits for engineering organizations: ClusterRole reviews, monitoring-stack permission triage, and post-compromise tabletop exercises starting from the three paths above. Contact us if your cluster footprint warrants a focused review.

References

• Graham Helton: nodes/proxy disclosure (January 2026)
• Microsoft Security Response Center: CVE-2026-33105 advisory (April 3, 2026)
• Palo Alto Unit 42: RBAC-based privilege escalation in popular Kubernetes platforms
• SCHUTZWERK: Kubernetes RBAC paths for privilege escalation
• Kyverno security advisory: ConfigMap context loader namespace validation