Notifications
Clear all
Topic starter
10/06/2026 11:43 pm
TL;DR: CVE-2025-62878 lets authenticated Kubernetes users turn Rancher Local Path Provisioner path templates into arbitrary host filesystem access, with exploitability ranging from namespace-level PVC control to cluster-scoped StorageClass changes according to Orca Security. The real lesson is that default storage backends can become host-level identity boundaries when templated paths trust user-controlled metadata.
NHIMG editorial — based on content published by Orca Security: an analysis of CVE-2025-62878 in Rancher Local Path Provisioner
By the numbers:
- The Docker Hub image has over 100 million total pulls and averages roughly 750,000 pulls per week.
Questions worth separating out
Q: What breaks when a Kubernetes storage backend trusts user-controlled path templates?
A: The storage backend stops confining volume operations to the intended directory and can redirect reads, writes, or deletions onto the host filesystem.
Q: Why do storage-class permissions matter so much in Kubernetes security?
A: StorageClass permissions matter because they can define how cluster-scoped storage behaves for every namespace that uses it.
Q: How do security teams know if a PVC template is exposing host paths?
A: Look for StorageClass fields that reference user-controlled PVC metadata, then test whether those values can produce traversal sequences or unexpected base-path escapes.
Practitioner guidance
- Upgrade the provisioner immediately Move every affected deployment to Local Path Provisioner v0.0.34 or a K3s release that bundles the fix.
- Review every StorageClass path template Inventory StorageClasses for pathPattern values that reference annotations or labels, then remove user-controlled fields where possible.
- Restrict storage-class creation and edits Limit StorageClass modification to trusted cluster administrators and audit who can create or patch cluster-scoped storage objects.
What's in the full article
Orca Security's full research covers the operational detail this post intentionally leaves for the source:
- Exact malicious YAML patterns showing how traversal sequences are injected into pathPattern values
- Host and Kubernetes audit indicators for detecting unsafe volume resolution and ConfigMap tampering
- Remediation timing guidance for upgrading bundled provisioners across K3s and downstream distributions
- Background on how the helper pod reaches the host filesystem through hostPath rather than privileged container settings
👉 Read Orca Security's analysis of CVE-2025-62878 in K3s storage →
K3s storage traversal: what IAM and platform teams need to know?
Explore further
12/06/2026 6:03 am
StorageClass templating is an identity boundary, not just a storage convenience. When a Kubernetes storage backend accepts user-controlled metadata and turns it into a host path, the control plane effectively becomes an access broker for the node filesystem. That is an NHI governance problem because the actor is a service workflow operating with durable, non-human privileges. Practitioners should treat StorageClass design as part of workload identity governance, not only platform engineering.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why host-level trust paths often go unnoticed until they are abused.
A question worth separating out:
Q: Who is accountable when a storage backend gives namespace users host access?
A: Accountability usually spans the platform team that owns the StorageClass, the cluster administrators who granted the permissions, and the security team that failed to detect unsafe templating. When host access comes from a default backend, the issue is governance, not just exploitation. Teams need clear ownership for storage templates, RBAC, and admission policy.
👉 Read our full editorial: K3s storage traversal turns a default provisioner into host risk
