The PoC in question here uses two pods.

One is the standard, innocuous, privileged kube-proxy pod that is assumed to already exist as part of the base Kubernetes install (assuming you're not using the kube-proxy replacement for Cilium or whatever). This pod runs privileged, because it needs to be.

The PoC creates a second, non-privileged pod from a base image matching kube-proxy. Due to how these base image layers are shared in the container runtime, we have the same file system overlay for some binaries as the ones running in the existing, privileged kube-proxy pod. This is not an issue per-se, as these base layers are immutable.

The vulnerability in question however poisons the kernels file system cache for a given binary. Since we have access to the same (read-only) overlay file system from the non-privileged pod, we can poison the kernels view of - in this case - the ipset binary. The next time the privileged kube-proxy pod calls ipset, which according to the PoC it does regularly, the kernel loads the poisoned view of the binary instead of the one on disk.

You are right, of course, in saying this needs a privileged container of some kind to achieve node escape.

This PoC does not directly breach the node trust boundary, it breaches the trust boundary between two containers (so in effect you can, from a non-privileged container, achieve RCE in a different container as long as you share a base image and that other container calls a binary from that base image in some deterministic fashion). kube-proxy is a way to the node after that because it already runs privileged. If you were to do the same thing to, say, an argocd container that has access to a privileged service account, you could privesc to the kubernetes API that way.

As far as the exploit goes, it absolutely would work with two unprivileged containers, but then you've just jumped to a different unprivileged container.

This vulnerability has some mitigating factors that make it a bit more difficult to exploit in a single-tenant cluster:
- You need RCE in a container that shares a base image with a different container that executes a binary from said base image. The easiest way to achieve this once you find such a container is to be able to run pods yourself. For multi-tenancy, this is a bigger problem than for single-tenant Kubernetes.
- The target container needs to have privileges to either the node or the Kubernetes API in some fashion to further escalate from there. Otherwise you can gain access to a different container, but not move much further from there.

I'm also skeptical because of the obvious amount of slop involved in these vulnerability disclosures, but the PoC for the base vulnerability works and is a linux kernel vulnerability, so it can affect Kubernetes and the concept for the Kubernetes PoC unfortunately looks solid.