K3s storage traversal turns a default provisioner into host risk

At a glance

What this is: This is a critical K3s storage flaw where templated path handling in Local Path Provisioner can be abused to reach the underlying host filesystem.

Why it matters: It matters because platform and IAM teams need to treat StorageClass templating, PVC authority, and hostPath exposure as governance boundaries, not just cluster plumbing.

Context

K3s storage provisioning is supposed to translate Kubernetes storage requests into local volumes safely, but CVE-2025-62878 shows what happens when a path template accepts user-controlled metadata without sanitization. In practice, that turns a storage convenience feature into a host access boundary that can be crossed from the Kubernetes API.

The identity lesson is straightforward: the actor is an authenticated Kubernetes user, not a mystery attacker, and the control failure sits in how storage permissions are delegated and interpreted. In environments where PVCs, StorageClasses, and annotations are all part of the provisioning path, the trust model has to account for who can influence the rendered path, not just who can create a pod.

Key questions

Q: What breaks when a StorageClass path template accepts user-controlled metadata?

A: The trust boundary breaks at the point where Kubernetes metadata becomes a host filesystem path. If the template accepts labels, annotations, or names without sanitization, an authenticated user can steer volume creation outside the intended base directory and force the provisioner to operate on sensitive host paths.

Q: Why does this vulnerability create host risk instead of just broken storage isolation?

A: Because the provisioner does not stop at path calculation. It uses the resolved path in host-backed filesystem operations, so a path traversal error becomes a read, write, or delete capability on the node itself. That changes the issue from storage misrouting to host compromise.

Q: What signs show that a K3s cluster is exposed to this storage flaw?

A: Look for StorageClasses that define pathPattern, especially if they reference PVC annotations or other user-controlled fields. Also watch for unexpected local-path-config edits and audit entries showing traversal strings in StorageClass create or update events.

Q: Should teams treat default K3s storage as lower risk than custom storage classes?

A: No. Default K3s installs reduce the attack surface only when the provisioner uses its built-in, non-user-controlled path template. Once operators introduce custom templating or unsafe path handling, the same default backend can become a host-level exposure path.

Technical breakdown

How path template traversal escapes the base directory

Rancher Local Path Provisioner renders a pathPattern from StorageClass data and then joins it with a configured base path. If that template contains traversal sequences such as ../, filepath.Join resolves the path outside the intended storage root. The vulnerability is CWE-23 style relative path traversal, but the practical impact is larger because the resulting path is later used for filesystem operations on the host. In a K3s default deployment, that means a storage request can be translated into host directory access instead of an isolated persistent volume path.

Practical implication: treat any templated storage path that accepts user influence as a host boundary and validate it before provisioning.

Why the helper pod turns path traversal into host-level access

The provisioner uses a helper pod to run shell scripts against the resolved directory, including mkdir and rm -rf operations. That means the vulnerable path is not just a path resolution bug, it becomes a filesystem action executed with hostPath-backed access. Since the mount provides the host filesystem reach, security controls that only block privileged containers will not detect or stop the issue. The real failure is the assumption that an unprivileged-looking pod cannot still touch sensitive host paths through its volume configuration.

Practical implication: inspect hostPath use and helper pod volume mounts, not just privileged flags, when auditing storage controllers.

Why default K3s configuration narrows but does not remove the risk

A default K3s installation is not exploitable in the same way as a custom configuration because the embedded manifest does not set a user-controlled pathPattern. The dangerous condition appears when an operator adds templating against PVC metadata or enables unsafe path handling. That difference matters for prioritisation: the flaw is not a blanket unauthenticated break-in, but it becomes severe wherever cluster RBAC or storage customization gives users influence over rendered paths. The governance problem is configuration drift into a weaker trust model.

Practical implication: inventory every StorageClass that templates on user input and remove unsafe path handling before treating the cluster as low risk.

Threat narrative

Attacker objective: The attacker aims to turn ordinary storage provisioning into host filesystem control and use that reach to steal, modify, or destroy critical node and cluster assets.

1. Entry occurs when an authenticated Kubernetes user submits a PVC or modifies a StorageClass that feeds user-controlled values into pathPattern.
2. Credential or privilege abuse follows when the provisioner accepts the rendered path without sanitization and maps it outside the intended storage root.
3. Escalation happens when the helper pod executes mkdir or rm -rf against the host-backed target path, giving the attacker read, write, or delete reach on the node filesystem.
4. Impact is host-level compromise of files such as Kubernetes PKI material, cron paths, or kubelet data, which can translate into full cluster abuse.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Default storage provisioning can become an identity boundary when it accepts user-controlled path templates: The vulnerable behavior is not simply a bad filesystem join. It is a governance failure in how a cluster decides who can influence where storage lands on the host. That boundary matters because the rendered path is derived from Kubernetes objects, which means storage authorization and host authorization are now entangled. Practitioners should treat StorageClass templating as a trust decision, not a convenience feature.

HostPath exposure breaks the assumption that container policy alone describes privilege: The helper pod looks unprivileged to PodSecurity-style controls, but the real power comes from the mounted host filesystem. That means the control plane can approve a workload that still reaches sensitive host directories through a volume path. The implication is that policy models focused only on container privilege will miss the actual blast radius.

Path sanitization belongs in the storage lifecycle, not as an afterthought in remediation: A storage controller that renders paths from metadata needs the same level of lifecycle governance applied to credentials. The issue is not merely that traversal sequences are dangerous, but that the system trusted user-controlled input to define a host file location. Practitioners should re-evaluate whether their storage provisioning logic is enforcing the same trust boundary they assume in IAM and IGA.

K3s defaults illustrate how convenience features can silently widen the attack surface across the edge stack: When a default provisioner becomes the primary storage backend, every downstream workload inherits its trust model. That makes the exposure especially relevant in edge, lab, and CI/CD environments where K3s is chosen for simplicity. The practical conclusion is that defaults need explicit governance review before they are accepted as safe infrastructure.

Container escape is the wrong mental model if it hides the storage trust failure: This flaw behaves like an escape in outcome, but the root cause is mis-governed path construction and host-backed storage access. Framing it only as escape risk underplays the upstream control gap. The better lesson is that identity, storage, and host access must be governed together whenever workload input can shape filesystem targets.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: NHI Lifecycle Management Guide

What this signals

PathPattern governance: The practical control point is not the PVC itself but whether a StorageClass allows user input to shape a host path. Once that happens, storage provisioning becomes an identity and authorization problem, because the cluster is effectively translating metadata into filesystem authority. Teams should review every custom template as a privileged trust decision rather than an implementation detail.

The vulnerability also shows why container policy alone is not enough. A pod can look compliant to privileged-container controls and still reach the host through a volume mount, so host-backed storage paths need explicit review in platform governance and admission policy. The lesson for practitioners is to align storage controls with the same trust rigor used for NHI and delegated access decisions.

For practitioners

• Audit every StorageClass path template Review pathPattern usage for any reference to PVC names, namespaces, labels, or annotations, and remove user-controlled inputs from host path construction.
• Block traversal sequences in admission controls Use admission policy to reject StorageClass values containing ../ or equivalent traversal patterns before they ever reach the provisioner.
• Restrict who can create or modify StorageClasses Limit StorageClass administration to trusted cluster operators and treat that permission as host-impacting authority, not routine namespace access.
• Inspect local-path-config for script tampering Check the ConfigMap that stores setup and teardown scripts, because anyone with edit rights can turn normal volume operations into arbitrary shell execution.
• Detect host-backed volume paths outside the base directory Alert when helper pods resolve to /etc, /root, /var/lib/kubelet, or other sensitive paths instead of the configured storage root.

Key takeaways

• The flaw is a path-joining and trust-boundary problem, not just a storage bug, because user-controlled metadata can reach the host filesystem.
• The article describes a critical host-impacting condition in K3s deployments, especially where StorageClasses template against PVC data.
• The limiting control is to remove user influence from path construction and treat StorageClass authority as a privileged governance surface.

Key terms

• StorageClass Templating: StorageClass templating is the practice of building a storage path or mount target from metadata supplied by Kubernetes objects. In this case, the template becomes a security boundary because unchecked user input can determine where host files are created, read, or deleted.
• HostPath-backed Provisioning: HostPath-backed provisioning maps container or helper-pod activity onto the node filesystem instead of an isolated virtual store. That model can be safe when tightly governed, but it creates host-impacting reach whenever the controller accepts untrusted path input or unsafe volume mounts.
• Path Traversal in Provisioning Logic: Path traversal in provisioning logic occurs when special sequences such as ../ let an attacker escape an intended directory and reach another filesystem location. In storage controllers, the risk is amplified because the resulting path may be executed against the host, not just recorded as metadata.
• Host-Level Identity Boundary: A host-level identity boundary is the point where workload authority stops and node authority begins. When storage templates or helper pods can cross that line, the cluster is no longer just allocating volumes, it is delegating filesystem power with real operational impact.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.