create persistentvolumes
A hostPath PV rooted at / exposes the node's root filesystem to any pod that claims it via a PVC.
PersistentVolumes are cluster-scoped, so this reaches across namespaces.
Pod Security Admission does not block it at any profile, including restricted, because PSA validates a pod's own volume types and never resolves a PVC to its bound PV's hostPath.
A fully restricted-compliant pod still mounts the host filesystem.
Only runAsNonRoot limits which host files are readable.
Note:
CVE-2023-5528 (Windows nodes only, CSI clusters unaffected) has been patched.
The base hostPath PV path is not version-patched and Pod Security Admission does not block it at any profile, since PSA does not inspect the PV behind a PVC.
- API Group
- (core)
- Scope
- cluster
- Audit Level
- Request
Escalation Paths
Create a hostPath PersistentVolume mounting node / (or use an existing one via a PVC)
Claim the volume from an otherwise restricted-compliant pod.
PSA does not inspect the PV behind a PVC, so even the restricted profile does not block it
Read or write arbitrary node filesystem paths.
This is T0 on control plane nodes
Or set the PV's claimRef to a victim's PVC name and namespace, including one not yet created, so the victim's future workload silently binds to attacker-controlled storage
Additional rights needed:
· create the volume, claim it, mount it
· only where a hostPath PersistentVolume already exists
Note:
The base hostPath PV path is not version-patched, and Pod Security Admission does not block it at any profile.
PSA checks the pod's own volume types, never the PV behind a PVC.
runAsNonRoot only limits which host files are readable, not the mount.
CVE-2021-25741 is a separate, patched issue.