Introduction In this post I’ll describe how to execute code on every Pod in many Kubernetes clusters when using a service account with nodes/proxy GET permissions. This issue was initially reported through the Kubernetes security disclosure process and closed as working as intended. Executing Commands In Another Pod Attribute Details Vulnerable Permission nodes/proxy GET Kubernetes Version Tested v1.34, v1.35 Required Network Access Kubelet API (Port 10250) Impact Code execution in any Pod on reachable Nodes Disclosure Status Won’t fix (Intended behavior) Helm charts Affected 69 Kubernetes administrators often grant access to the nodes/proxy resource to service accounts requiring access to data such as Pod metrics and Container logs. As such, Kubernetes monitoring tools commonly require this resource for reading data. nodes/proxy GET allows command execution when using a connection protocol such as WebSockets. This is due to the Kubelet making authorization decisions based on the initial WebSocket handshake’s request without verifying CREATE permissions are present for the Kubelet’s /exec endpoint requiring different permissions depending solely on the connection protocol. The result is anyone with access to a service account assigned nodes/proxy GET that can reach a Node’s Kubelet on port 10250 can send information to the /exec endpoint, executing commands in any Pod, including privileged system Pods , potentially leading to a full cluster compromise. Kubernetes AuditPolicy does not log commands executed through a direct connection to the Kubelet’s API. This is not an issue with a particular vendor. Vendors widely utilize the nodes/proxy GET permission since there are no viable alternatives that are generally available. A quick search returned 69 helm charts that mention nodes/proxy GET permissions. Some charts ship with it, while others may need additional options configured. If you have concerns, check with your vendor and review the detection section of this post. Note Some charts require the functionality to be enabled for nodes/proxy to be in use. For example, cilium must be configured to use Spire The following are a few of the notable charts. See the appendix of this post for the full list of the 69 Helm charts identified: prometheus-community/prometheus grafana/promtail datadog/datadog elastic/elastic-agent cilium/cilium opentelemetry-helm/opentelemetry-kube-stack trivy-operator/trivy-operator newrelic/newrelic-infrastructure wiz-sec/sensor The following ClusterRole shows all the permissions needed to exploit this vulnerability. # Vulnerable ClusterRole apiVersion : rbac.authorization.k8s.io/v1 kind : ClusterRole metadata : name : nodes-proxy-reader rules : - apiGroups : [ "" ] resources : [ "nodes/proxy" ] verbs : [ "get" ] As a cluster admin, you can check all service accounts in the cluster for this permission using this detection script . If the service account is vulnerable, it can run commands in all Pods in the cluster using a tool like websocat: websocat --insecure \ --header "Authorization: Bearer $TOKEN " \ --protocol v4.channel.k8s.io \ "wss:// $NODE_IP :10250/exec/default/nginx/nginx?output=1&error=1&command=id" uid = 0 ( root ) gid = 0 ( root ) groups = 0 ( root ) If you would like to try this out yourself, I have published a lab to walk through executing commands in other pods Demo Environment If you would like to be notified of other research early, RSS feeds are available , or get it directly to your inbox . Deepdive: What is Nodes/Proxy? A quick refresher: Kubernetes RBAC uses resources and verbs to control access. Resources like pods , pods/exec , or pods/logs map to specific operations, and verbs like get , create , or delete define what actions are permitted. For example, pods/exec with the create verb allows command execution in pods, while pods/logs with the get verb allows reading logs. The nodes/proxy resource is unusual. Unlike most Kubernetes resources that map to specific operations (like pods/exec for command execution or pods/logs for log access), nodes/proxy is a catch-all permission that controls access to the Kubelet API. It does this by granting access to two different, but slightly related endpoints called the API Server Proxy and the Kubelet API . API Server Proxy The first endpoint nodes/proxy grants access to is the API Server proxy endpoint $API_SERVER/api/v1/nodes/$NODE_NAME/proxy/... . Requests sent to this endpoint are proxied from the API Server to the Kubelet on the target Node. This is used for many operations, but some common ones are: Reading metrics: $API_SERVER/api/v1/nodes/$NODE_NAME/proxy/metrics Reading resource usage: $API_SERVER/api/v1/nodes/$NODE_NAME/proxy/stats/summary Getting Container logs: $API_SERVER/api/v1/nodes/$NODE_NAME/proxy/containerLogs/$NAMESPACE/$POD_NAME/$CONTAINER_NAME These can be accessed directly with kubectl’s --raw flag or directly with curl. For example, making a request to the metrics endpoint returns some basic metrics i...