Podman曝CVSS 10.0严重容器逃逸漏洞(CVE-2026-94603)，恶意镜像可绕过沙箱限制

原创

tuto
tuto

杂杂咱谈

2026年9月30日 11:23
福建

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

一、漏洞概述

Podman被披露存在严重安全漏洞CVE-2026-94603，CVSS v3评分达到10.0(Critical)。漏洞与Podman支持的容器Checkpoint镜像恢复机制有关，攻击者可通过构造恶意容器镜像，使其在执行podman run时控制容器的创建参数。

该漏洞的核心问题在于当Podman识别到镜像包含特定的Checkpoint注释后，会将其视为Checkpoint镜像，并在恢复容器时忽略用户指定的部分安全限制。

例如，管理员在运行容器时通过--cap-drop删除全部Linux Capabilities，但恶意Checkpoint镜像可以使这些用户指定的限制被忽略，并按照镜像自身保存的配置创建容器。如果镜像携带完整Capabilities等高权限配置，攻击者可能进一步削弱容器隔离机制，增加容器逃逸及主机受影响的风险。

该功能最早于Podman 4.4.0引入。目前尚无已确认的在野利用或公开PoC。官方已通过移除相关Checkpoint功能进行修复。

二、技术细节

1. 漏洞根因

CVE-2026-94603漏洞源于Podman的OCI容器Checkpoint镜像恢复功能。

Podman 4.4.0开始支持将容器Checkpoint通过OCI Registry进行共享，并可以通过podman run恢复Checkpoint容器。

正常情况下，用户可以通过运行参数控制容器的安全边界，例如：

--cap-drop=all

用于删除容器的Linux Capabilities。

但Checkpoint并不仅仅保存容器文件系统，同时还记录了容器创建和运行所需的配置状态，其中包括Capabilities等安全相关参数。

当Podman检测到镜像包含特定的Checkpoint Annotation：

io.podman.annotations.checkpoint.runtime.name

后，会将其作为Checkpoint镜像处理。

问题在于，旧版本Podman在恢复此类镜像时，会忽略用户提供的部分容器创建参数，转而使用Checkpoint中保存的配置。

因此形成以下安全边界问题：

用户安全配置           │        ├── --cap-drop=all           │          ▼      Podman run           │         │ 检测到Checkpoint Annotation         ▼     Checkpoint恢复逻辑          │         X 忽略部分用户配置          │           ▼     使用镜像自身的容器配置          │        ▼     恶意镜像控制容器运行方式

这意味着原本由管理员设置的容器安全限制可能无法按照预期生效。

2. 攻击流程

攻击者可以通过以下方式构造攻击链：

攻击者         │        ▼     构造恶意Checkpoint镜像         │         ├── 设置Checkpoint Annotation        ├── 保存高权限Capabilities        └── 保存特定容器运行配置        │        ▼     上传至OCI Registry        │        ▼     诱导目标主机拉取并执行镜像       │       ▼    podman run        │        ▼     Podman识别Checkpoint镜像        │        ▼      忽略用户指定的安全限制         │       ▼     按照恶意镜像配置启动容器        │       ▼     容器隔离机制被削弱        │        ▼    进一步尝试容器逃逸 / 影响宿主机

其中最关键的一点是镜像能够影响Podman最终如何创建和运行容器。

这破坏了传统容器运行模型中管理员通过命令行参数决定安全边界的假设。

3. 漏洞影响

成功利用该漏洞后，恶意镜像可能绕过管理员设置的部分安全限制，包括：

• --cap-drop等Capabilities限制;
• 部分容器隔离配置；
• 用户预期的运行时安全参数；
• 容器沙箱边界。

如果攻击者构造的恶意Checkpoint镜像包含高权限Capabilities，则可能进一步扩大容器内部权限，并在存在其他容器逃逸条件的情况下影响宿主机。

因此，该漏洞的主要风险为：

恶意镜像 → 覆盖用户安全配置 → 容器权限提升 → 削弱沙箱隔离 → 潜在容器逃逸

目前公开信息并未确认该漏洞已经在野利用，也没有确认存在公开可直接实现宿主机接管的PoC。

三、受影响版本

该Checkpoint功能从Podman 4.4.0开始引入，因此：

官方通过移除相关Checkpoint镜像运行功能解决该问题，因此升级后的podman run将不再支持此类Checkpoint镜像。

四、漏洞信息

五、漏洞利用条件

该漏洞与传统的远程未认证漏洞有所不同，漏洞攻击者利用的前提是首先需要让目标环境拉取并运行恶意Checkpoint镜像。

典型场景包括：

• 用户从不可信Registry拉取容器镜像；
• CI/CD流水线自动执行第三方镜像；
• 自动化系统使用外部镜像进行构建或部署；
• 管理员误将恶意Checkpoint镜像作为普通容器镜像运行。

因此，对于运行不受信任镜像的Podman主机，该漏洞风险尤其值得关注。

六、修复与缓解建议

1. 升级Podman

官方建议升级至以下安全版本：

Podman 5.8.8+      Podman 6.1.3+

升级后，相关Checkpoint镜像运行功能已被移除。

2. 暂时无法升级时检查镜像

如果暂时无法升级，应对拉取的OCI镜像进行检查，重点查找：

io.podman.annotations.checkpoint.runtime.name

如果发现镜像包含该Annotation，应将其视为高风险Checkpoint镜像，在确认来源和可信度之前不要执行。

需要注意的是，Podman自身无法自动替管理员完成这类镜像安全审查，因此建议在镜像进入生产环境前增加Registry或CI/CD侧的检查机制。

3. 限制第三方镜像

• 使用可信的内部Registry；
• 对外部镜像进行签名验证；
• 建立镜像Allowlist；
• 禁止生产环境直接运行来源不明的镜像；
• 在CI/CD流程中增加镜像静态检查；
• 对Checkpoint相关Annotation进行检测。

4. 不要仅依赖--cap-drop

该漏洞特别值得注意的一点是：即使管理员在运行容器时显式配置：

--cap-drop=all

旧版本Checkpoint恢复机制仍可能忽略该配置。

因此，在受影响版本上，单纯增加--cap-drop等运行参数并不能彻底解决该问题，升级Podman才是主要修复措施。

七、安全建议

对于使用Podman运行第三方或不受信任镜像的环境，建议立即进行版本排查。

1. 当前Podman是否为4.4.0及以上版本；
2. 是否运行来自外部Registry的镜像；
3. 是否存在Checkpoint镜像；
4. io.podman.annotations.checkpoint.runtime.name是否有无存在；
5. 是否在CI/CD中自动执行第三方镜像；
6. 是否对镜像来源和签名进行验证；
7. 是否能够升级至5.8.8或6.1.3。

CVE-2026-94603 #Podman