# RBAC GET for nodes/proxy allows running commands on all pods

**URL:** <https://discuss.prometheus.io/t/rbac-get-for-nodes-proxy-allows-running-commands-on-all-pods/3494>\
**Category:** General Help/Support\
**Created:** [January 26, 2026, 7:13pm UTC](https://discuss.prometheus.io/t/rbac-get-for-nodes-proxy-allows-running-commands-on-all-pods/3494 "2026-01-26T19:13:12Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![warsang](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.prometheus.io/warsang/32/1242_2.png) [@warsang](https://discuss.prometheus.io/u/warsang)\
**Post date:** [January 26, 2026, 7:13pm UTC](https://discuss.prometheus.io/t/rbac-get-for-nodes-proxy-allows-running-commands-on-all-pods/3494/1 "2026-01-26T19:13:12Z")

</div>

Hi! I recently read this blogpost:

> **[Kubernetes Remote Code Execution
Via Nodes/Proxy GET Permission](https://grahamhelton.com/blog/nodes-proxy-rce)**
>
> An authorization bypass in
> Kubernetes RBAC allows for nodes/proxy GET permissions to execute
> commands in any Pod in the cluster.

It seems like a malicious user with direct access to a prometheus server who can get access to the automounted ServiceAccount token would be able to send the following to the Kubelet API:

```auto
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)

```

From my understanding, it doesn’t seem like this is really an “ **issue** ” coming from prometheus; Rather, it’s because of a missing feature: “_The Kubelet API authorization uses a coarse authorization scheme, where actions like reading health status and the ability to exec into a pod require the same RBAC permissions_.” according to [KEP-2862](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2862-fine-grained-kubelet-authz/README.md)

I am very new to prometheus so I am not extremely familiar with the inner workings; however, I didn’t find any discussions about this and thought I’d start one. What would be the recommended way for users that can’t use KEP-2862 because they’re using an older version of Kubernetes to harden their set-up? Apply a network security policy to prevent reaching port 10250 or are there other approaches one can take for defense-in-depth? Would that network security policy risk breaking anything?

Thanks in advance!