K3s storage traversal turns a default provisioner into host risk

At a glance

What this is: This is a critical Kubernetes storage traversal flaw in Rancher Local Path Provisioner that can expose host filesystems through malicious path templates.

Why it matters: It matters because storage backends, service identities, and cluster RBAC now intersect at the host boundary, so IAM, PAM, and NHI teams need to treat Kubernetes control-plane permissions as infrastructure access.

By the numbers:

• The Docker Hub image has over 100 million total pulls and averages roughly 750,000 pulls per week.

👉 Read Orca Security's analysis of CVE-2025-62878 in K3s storage

Context

CVE-2025-62878 is a relative path traversal issue in the default storage backend used by K3s, and the practical problem is simple: a path template that trusts user-controlled input can redirect a volume operation onto the host filesystem. In identity terms, this is not just a software bug, it is a boundary failure between Kubernetes API permissions and host-level impact.

That matters because Kubernetes storage workflows often sit outside traditional IAM review, yet they can still create durable access to files, keys, and configuration on every node. For teams managing NHI, workload identity, and platform governance together, the question is not only who can create a PVC, but what that PVC can reach once the provisioner resolves the path.

Key questions

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. That turns an apparently normal PVC workflow into infrastructure access. In practice, the break is not only path traversal, it is loss of boundary control between namespace-level input and node-level impact.

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. If a class accepts templated input from annotations or labels, the resulting access can exceed the intent of namespace RBAC. Teams should treat StorageClass governance as part of platform access control, not a separate storage admin task.

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. The strongest signals are audit events showing pathPattern updates, helper pods writing outside the storage root, and ConfigMap changes that alter setup or teardown scripts.

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.

Technical breakdown

How pathPattern injection breaks storage path isolation

Local Path Provisioner uses a StorageClass field called pathPattern to decide where persistent volume data lands on a node. In affected versions, the rendered template is passed into filepath.Join without sanitisation, so traversal sequences such as ../ escape the intended base directory. Because the parameter can consume PVC metadata, a user-controlled annotation can become filesystem path input. The resulting volume is no longer confined to application storage. It can point at /etc, /root, or other sensitive host locations depending on the resolved path and node permissions.

Practical implication: block traversal in StorageClass templates and review any pathPattern that consumes user-controlled PVC fields.

Why the helper pod creates host-level impact

The provisioner does not merely compute a bad path. It spawns a helper pod that runs shell scripts against the resolved directory, using hostPath access to create or remove the target path. That means mkdir and rm -rf operations can affect host directories even when the pod does not appear privileged. The danger increases when reclaimPolicy is Delete, because removal can become destructive. This is a control-plane to host-filesystem trust chain, not a conventional container escape through kernel breakouts.

Practical implication: audit helper-pod behaviour and restrict hostPath access to sensitive directories, not just privileged securityContext settings.

Why PodSecurity controls miss this class of exposure

A key blind spot is that the helper pod can look unprivileged from a securityContext perspective while still gaining host access through mounted paths. That means controls focused only on privileged: true, PodSecurity admission, or legacy PodSecurityPolicies can miss the actual risk. The technical failure is not elevated Linux capabilities, but unsanitised path resolution combined with host-mounted filesystem access. In practice, policy engines need to inspect volume targets and storage templates, not only pod privilege flags.

Practical implication: add admission checks for hostPath targets and unsafe storage templates, because pod privilege alone is not a sufficient control signal.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

PodSecurity is the wrong lens for host filesystem risk when hostPath is doing the real work. This flaw shows why security teams cannot rely on privileged-container detection as their primary control. The helper pod may appear ordinary, yet the host access is still real because the mount path is what crosses the boundary. The lesson is that identity and access policy for Kubernetes must inspect where a workload can reach, not only how it is labelled. Practitioners need hostPath-aware policy and storage-template review.

Default platform components can create hidden NHI blast radius at cluster scope. K3s ships Local Path Provisioner as the default backend, which means a storage weakness can become a broad platform exposure before any application team makes a choice. This is where NHI governance and platform governance converge: a single cluster-scoped StorageClass can affect every node and every namespace that consumes it. Practitioners should classify default storage infrastructure as part of the trusted identity perimeter.

Unsafe path allowances create a named failure mode: storage path trust debt. The vulnerable pattern is not just path traversal, it is the accumulated trust placed in templated storage paths that outlive the assumptions that produced them. Once allowUnsafePathPattern is enabled, the governance model depends on every future user behaving safely, which is not a control boundary. The implication is that teams must re-evaluate how much authority a storage template should ever inherit from tenant-controlled metadata.

Cluster-admin RBAC and namespace-user PVC controls are not interchangeable risk levels. The article shows two materially different trust models: direct StorageClass creation and PVC annotation injection. One is clearly privileged, while the other can collapse the effective privilege requirement if the storage template already trusts annotation data. Practitioners should separate cluster-scoped access from namespace-scoped influence when reviewing storage governance, because the resulting blast radius is not the same.

From our research:

• 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.
• For a broader failure-pattern view, 52 NHI Breaches Analysis shows how exposed credentials and overbroad access repeatedly turn small misconfigurations into major incidents.

What this signals

Storage path trust is becoming a distinct governance category. Teams that already manage workload identities, service accounts, and Kubernetes RBAC need to add storage templating to that map, because the identity boundary now includes where a volume resolves on the node. The practical change is to review storage classes with the same discipline applied to secrets and privileged service accounts.

With only 5.7% of organisations reporting full visibility into service accounts, the wider lesson is that hidden access paths are the norm, not the exception. That makes admission controls, configuration review, and hostPath policy essential guardrails for platform teams running K3s or similar embedded storage defaults.

The next governance step is to treat default storage components as part of the trust perimeter. If a backend can translate metadata into host-level writes, then NHI, PAM, and platform teams need shared ownership of the storage lifecycle, not separate ticket queues.

For practitioners

• Upgrade the provisioner immediately Move every affected deployment to Local Path Provisioner v0.0.34 or a K3s release that bundles the fix. Treat anything older than v0.0.34 as exposed until proven otherwise, including downstream distributions that embed the provisioner.
• Review every StorageClass path template Inventory StorageClasses for pathPattern values that reference annotations or labels, then remove user-controlled fields where possible. Reject any template that can resolve to ../ sequences or escape the configured base directory.
• Restrict storage-class creation and edits Limit StorageClass modification to trusted cluster administrators and audit who can create or patch cluster-scoped storage objects. Separate this review from namespace-level PVC permissions so the two trust planes are not conflated.
• Detect unsafe host-path resolution Alert on helper pod activity that resolves volumes outside the expected base path, especially /opt/local-path-provisioner and /var/lib/rancher/k3s/storage. Pair that with audit rules for StorageClass updates that contain ../ in pathPattern.
• Inspect local-path-config for tampering Check the local-path-config ConfigMap for modified setup or teardown scripts and lock down patch access. If you do not need local-path storage, disable the provisioner instead of trying to harden a component you do not use.

Key takeaways

• This vulnerability shows how a storage template can cross from routine PVC handling into host filesystem control.
• The exposure is serious because the default K3s storage backend is widely deployed and the attack can be triggered with simple YAML.
• The control that matters most is not pod privilege alone, but strict governance over StorageClass templates, hostPath access, and default storage backend versions.

Key terms

• StorageClass: A StorageClass defines how Kubernetes provisions persistent storage and which backend handles the request. In this case, it becomes part of the access control surface because its parameters can influence where data lands on the host and who can indirectly reach sensitive filesystem paths.
• Path Traversal: Path traversal is the use of sequences such as ../ to escape an intended directory and access files elsewhere on the filesystem. In Kubernetes storage workflows, it becomes dangerous when template values are not sanitised before being joined into a host path.
• HostPath Volume: A hostPath volume mounts a directory from the node filesystem into a pod. It is a powerful mechanism because it can expose the underlying host directly, so governance must focus on where the mount points and what directories the pod can touch, not only on pod privilege flags.

Deepen your knowledge

StorageClass governance, hostPath exposure, and Kubernetes identity boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing platform access in K3s or similar environments, it is worth exploring.

This post draws on content published by Orca Security: an analysis of CVE-2025-62878 in Rancher Local Path Provisioner. Read the original.