CVE-2025-62878: 
vulnerability analysis and mitigation

CVE-2025-62878 is a critical path traversal vulnerability in the Rancher local-path-provisioner that allows a low-privileged attacker to manipulate the parameters.pathPattern field in StorageClass definitions to create PersistentVolumes at arbitrary locations on the host node. It affects all versions of github.com/rancher/local-path-provisioner prior to v0.0.34, and is also present in IBM Observability with Instana (OnPrem). The vulnerability was published to the GitHub Advisory Database on February 4, 2026, and to the NVD on February 25, 2026. It carries a CVSS v3.1 base score of 9.9 (Critical) (GitHub Advisory, IBM Advisory).

The root cause is insufficient validation and normalization of the parameters.pathPattern field in StorageClass definitions, classified as CWE-23 (Relative Path Traversal). The vulnerable code resides in provisioner.go at line 381, where user-controlled template values (e.g., {{ .PVC.Namespace }} and {{ .PVC.Name }}) are rendered into a filesystem path without sanitizing .. sequences. An attacker with permissions to create or modify StorageClass objects can craft a pathPattern such as {{ .PVC.Namespace }}/{{ .PVC.Name }}/../../../../../etc/new-dir, causing the provisioner to create a PersistentVolume pointing to /etc/new-dir on the host node instead of a path under the configured base directory. A public proof-of-concept is available on GitHub (GitHub Advisory, PoC).

Successful exploitation allows an attacker to create PersistentVolumes that map to arbitrary host filesystem locations, enabling overwriting of sensitive system files (e.g., in /etc), unauthorized read access to unintended directories, and potential full compromise of the Kubernetes node. Because the scope is changed (S:C in CVSS), the impact extends beyond the Kubernetes pod boundary to the underlying host node, enabling privilege escalation and lateral movement within the cluster. Confidentiality, integrity, and availability are all rated High, reflecting the potential for complete node takeover (GitHub Advisory, Orca Security).

1. Reconnaissance: Identify Kubernetes clusters running the Rancher local-path-provisioner at a version prior to v0.0.34 using kubectl get pods -A | grep local-path or by inspecting the provisioner image tag.
2. Verify permissions: Confirm that the attacker's account has create or update permissions on StorageClass objects via kubectl auth can-i create storageclasses.
3. Craft malicious StorageClass: Create a StorageClass YAML with a traversal payload in parameters.pathPattern, for example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: malicious-sc
provisioner: rancher.io/local-path
reclaimPolicy: Delete
parameters:
  pathPattern: "{{ .PVC.Namespace }}/{{ .PVC.Name }}/../../../../../etc/attacker-dir"
volumeBindingMode: WaitForFirstConsumer

4. Apply the StorageClass: Run kubectl apply -f malicious-sc.yaml to register the malicious StorageClass in the cluster.
5. Trigger provisioning: Create a PersistentVolumeClaim referencing the malicious StorageClass. When a pod consuming the PVC is scheduled, the provisioner resolves the path and creates a directory at /etc/attacker-dir on the host node.
6. Achieve objective: Mount the PVC in a pod to read from or write to the host path, enabling file overwrite (e.g., replacing /etc/cron.d entries), sensitive data exfiltration, or further privilege escalation on the node (GitHub Advisory, PoC).

• Kubernetes API Logs: Audit log entries showing create or update operations on StorageClass resources by non-admin users, especially with parameters.pathPattern values containing .. sequences.
• StorageClass Definitions: Presence of StorageClass objects with pathPattern values containing relative path elements (e.g., ../, ..%2F) or paths resolving outside the expected base directory (e.g., /etc, /var, /root).
• File System (Host Node): Unexpected directories created in sensitive locations such as /etc/, /var/, or /root/ that correspond to PVC namespace/name patterns; new or modified files in those directories owned by the provisioner service account.
• PersistentVolume Objects: PersistentVolumes with hostPath values pointing outside the configured local-path base directory (typically /opt/local-path-provisioner/).
• Process/Container Activity: Pods mounting PVCs from the suspicious StorageClass performing unusual file read/write operations on host-mounted paths; unexpected child processes spawned from within such pods (GitHub Advisory, Orca Security).

The vulnerability is fully addressed in local-path-provisioner v0.0.34, which validates and normalizes pathPattern values to ensure all generated paths resolve under the configured base directory, rejecting any traversal attempts. There are no workarounds — the vendor explicitly states that users must upgrade to v0.0.34 or later to mitigate the issue. As additional hardening measures, administrators should restrict StorageClass create/update permissions to trusted users only, audit existing StorageClass definitions for suspicious pathPattern values, and implement Kubernetes RBAC policies limiting API server access (GitHub Advisory, IBM Advisory).

Orca Security published a dedicated technical blog post analyzing the vulnerability and its exploitation potential in Kubernetes environments (Orca Security). Security Online Info covered the vulnerability, initially describing it as a "Critical 10.0" issue, reflecting community concern about its severity (Security Online). The NVIDIA developer forums raised questions about when the local-path-provisioner would be updated to v0.0.34 in the context of BCM 11, indicating downstream product impact (NVIDIA Forums). Social media discussion on Bluesky and Mastodon highlighted the PoC availability and urged administrators to patch promptly.