CVE-2025-62878 — Critical Path Traversal in Rancher Local Path Provisioner (CVSS 10.0)

What it is

CVE-2025-62878 affects Rancher Local Path Provisioner versions prior to v0.0.34, patched January 6, 2026. The root cause is the pathFromPattern() function in provisioner.go, which renders a user-supplied pathPattern template (Go template syntax with access to PVC namespace, name, labels, annotations) with no sanitization before provisionFor() joins it with the base storage path via filepath.Join, which resolves ../ sequences.

How it works

Three attack vectors, in order of practical risk:

• PVC annotation injection (most dangerous): if a StorageClass templates pathPattern against PVC annotations — a documented customization pattern — any namespace user controls the resolved path through their own annotations. Kubernetes does not check whether a user has permission on the referenced StorageClass, so this works without cluster-admin.
• Direct StorageClass poisoning: a cluster-admin (or anyone with create storageclasses RBAC) sets pathPattern to something like ../../etc/cron.d directly.
• Post-patch bypass: even on v0.0.34, any StorageClass with allowUnsafePathPattern: "true" (a compatibility escape hatch added by the fix) bypasses validation entirely.

Once the path escapes the base directory, a helper pod executes shell scripts from the local-path-config ConfigMap against it: mkdir -m 0777 -p "$VOL_DIR" on provision, rm -rf "$VOL_DIR" on delete (with reclaimPolicy: Delete). That ConfigMap is itself user-editable, making it a second, separate trust boundary.

flowchart TD
    A[pathPattern template] --> B{Sanitized?}
    B -->|No, pre-0.0.34| C[filepath.Join resolves ../]
    B -->|allowUnsafePathPattern=true| C
    C --> D[Helper pod mkdir/rm -rf at resolved host path]
    D --> E[Host PKI, SSH keys, kubelet dirs exposed]

Since v0.0.26 the helper pod gets host access via a hostPath volume mount rather than privileged: true, so PodSecurity/OPA/PSP policies that only block privileged containers miss it entirely.

Preconditions / Affected

All versions before v0.0.34; the pathPattern feature itself only exists from v0.0.27, so v0.0.27–v0.0.33 carry the real risk. Default K3s installs are not exploitable out of the box — the embedded manifest ships with no pathPattern set, falling back to a hardcoded, non-user-controlled template. Exploitation requires someone with cluster-level RBAC to have first added a pathPattern to a StorageClass. Downstream distributions bundling the provisioner: K3s, k3d, Rancher Desktop, AKS Edge Essentials, Amazon EKS Anywhere, kind, Minikube, Deckhouse, SUSE Application Collection.

What to do

• Upgrade to v0.0.34.
• Audit StorageClasses for pathPattern referencing annotations/labels; restrict to static values.
• Restrict create/update RBAC on StorageClasses and on the local-path-config ConfigMap.
• Deploy Kyverno/OPA policies rejecting pathPattern values containing ../.
• If unused, disable the provisioner: --disable local-storage.
• Detection queries given for audit logs:

event.verb IN ("create", "update") AND
event.objectRef.resource = "storageclasses" AND
event.requestObject.parameters.pathPattern CONTAINS "../"

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

Also alert on any StorageClass with allowUnsafePathPattern set to "true".

Caveats

Orca disputes the CVSS 10.0 score: a 10.0 requires Privileges Required: None, but the primary vector needs create storageclasses RBAC (cluster-admin-level), and the lower-privilege annotation vector still depends on a pre-existing StorageClass configured to template user-controlled fields. Orca estimates actual severity at 8.4–9.1. No in-the-wild exploitation or public PoC as of February 9, 2026, though the advisory's example YAML is functionally a working PoC.