create pods
Privileged, hostPID, hostPath, or hostNetwork pods mount / and chroot to the node for full host access.
T0 in kube-system or on a control plane node.
Setting spec.nodeName directly places the pod on any node, bypassing the scheduler's taint checks, since taints are enforced by the scheduler only.
This is still an ordinary pods create request, not the pods/binding subresource that most admission engines never inspect, so admission policy can see and block it.
T0 with following verbs:
The same privileged pod placed on a control plane node
A privileged pod spec decides what the workload can do, and pods/binding decides where it runs.
The taint keeping workloads off the control plane is enforced by the scheduler, so a direct binding ignores it.
Contextual upgrade to T0:
Pod is scheduled in kube-system or on a control plane node, exposing node-level and control plane credentials, and admission controls (Pod Security Admission, OPA/Gatekeeper, Kyverno) are absent or configured permissively
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- Request
Escalation Paths
Create a pod with privileged + hostPID or hostPath mounting /
Set spec.nodeName to a specific control plane node to force placement there.
Taints are scheduler-only checks, so no toleration is needed
chroot or nsenter into the host to gain root on the node
Read /etc/kubernetes/pki, steal kubelet cert or SA tokens.
This is T0 on the control plane
Additional rights needed:
Create a pod using hostNetwork, hostPID, hostIPC or hostPath as available
hostNetwork reaches cloud metadata and the API server from the node network namespace.
hostPID reads host process env vars
hostPath to / reads other pods' SA tokens under /var/lib/kubelet and the cluster CA private key if scheduled on a control plane node
Additional rights needed:
Note:
On a control plane node, hostPath to / exposes the cluster CA private key for full cluster compromise.
On worker nodes this is node-level only (T1).
Create a pod targeting a Windows node with spec.securityContext.windowsOptions.hostProcess: true
Container starts as NT AUTHORITY\SYSTEM in the host network and volume namespaces
Windows HostProcess is blocked by both Baseline and Restricted Pod Security Standards.
Only namespaces enforcing Privileged level or unlabeled namespaces are vulnerable
Full Windows node compromise follows, with lateral move to other workloads or extraction of node credentials
Additional rights needed:
Note:
Windows HostProcess containers were introduced as stable in 1.23.
This is by-design for Windows workloads, so no patch applies.
Linux-only clusters are unaffected.
The risk is specific to mixed OS clusters.