文章总结： 文章深度剖析RancherLocalPathProvisionerCVE-2025-62878高危漏洞，该漏洞源于路径清洗缺失，允许攻击者通过StorageClass或PVC注解注入实现主机文件系统读写与容器逃逸。虽默认K3s环境不受影响，但使用自定义模板配置的集群面临严重风险。建议立即升级至v0.0.34版本，收紧RBAC权限，审计StorageClass配置，并利用提供的检测规则排查潜在威胁。 综合评分： 91 文章分类： 漏洞分析,漏洞预警,云安全
CVSS 10.0！Rancher漏洞致K3s集群面临容器逃逸风险
Dubito Dubito
云原生安全指北
2026年2月12日 08:35 江苏
注：本文翻译自 ORCA Security 的文章《Path Traversal in Rancher Local Path Provisioner Enables Host Filesystem Compromise Across K3s Clusters》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
2026年2月4日，Rancher Local Path Provisioner披露了一则严重漏洞（CVE-2025-62878[2]，CVSS 10.0）。该漏洞影响低于 v0.0.34 版本[3]的所有Rancher Local Path Provisioner（注：Rancher本地路径分配器），而该组件是每个K3s集群的默认存储后端。此缺陷允许已认证的攻击者通过向StorageClass路径模板注入遍历字符串，对底层主机文件系统中的任意目录执行读取、写入和删除操作。目前尚未观察到实际利用行为，但攻击只需几行Kubernetes YAML即可发起。请立即升级至v0.0.34[4]。
二、概要速览
| 属性 | 详情 | | — | — | | CVE | CVE-2025-62878 | | 严重性 | 严重 (厂商评定CVSS 10.0，详见下方Orca安全研究分析) | | CWE | CWE-235 | | 受影响产品 | Rancher Local Path Provisioner | | 受影响版本 | < v0.0.34 (修复版本之前的所有版本) | | 攻击向量 | 网络 (Kubernetes API) | | 认证要求 | 低（任意命名空间内创建PVC）至高（创建StorageClass） | | 利用复杂度 | 低 | | 用户交互 | 无 | | 活跃利用 | 否 | | PoC 公开 | 否 (但利用只需简单的YAML) | | CISA KEV | 否 | | 修复方案 | 已提供 – v0.0.34 |
三、什么是 Rancher Local Path Provisioner？
Rancher Local Path Provisioner[6] 用于在节点本地磁盘上动态创建持久卷。它作为K3s中的默认StorageClass（存储类）发布，因此任何未指定其他StorageClass的PVC（PersistentVolumeClaim，持久卷声明）都会自动路由至该组件。K3s广泛部署于边缘计算、物联网、CI/CD 流水线（pipeline）及开发环境中。
该组件的 Docker Hub 镜像[7]累计拉取量超过1亿次，平均每周约75万次。一旦攻击者攻陷该分配器，便能直接从Kubernetes API直通集群中每个节点的主机文件系统。
四、技术分析
漏洞根源在于 provisioner.go[8] 中的 pathFromPattern() 函数完全缺乏路径清洗机制。Local Path Provisioner 允许操作员通过 StorageClass 上的 pathPattern 参数，自定义PV数据目录在节点上的存放位置。该参数接受 Go 模板语法，并可访问 PVC 元数据（命名空间、名称、标签、注解）。在受影响版本中，渲染后的模板未经任何校验即被直接使用。
调用函数 provisionFor() 通过 filepath.Join 将该未经验证的输出与配置的基路径拼接，而 filepath.Join 会解析 ../ 字符串。若将 pathPattern 设置为 ../../etc/cron.d，解析后的路径将完全逃逸基础目录（独立部署时为 /opt/local-path-provisioner，K3s 中为 /var/lib/rancher/k3s/storage）。
接下来的问题使该漏洞比常规路径遍历更为严重。分配器会启动一个 Helper Pod，针对解析后的路径执行 Shell 脚本。默认的创建脚本运行 mkdir -m 0777 -p "$VOL_DIR"，默认的销毁脚本运行 rm -rf "$VOL_DIR"。这些脚本存放在 local-path-config ConfigMap（位于 local-path-storage 命名空间，或在 K3s 中位于 kube-system）中，且用户可编辑。因此，分配器的安全性还依赖于保护该 ConfigMap 的 RBAC 权限。任何能修改此 ConfigMap 的人，都可在后续每次 PVC 创建或删除时，注入拥有主机文件系统访问权限的任意 Shell 命令。此问题虽非 CVE-2025-62878 本身，但与其处于相同的信任边界，建议在修复 pathPattern 的同时一并审计。
现有报道普遍忽略了一个技术细节：自 v0.0.26 版本起，Helper Pod 不再以 privileged: true 运行。它改通过挂载 hostPath 卷来获取主机文件系统访问权限。因此，那些阻断特权容器的 PodSecurity 准入控制器、OPA 策略以及传统的 PodSecurityPolicy 均无法拦截该 Pod。从策略视角看，该 Pod 表现为非特权，其对主机的访问是通过挂载操作静默实现的，而非源于安全上下文。
攻击向量共三种：
- 1. 直接 StorageClass 投毒： 集群管理员（或任何拥有 StorageClass 创建 RBAC 权限的用户）通过定义恶意 StorageClass，在
pathPattern中嵌入遍历字符串。此方法最直接，但需要较高权限。 - 2. PVC 注解注入： 这是最危险的向量。如果现有 StorageClass 针对 PVC 注解（annotation）进行模板化（一种用于灵活路径定制的常见模式），那么任意命名空间用户均可通过其注解控制渲染后的路径。Kubernetes[9] 在创建 PVC 时不会校验用户对所引用 StorageClass 的权限，因此分配器会直接处理该请求。这将所需权限从集群管理员降级为任意命名空间用户。
- 3. 补丁后绕过： 即使在 v0.0.34 版本，如果集群在任何 StorageClass 上设置了
allowUnsafePathPattern: "true"（修复版本中为兼容旧配置引入的逃逸出口），则两层校验均会被完全绕过，集群仍处于完全脆弱状态。
一旦攻击者控制了解析后的路径，便可创建 PVC， Helper Pod 随即在目标主机路径上执行 mkdir -m 0777 -p；随后任何挂载该 PV 的 Pod 都将获得该路径的读写权限。若使用 reclaimPolicy: Delete 删除 PVC， Helper Pod 会在同一路径执行 rm -rf。由此，影响迅速升级：通过将 PV 指向 /etc/kubernetes/pki/ 可读取集群 PKI 材料；向 /etc/cron.d/ 或 /root/.ssh/authorized_keys 写入数据可实现主机代码执行；删除 /etc/kubernetes 或 /var/lib/kubelet 则可摧毁关键基础设施。由于 StorageClass 是集群作用域（cluster-scoped）资源，单个恶意 StorageClass 即影响所有节点。这实质上是一种容器逃逸：攻击者虽未从容器内部突破，但实际获得了同等的主机控制能力。
在生产环境、边缘端或 CI/CD 流水线中运行 K3s 的组织应将此漏洞列为高优先级处理。默认部署、利用简单以及主机级影响这三重因素叠加，使得该漏洞必须在公开 PoC 加速攻击进程前完成修复。对于使用自定义 pathPattern 或基于注解模板的团队，应视为紧急任务。
五、受影响版本
| 分支 | 受影响版本 | 修复版本 | 备注 | | — | — | — | — | | Local Path Provisioner | < v0.0.34[3] | v0.0.34[4] | 依据 GitHub 安全公告 GHSA-jr3w-9vfr-c746[10] |
该安全公告将 v0.0.34 之前[3]的所有版本标记为受影响。pathPattern 特性自 v0.0.27 版本引入，因此 v0.0.27 至 v0.0.33 版本存在最实际的利用风险。更早版本虽不具备此特性，但仍可能被扫描器标记。无论如何，所有低于 v0.0.34 的版本都应升级。
下游集成 Local Path Provisioner 的发行版包括：K3s（默认 StorageClass）、k3d、Rancher Desktop、AKS Edge Essentials（微软 Azure）、Amazon EKS Anywhere、kind 和 Minikube、Deckhouse Kubernetes Platform 以及 SUSE Application Collection。其中 K3s 集群因其默认 StorageClass 行为，需特别关注。
六、威胁态势
利用活动： 截至 2026 年 2 月 9 日，未观察到野外利用行为。未列入 CISA 已知被利用漏洞目录。GitHub 安全公告评定该漏洞为严重，CVSS 10.0 分。
PoC 公开状态： 尚未发布正式的概念验证代码。然而，安全公告本身已包含一个可工作的恶意 StorageClass YAML，实质上已构成 PoC。无需 Shellcode、无需内存破坏、无需时序技巧——仅需 YAML。
攻击归因： 尚未发布相关的威胁行为者归因信息。
七、Orca 安全研究分析：默认 K3s 安装与 CVSS 上下文
默认的 K3s 开箱即用并不可被利用。这是公开报道中缺失的最重要细节。K3s 嵌入式 Manifest[11]（即 k3s-io/k3s 中的 local-storage.yaml）在默认 StorageClass 上并未设置 pathPattern。当 pathPattern 未设置时，分配器会回退至硬编码模板（{{ .PVName }}{{ .PVC.Namespace }}{{ .PVC.Name }}），该模板完全由下划线连接的系统内部生成值构成，用户无法控制注入。因此，要实现主要攻击向量，必须由拥有集群级 RBAC 权限的用户先行创建或修改一个 StorageClass 以添加 pathPattern。这并未降低该漏洞对于使用自定义模板或基于注解路径的环境的严重性，但意味着：未经集群管理员事先操作，纯粹的 K3s 安装环境并不能直接被利用。
CVSS 10.0 的评分同样需要置于上下文中理解。CVSS v3.1 标准下的 10.0 分要求权限需求（Privileges Required）为无。而创建恶意 StorageClass 需要 create storageclasses 的 RBAC 权限，这是一种通常仅授予管理员的集群级权限。权限要求更低的 PVC 注解向量虽将权限需求降为任意命名空间用户，但它依赖于一个已存在的、且已针对用户可控注解进行模板化的 StorageClass——这是一种配置选择，而非默认配置。更精确的评分会根据攻击向量不同落在 8.4 至 9.1 分之间，同时作用域变更（Scope Changed）应反映从容器到主机的边界跨越。尽管如此，这仍属于严重级别，仍需立即修复。但团队在处理此漏洞时，若需与真正无需认证、零交互的远程代码执行漏洞进行优先级排序，应权衡其实际的权限要求。
八、修复方案
8.1 首要行动
升级至 Local Path Provisioner v0.0.34（发布于 2026 年 1 月 6 日）。
| 部署类型 | 修复操作 |
| — | — |
| K3s 集群 | 升级至集成了 Local Path Provisioner v0.0.34 的 K3s 发行版，或手动替换 Provisioner 部署镜像。 |
| 独立 Helm / YAML | 更新容器镜像至 rancher/local-path-provisioner:v0.0.34 并重新部署。 |
| k3d / Rancher Desktop | 更新至附带已修复 Provisioner 的最新版本。 |
| AKS Edge Essentials / EKS Anywhere | 查阅厂商文档，获取更新的 Provisioner 镜像。 |
8.2 临时缓解措施
厂商安全公告指出暂无变通方案，v0.0.34 是唯一完整的修复版本。在规划升级期间，以下加固步骤可降低暴露面：
- • 审计所有 StorageClass 中引用了用户可控字段（注解、标签）的
pathPattern参数，并将其限制为静态值。 - • 收紧 RBAC 权限，将 StorageClass 的创建和修改权限限制于受信任的集群管理员。
- • 检查
local-path-configConfigMap（位于local-path-storage或kube-system命名空间）中的 setup 或 teardown 脚本是否被篡改，并限制其编辑权限。 - • 部署 OPA Gatekeeper 或 Kyverno 准入策略，拒绝包含
../序列的pathPattern值的 StorageClass。 - • 对于非关键依赖本地路径存储的集群，可通过
--disable local-storage完全禁用该分配器。
8.3 入侵后排查要点
若您的集群曾运行存在漏洞的版本，并且存在针对用户可控 PVC 元数据进行模板化的 StorageClass，请审查 PVC 创建审计日志中是否包含遍历字符串的注解值。检查节点文件系统中是否存在配置的基础目录之外的意外目录。若无法排除未经授权的主机文件系统访问行为，请轮换所有集群 PKI 材料及 kubeconfig 凭证。
九、检测指引
9.1 主机级指标
监控 Helper Pod 日志，留意解析至配置的基础目录之外的卷路径。基础路径因部署而异：独立部署默认为 /opt/local-path-provisioner，K3s 默认为 /var/lib/rancher/k3s/storage。检测规则需覆盖上述两种情况。重点关注针对 /etc、/root、/var/lib/kubelet 或 /etc/kubernetes 等敏感目录执行的 mkdir 或 rm -rf 操作。
9.2 Kubernetes API 指标
审计 StorageClass 的创建/更新事件，检查 pathPattern 参数是否包含 ../ 字符串。监控 PVC 注解中的遍历载荷。对任何 allowUnsafePathPattern 设置为 true 的 StorageClass 发出告警。留意对 local-path-config ConfigMap 的意外修改。
9.3 Pod 安全盲区
阻断特权容器的标准控制措施无法标记此 Helper Pod。它通过挂载 hostPath 卷而非设置 privileged: true 来获取主机访问权限。依赖基于安全上下文（securityContext）策略的组织，需要针对指向敏感目录的 hostPath 卷制定明确的规则。
# Kubernetes 审计日志查询（伪代码）
event.verb IN ("create", "update") AND
event.objectRef.resource = "storageclasses" AND
event.requestObject.parameters.pathPattern CONTAINS "../"
# ConfigMap 篡改检测
event.verb IN ("update", "patch") AND
event.objectRef.resource = "configmaps" AND
event.objectRef.name = "local-path-config"
十、Orca 如何提供帮助？
Orca 云安全平台[12] 能够帮助安全团队在数分钟内对 CVE-2025-62878[2] 等威胁做出响应。
- • 即时发现： 识别云及 Kubernetes 环境中运行存在漏洞的 Local Path Provisioner 版本的云资产。
- • 上下文感知优先级分析： 清晰了解哪些易受攻击的资产[13]暴露在公网、处于生产环境或包含敏感数据——从而优先聚焦最重要风险。
- • 攻击路径分析： 理解该漏洞是否构成通向关键资产的路径，或能否与其他风险进行链式利用。
借助 Orca，受 CVE-2025-62878 影响的客户能够快速识别其暴露面，并确保安全团队优先聚焦于最关键的 K3s 集群及边缘部署。
引用链接
[1] 《Path Traversal in Rancher Local Path Provisioner Enables Host Filesystem Compromise Across K3s Clusters》: https://orca.security/resources/blog/cve-2025-62878-rancher-local-path-provisioner/
[2] CVE-2025-62878: https://github.com/advisories/GHSA-jr3w-9vfr-c746
[3] 低于 v0.0.34 版本: https://github.com/rancher/local-path-provisioner/pull/542
[4] v0.0.34: https://github.com/rancher/local-path-provisioner/releases/tag/v0.0.34
[5] CWE-23: https://cwe.mitre.org/data/definitions/22.html
[6] Rancher Local Path Provisioner: https://github.com/rancher/local-path-provisioner
[7] Docker Hub 镜像: https://hub.docker.com/r/rancher/local-path-provisioner
[8] provisioner.go: https://github.com/rancher/local-path-provisioner/blob/master/provisioner.go
[9] Kubernetes: https://orca.security/glossary/kubernetes-security/
[10] GHSA-jr3w-9vfr-c746: https://github.com/rancher/local-path-provisioner/security/advisories/GHSA-jr3w-9vfr-c746
[11] K3s 嵌入式 Manifest: https://github.com/k3s-io/k3s/blob/master/manifests/local-storage.yaml
[12] Orca 云安全平台: https://orca.security/platform/
[13] 易受攻击的资产: https://orca.security/platform/vulnerability-management/
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito Dubito《CVSS 10.0！Rancher漏洞致K3s集群面临容器逃逸风险》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论