Excited to disclose my research allowing RCE in Kubernetes
It allows running arbitrary commands in EVERY pod in a cluster using a commonly granted "read only" RBAC permission. This is not logged and and allows for trivial Pod breakout.
Unfortunately, this will NOT be patched.
I initially disclosed this in November of 2025 to the Kubernetes bug bounty program.
After much back and forth, it was decided that this "this behavior is working as intended" despite the risk it poses. I disagree.
It's nuanced, but the short answer is there is there is a mismatch between WebSockets and the Kublet's authorization logic.
It checks the RBAC GET verb instead of CREATE when connecting via websockets. In this example, sending an HTTP request is rightfully blocked
However, when making the same connection over websockets, the request is permitted!
I analyzed as many helm charts as I could get my hands on and ~69 of them mention the nodes/proxy GET permission. Some of the worlds biggest kubernetes vendors rely on it because there is no generally available alternative.
I've published a very simple tutorial on exploiting this for RCE on the wonderful @iximiuz. You can try it out here: labs.iximiuz.com/tutorials/node…
Here is a script to check if your cluster has a service account that can be used for arbitrary code execution. If you're running a production cluster (especially with monitoring tools), I would highly recommend checking.
What you can do with this permission:
- Steal service account tokens in other pods
- Execute code in any Pod including control plane pods (etcd, apiserver, etc).
- Execute code in privileged pods, allowing for Pod -> node breakout.
- All without the commands being logged
For the full disclosure and breakdown please refer to the disclosure.
I will be presenting this research with some of the juicy details and implications at @SpecterOps's SOCON in a few months specterops.io/so-con/#rs-tal…
@SpecterOps Soon...
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Before moving from my role at Google to Snowflake I sat down and did a braindump of all the guidelines that I follow (or followed at one point and wanted to reintroduce).
For those interested, here are the ~34 guidelines that made the cut
Read all the documentation for products you’re working on. Understand how they work in and out as early as often. Read them in full. It will take days or weeks. Find all the docs possible. Talk to people about them. Annotate them with questions and ideas.
Become a proficient in the common tech stack. Does your team use git for EVERYTHING? You should know it well. Does your team use terraform? Be proficient in it.
The purchase of Comptia and Offsec by private equity firms should indicate trouble is looming in the security world.
Expect to pay more for lower quality certifications.
If you're in a hiring position, start identifying ways you can identify quality candidates without certs.
If you couldn't already tell, this is frustrating to me and is part of why I push everyone to have some sort of public proof of their competence in a subject that isn't a certification.
Blogging is a great way to demonstrate you're skills without needing to pay cert providers.
PE firms have no north star other than profit. They buy companies, increase short term profits through anti-consumer practices, then sell the company. All at a lower tax rate than a minimum wage worker.
If you're unfamiliar with the the perils of PE, I've linked to a few below:
Challenging researchers via a $1,000,000 bug bounty for their new Private Cloud Compute technology, releasing source code, architecture docs, and tooling means apple is VERY confident in this tech. 1/?
1. Back In June, Apple announced their “Private Cloud Compute” technology which allows for workloads originating on an apple device to be processed on a device in the cloud with higher, more specialized, computational hardware.
2. The unique aspect of this this is the security guarantees Apple provides around the AI’s processing of user data, specifically, apple states: “user data sent to PCC isn’t accessible to anyone other than the user – not even to Apple”.
Alright here are my thoughts after digging into NixOS this weekend, buckle up because I have some thoughts on how it could be used for both personal use and in a security setting:
NixOS (not to be confused with *nix or the Nix package manger) is a Linux distro that aims to be reproducible, declarative, and reliable. It has a few different ways of accomplishing this:
Reproducibility: Your entire operating system is put into a few configuration files. These files determine what software, users accounts, services, network settings, software configurations, etc, are set up.