A standard Kubernetes permission (found in virtually every monitoring and observability stack) has been identified as a direct path to a cluster-wide RCE. This finding proves that foundational assumptions that RBAC ‘GET’ permissions are strictly limited to read-only telemetry—but because it’s not a traditional vulnerability, it creates a high-risk attack surface that’s totally invisible to static configuration scanners.

Published in January 26, 2026 by security researcher Graham Helton, the issue centers on the Kubernetes RBAC permission nodes/proxy GET, a permission frequently granted to monitoring and observability components. Although the permission has previously been assumed to provide read-only access, Helton demonstrated that it can be abused to execute arbitrary commands inside pods via the Kubelet API, effectively collapsing multiple trust boundaries within the cluster.

From “Read-Only” Access to Full Workload Compromise

The root of the issue lies in how Kubernetes authorizes WebSocket connections proxied from the API server to the Kubelet. Pod exec operations are initiated using a WebSocket handshake, which begins as an HTTP GET request. Kubernetes authorizes this request based solely on the GET verb – meaning a principal with nodes/proxy GET permission can successfully initiate an exec session without having the explicit permissions normally required to execute commands in pods.

This creates a vertical privilege escalation path: an attacker with limited, legitimate access to the cluster (often through a service account used by monitoring tools) can escalate their privileges and gain the ability to run commands across arbitrary workloads. While the outcome is remote code execution, the underlying issue is more accurately described as overly permissive RBAC semantics combined with an authorization gap, which is why the Kubernetes security team ultimately classified the behavior as “working as intended.”

Why Configuration Scanning Alone Falls Short

Following the disclosure, detection scripts were shared to help identify clusters at risk by locating roles and bindings that include the nodes/proxy permission. These checks are useful, but they only answer one question:

Who could exploit this issue?

They do not answer the more important one:

Is this happening right now?

Configuration-based tools (CNAPPs, posture scanners, and RBAC analyzers) can flag risky permissions, but they cannot determine intent, context, or abuse. In real-world environments, nodes/proxy GET is legitimately used by many components. Removing it outright is often not feasible, and simply knowing it exists does not tell you whether it’s being leveraged maliciously.

Runtime Is the Only Way to Detect Actual Exploitation

Detecting exploitation of this privilege escalation requires runtime visibility.

The abuse path involves live L7 interactions with the Kubernetes API and the Kubelet, including WebSocket upgrades, exec requests, and command streams that occur after authentication and authorization have already succeeded. These actions leave no footprint in static configuration and are often indistinguishable from legitimate activity unless you are observing them as they happen, in context.

Only runtime protection can:

• Observe unexpected or high-risk exec activity
• Detect WebSocket-based command execution patterns
• Correlate API requests with workload behavior and identity
• Distinguish legitimate operational access from attacker-driven escalation

Without runtime monitoring, exploitation of this issue is effectively invisible.

Sweet Security: Closing the Gap Between Exposure and Exploitation

At Sweet Security, we believe security doesn’t stop at identifying risky configurations – it requires detecting and stopping attacks in production. Our platform combines CNAPP-style configuration analysis with deep runtime protection, allowing teams to both:

• Identify service accounts and roles that could abuse nodes/proxy, and
• Detect and alert on actual exploitation attempts by monitoring live L7 traffic and execution behavior across Kubernetes control plane and workloads.

This dual approach is essential for modern cloud-native environments, where permissions are complex, defaults are dangerous, and attackers increasingly operate within the bounds of “allowed” access.