Path Traversal in Rancher Local Path Provisioner Enables Host Filesystem Compromise Across K3s Clusters

Introduction

A critical vulnerability (CVE-2025-62878, CVSS 10.0) was disclosed on February 4, 2026 affecting all versions of Rancher’s Local Path Provisioner prior to v0.0.34, the default storage backend for every K3s cluster. The flaw allows authenticated attackers to read, write, and delete arbitrary directories on the underlying host filesystem by injecting traversal sequences into a StorageClass path template. No exploitation has been observed yet, but the attack requires nothing more than a few lines of Kubernetes YAML. Upgrade to v0.0.34 immediately.

Quick Overview

What is Rancher Local Path Provisioner?

Rancher Local Path Provisioner dynamically creates persistent volumes on local node disks. It ships as the default StorageClass in K3s, so any PVC that does not specify a different StorageClass routes through it automatically. K3s is widely deployed across edge computing, IoT, CI/CD pipelines, and development environments.

The Docker Hub image has over 100 million total pulls and averages roughly 750,000 pulls per week. Compromising the provisioner gives an attacker a direct path from the Kubernetes API to the host filesystem of every node in the cluster.

Technical Analysis

The root cause is a complete absence of path sanitization in a single function: pathFromPattern() inside provisioner.go. Local Path Provisioner lets operators customize where PV data directories land on nodes via a pathPattern parameter on the StorageClass. This parameter accepts Go template syntax with access to PVC metadata (namespace, name, labels, annotations). In vulnerable versions, the rendered template was passed through with no validation whatsoever.

The calling function, provisionFor(), joined this unsanitized output with the configured base path using filepath.Join, which resolves ../ sequences. Set pathPattern to ../../etc/cron.d, and the resolved path escapes the base directory (/opt/local-path-provisioner for standalone, /var/lib/rancher/k3s/storage for K3s) entirely.

What happens next is what makes this worse than a typical path traversal. The provisioner spawns a helper pod to execute shell scripts against that resolved path. The default setup script runs mkdir -m 0777 -p “$VOL_DIR”. The default teardown script runs rm -rf “$VOL_DIR”. These scripts live in the local-path-config ConfigMap (local-path-storage namespace, or kube-system in K3s) and are user-editable. So the provisioner’s security also depends on RBAC protecting that ConfigMap. Anyone who can modify it can inject arbitrary shell commands that execute with host filesystem access on every subsequent PVC create or delete. This is a separate issue from CVE-2025-62878 but shares the same trust boundary problem and is worth auditing alongside the pathPattern fix.

A subtlety that existing coverage misses entirely: since v0.0.26, the helper pod does not run with privileged: true. It gains host filesystem access through a hostPath volume mount instead. PodSecurity admission controllers, OPA policies, and legacy PodSecurityPolicies that block privileged containers will not catch it. The pod looks unprivileged from a policy perspective. The host access comes silently through the mount, not the security context.

There are three attack vectors:

1. Direct StorageClass poisoning: A cluster-admin (or anyone with StorageClass creation RBAC) defines a malicious StorageClass with traversal sequences in pathPattern. Simplest vector, but requires elevated privileges.
2. PVC annotation injection: This is the most dangerous one. If an existing StorageClass templates against PVC annotations (a documented pattern for flexible path customization), any namespace user controls the rendered path through their annotations. Kubernetes does not verify whether a user has permissions on the referenced StorageClass when creating a PVC, so the provisioner processes the request regardless. This downgrades the required privilege from cluster-admin to any namespace user.
3. Post-patch bypass: Even on v0.0.34, clusters that set allowUnsafePathPattern: “true” on any StorageClass (a backward-compatibility escape hatch introduced in the fix) completely bypass both validation layers and remain fully vulnerable.

Once an attacker controls the resolved path, they create a PVC, the helper pod runs mkdir -m 0777 -p at the target host path, and any pod mounting the resulting PV gets read/write access. On deletion with reclaimPolicy: Delete, the helper pod runs rm -rf on the same path. From there, the impact escalates quickly: read cluster PKI material by pointing a PV at /etc/kubernetes/pki/, achieve host code execution by writing to /etc/cron.d/ or /root/.ssh/authorized_keys, or destroy critical infrastructure by deleting /etc/kubernetes or /var/lib/kubelet. Since StorageClass is cluster-scoped, a single malicious one affects every node. This is effectively a container escape: the attacker never breaks out of a container, but gains the same practical capability.

Organizations running K3s in production, at the edge, or in CI/CD pipelines should treat this as high priority. The combination of default deployment, trivial exploitation, and host-level impact makes this one to patch before a public PoC accelerates the timeline. Teams running custom pathPatterns or annotation-based templating should treat it as urgent.

Affected Versions

The advisory marks all versions prior to v0.0.34 as affected. The pathPattern feature was introduced in v0.0.27, so v0.0.27 through v0.0.33 carry the most practical risk. Earlier versions lack the feature but may still be flagged by scanners. Regardless, anything older than v0.0.34 should be upgraded.

Downstream distributions bundling Local Path Provisioner include K3s (default StorageClass), k3d, Rancher Desktop, AKS Edge Essentials (Microsoft Azure), Amazon EKS Anywhere, kind and Minikube, Deckhouse Kubernetes Platform, and SUSE Application Collection. K3s clusters warrant particular attention because of the default StorageClass behavior.

Threat Status

Exploitation Activity: No exploitation observed in the wild as of February 9, 2026. Not listed in CISA’s Known Exploited Vulnerabilities catalog. GitHub advisory rates this Critical with CVSS 10.0.

PoC Availability: No formal proof-of-concept has been published. That said, the advisory itself contains a working malicious StorageClass YAML that is functionally a PoC. No shellcode, no memory corruption, no timing tricks. Just YAML.

Attribution: No threat actor attribution has been published.

Orca’s Security Research Analysis: Default K3s Installations and CVSS Context

Default K3s is not exploitable out of the box. This is the most important nuance missing from public coverage. The K3s embedded manifest (local-storage.yaml in k3s-io/k3s) ships with no pathPattern on the default StorageClass. When pathPattern is unset, the provisioner falls back to a hardcoded template ({{ .PVName }}{{ .PVC.Namespace }}{{ .PVC.Name }}) composed entirely of internally generated values joined by underscores. No user-controlled injection is possible. For the primary attack vector to work, someone with cluster-level RBAC must first create or modify a StorageClass to add a pathPattern. This does not diminish the severity for environments using custom templates or annotation-based paths, but it means a vanilla K3s installation is not directly exploitable without prior cluster-admin action.

The CVSS 10.0 also deserves context. A 10.0 under CVSS v3.1 requires Privileges Required: None. Creating a malicious StorageClass requires the create storageclasses RBAC permission, a cluster-level privilege typically held only by administrators. The lower-privilege PVC annotation vector reduces this to any namespace user, but depends on a pre-existing StorageClass that already templates against user-controlled annotations, which is a configuration choice, not a default. A more precise score would land between 8.4 and 9.1 depending on the vector, with Scope Changed to reflect the container-to-host boundary crossing. Still firmly critical. Still demands immediate patching. But teams triaging this against truly unauthenticated, zero-interaction RCEs should weigh the actual privilege requirements when deciding what to patch first.

Remediation

Primary Action

Upgrade to Local Path Provisioner v0.0.34 (released January 6, 2026).

Interim Mitigations

The vendor advisory states there are no workarounds and v0.0.34 is the only full fix. While planning the upgrade, the following hardening steps can reduce exposure. 

• Audit all StorageClasses for pathPattern parameters that reference user-controlled fields (annotations, labels) and restrict them to static values. 
• Tighten RBAC so StorageClass creation and modification is limited to trusted cluster administrators. 
• Check the local-path-config ConfigMap (in local-path-storage or kube-system) for tampered setup or teardown scripts, and restrict edit access. 
• Deploy OPA Gatekeeper or Kyverno admission policies to reject StorageClasses with pathPattern values containing ../ sequences. 
• For clusters where local-path storage is not critical, disable the provisioner entirely with –disable local-storage.

Post-Compromise Considerations

If your cluster ran a vulnerable version with StorageClasses that template against user-controlled PVC metadata, review PVC creation audit logs for annotation values containing traversal sequences. Inspect node filesystems for unexpected directories outside the configured base path. Rotate all cluster PKI material and kubeconfig credentials if unauthorized host filesystem access cannot be ruled out.

Detection Guidance

Host-level indicators

Monitor helper pod logs for volume paths resolving outside the configured base directory. The base path differs by deployment: standalone defaults to /opt/local-path-provisioner, K3s defaults to /var/lib/rancher/k3s/storage. Detection rules must cover both. Watch for mkdir or rm -rf targeting sensitive directories like /etc, /root, /var/lib/kubelet, or /etc/kubernetes.

Kubernetes API Indicators

Audit StorageClass create/update events for pathPattern parameters containing ../ sequences. Monitor PVC annotations for traversal payloads. Alert on any StorageClass with allowUnsafePathPattern set to “true”. Watch for unexpected modifications to the local-path-config ConfigMap.

Pod security blind spot

Standard controls that block privileged containers will not flag the helper pod. It gets host access through a hostPath volume mount, not privileged: true. Organizations relying on securityContext-based policies need explicit rules for hostPath volumes targeting sensitive directories.

# Kubernetes audit log query (pseudocode)
event.verb IN ("create", "update") AND
event.objectRef.resource = "storageclasses" AND
event.requestObject.parameters.pathPattern CONTAINS "../"

# ConfigMap tampering detection
event.verb IN ("update", "patch") AND
event.objectRef.resource = "configmaps" AND
event.objectRef.name = "local-path-config"

# Kubernetes audit log query (pseudocode)
event.verb IN ("create", "update") AND
event.objectRef.resource = "storageclasses" AND
event.requestObject.parameters.pathPattern CONTAINS "../"

# ConfigMap tampering detection
event.verb IN ("update", "patch") AND
event.objectRef.resource = "configmaps" AND
event.objectRef.name = "local-path-config"

How Can Orca Help?

The Orca Cloud Security Platform enables security teams to respond to threats like CVE-2025-62878 within minutes.

• Instant Discovery: Identify cloud assets running vulnerable Local Path Provisioner versions across their cloud and Kubernetes environments
• Context-Aware Prioritization: See which vulnerable assets are internet-facing, in production, or contain sensitive data – focus on what matters first
• Attack Path Analysis: Understand if this vulnerability creates a path to critical assets or can be chained with other risks

With Orca, customers affected by CVE-2025-62878 were able to identify their exposure and ensure security teams are focused on the most critical K3s clusters and edge deployments first.