GitHub Security Advisories 在 2026 年 8 月 27 日公开了一项影响 Crossplane 包管理流程的高危安全问题 GHSA-mf7q-r4rv-jv94。该问题不是传统意义上的容器运行时逃逸，而是发生在 OCI 包安装过程中的“检查时与使用时不一致”（TOCTOU）：Crossplane 可能验证了一个已签名的镜像，随后却从同一个 tag 拉取到另一份未签名内容。
对普通 Kubernetes 集群用户来说，这条消息不意味着所有 Crossplane 环境都会立刻失陷。官方公告明确限定了触发前提：集群需要启用 Crossplane 包签名验证，安装时使用 tag 或语义化版本而不是 digest，并且包来自运营方无法完全控制的镜像仓库。满足这些条件的团队，应把它当作供应链信任链断裂问题尽快处理。
问题出在哪个环节
Crossplane 可以通过 ImageConfig 为包管理器配置 cosign 签名校验。正常流程应当是：解析镜像引用，确定不可变的内容摘要，对该内容验证签名，再拉取完全相同的内容并安装。这样签名绑定的是具体字节，而不是一个可能在仓库侧变化的标签。
GHSA-mf7q-r4rv-jv94 描述的缺陷在于，受影响的流程对 tag 引用分别执行了验证和拉取。攻击者控制或影响镜像仓库时，可以让第一次请求返回已签名镜像，第二次请求返回另一份未签名镜像。表面上日志会显示“签名验证通过”，实际进入集群的内容却可能没有经过同一份签名保护。
哪些环境需要优先排查
第一类是把 Crossplane 当作平台控制面的团队。Crossplane 会通过 Kubernetes 控制器协调云资源、基础设施和组合资源，包安装过程又可能引入 Providers、Functions 等扩展组件。若这些组件拥有较高的集群权限，供应链校验失效后的影响就不只是某个容器启动异常，还可能延伸到控制器能访问的 Kubernetes API、云平台凭据和基础设施对象。
第二类是启用了签名验证但仍普遍使用 tag 的环境。很多团队已经部署 cosign、准入策略或镜像扫描，因此容易误以为“看到验证成功就等于后续安装安全”。这起事件提醒我们，验证对象、拉取对象和最终运行对象必须是同一个 digest，不能只检查仓库名称或 tag 字符串。
第三类是从第三方或多方协作仓库安装包的环境。官方公告没有把问题描述为任意 Crossplane 用户都能远程利用的漏洞，风险依赖不受控注册表能够对不同请求返回不同内容。内部私有仓库、镜像代理和缓存层也应检查是否会重新解析 tag，以及是否保留并强制使用原始 digest。
版本与修复状态
GitHub Advisory 列出的受影响依赖为 github.com/crossplane/crossplane-runtime/v2：版本 2.3.0 至 2.3.2 受影响，首个修复版本为 2.3.3；预发布版本 2.4.0-rc.0 受影响，首个修复版本为 2.4.0-rc.1。公告同时说明修复已经合入主分支，并回移到 v2.3 与 v2.2 分支，Crossplane 侧将随 v2.3.3 与 v2.2.3 发布。
升级时不要只看 Crossplane 核心镜像的标签。还要确认实际运行的 Crossplane Runtime 依赖、Provider/Function 包版本以及平台团队自维护的镜像构建是否已经包含修复。预发布版本尤其不能仅因为版本号更高就判断为安全，必须以官方 release note 和实际 digest 为准。
运维人员怎么排查
先盘点配置：是否启用了 ImageConfig 签名验证，验证策略作用于哪些包，包来源包含哪些 OCI registry。再盘点安装记录：从 Kubernetes 对象、Crossplane 日志、GitOps 仓库和审计日志中整理近期安装或升级过的 package revision，记录当时使用的是 tag、版本号还是 digest。
重点检查同一个 package tag 在不同时间解析出的 digest 是否发生变化，以及 Crossplane 事件中记录的引用是否与镜像仓库、节点运行时实际拉取的 digest 一致。不要把“拉取成功”或“签名校验成功”当作充分证据。若无法建立验证摘要、安装摘要和运行摘要之间的对应关系，应先暂停从不受控仓库继续安装新包。
如果近期确实安装过受影响版本，建议保留相关审计日志和镜像元数据，核对 Provider、Function 的权限范围、ServiceAccount、Secret 引用和对外连接记录。发现异常时按供应链事件处理：隔离可疑包和相关凭据，保留现场，再根据组织应急流程决定回滚、吊销凭据或重建控制器。不要在没有备份和影响评估的情况下直接删除生产对象。
临时缓解与升级建议
最直接的临时缓解是按照官方建议使用 image digest 安装，而不是使用可变的 tag。digest 应来自可信的发布流程，并在配置、GitOps 清单和审批记录中保持一致。若仓库代理会自动改写引用，也要确认它不会在签名验证后重新按 tag 解析内容。
正式修复应安排在测试环境先升级，验证 Provider、Function、组合资源和云平台 API 调用，再选择业务窗口更新生产控制器。升级前备份关键清单和配置，记录当前版本、镜像摘要及回滚路径；重启或滚动更新控制器前评估基础设施编排是否会暂时停止。修复版本和发布节奏以 Crossplane 官方公告为准，不建议直接复制未经验证的第三方命令。
长期来看，签名校验应和 digest 固定、镜像来源限制、SBOM、漏洞扫描及 Kubernetes 准入策略一起建设。对高权限扩展包设置最小权限，对外部仓库采用白名单和镜像同步，对 tag 更新建立人工审批或自动变更审计。这样即使某个标签被仓库侧重新指向，也不会悄悄绕过整个发布链路。
不要忽略信任边界
这起事件的价值在于，它把一个常被忽略的工程细节暴露出来：安全检查不是一个孤立按钮，而是一条从“发布什么”到“验证什么”再到“运行什么”的完整链路。签名系统如果验证的是 A，安装系统拿到的是 B，那么前面的绿色结果并不能证明后面的内容可信。
目前公开信息显示，该问题没有分配 CVE，且官方公告把利用条件限定在特定配置组合内。运维团队应据此做风险分级，不必因为标题带有“供应链”就盲目停掉所有集群，但也不能因为没有 CVE 或没有公开在野利用就延后修复。完成版本确认、digest 固定、来源收敛和日志回溯，才是这类控制面组件更稳妥的处理顺序。
信息来源：GitHub Security Advisory GHSA-mf7q-r4rv-jv94（2026-08-27），Crossplane Runtime 官方安全公告及 Crossplane 官方发布分支信息。版本与缓解结论以官方公告后续更新为准。
