回顾过去：纠正未修复的 Kubernetes CVE 记录

借由 Pushkar Joglekar (Broadcom / SIG Security)、 Tabitha Sable (Datadog / K8s Security Response Committee / SIG Security) | 译者 Xin Li (DaoCloud) |

Kubernetes 项目依赖透明性来赋能集群管理员和安全研究人员。 我们做到这一点的一个重要方式是将 CVE 记录发布到常见漏洞和风险数据库。 作为我们持续完善官方 Kubernetes CVE 信息源 努力的一部分，我们发现了一些差异。一些较旧的、未修复问题的 CVE 记录错误地包含了 fixed version 字段。

Kubernetes 安全响应委员会（SRC）将于 2026 年 6 月 1 日纠正受影响的 CVE 记录。 这可能导致漏洞扫描器在以前未检测到的地方识别这些漏洞。

为帮助减少混淆，本文提供了多年前披露但仍未修复的三个漏洞的技术更新： CVE-2020-8561、CVE-2020-8562 和 CVE-2021-25740。

为什么我们现在更新这些记录

虽然这些漏洞已经公开多年，但最近生成官方开源漏洞（OSV）文件的工作表明， 它们相应的 CVE 记录并未准确反映其状态。 具体来说，一些记录表明存在 fixed 版本，而实际上， 这些问题是架构设计上的权衡，无法在不破坏基本 Kubernetes 功能的情况下通过代码完全修复。

纠正这些记录对社区至关重要，原因如下：

  • 自动化保真度：现代漏洞扫描器依赖精确的版本范围。 不准确的 fixed 标签会导致漏报，给用户一种虚假的安全感。
  • 风险文档化：通过将这些正式列为 unfixed， 我们确保平台提供商和管理员意识到持续需要管理缓解措施。

为完整性起见，我们还应该提到 CVE-2020-8554 是一个未修复的 CVE，其正确的 CVE 记录表明它影响所有版本。 该记录也将被更新为使用更标准的版本号格式。

未修复的架构风险技术分析

以下漏洞不会被 Kubernetes 项目修复。 GitHub Issue 仍然是了解这些缺陷技术细节的最佳参考。

CVE-2020-8561：kube-apiserver 中的 Webhook 重定向

  • 严重性：中（4.1）。
  • 问题：kube-apiserver 在与准入 Webhook 通信时遵循 HTTP 重定向。 具有配置 AdmissionWebhookConfiguration 能力的角色可以将 API 服务器请求重定向到内部私有网络。
  • 为什么仍未修复：限制此行为需要破坏许多合法集成所依赖的标准 HTTP 客户端行为。
  • 缓解措施：将 API 服务器日志级别设置为小于 10（以防止记录响应正文） 并禁用动态性能分析（--profiling=false）以防止未经授权的日志级别更改。

CVE-2020-8562：通过 DNS TOCTOU 绕过代理

  • 严重性：低（3.1）。
  • 问题：API 服务器代理中的检查时间到使用时间（TOCTOU）竞态条件允许用户绕过 IP 限制。 系统执行 DNS 检查来验证 IP，但随后执行第二次解析以建立实际连接，攻击者可以操纵这一点。
  • 为什么仍未修复：修复此问题需要固定已解析的 IP，但这会破坏复杂的分域 DNS 或动态 IP 环境。
  • 缓解措施：为 API 服务器使用本地 DNS 缓存服务器（如 dnsmasq）并配置 min-cache-ttl 以在检查和连接之间强制执行一致的响应。

CVE-2021-25740：通过 Endpoints 跨命名空间转发

  • 严重性：低（3.1）。
  • 问题：Endpoints 和 EndpointSlice API 对象中的设计缺陷允许用户手动指定 IP 地址， 可用于将 LoadBalancer 或 Ingress 指向其他命名空间中的后端。
  • 为什么仍未修复：这是许多网络工具和 Operator 使用的 Endpoints API 的基本功能。
  • 缓解措施：限制对 Endpoints（遗留）和 EndpointSlices 的写访问。 自 Kubernetes 1.22 以来，Kubernetes RBAC 授权模式不再将这些权限包含在默认的 edit 和 admin ClusterRole 中。 该移除适用于使用 Kubernetes v1.22 创建的集群； 对于从旧版本升级的集群，管理员应手动审计并协调 system:aggregate-to-edit ClusterRole。

说明：

2026 年 6 月 1 日，这些 CVE 记录将被更新以正确反映所有版本都受影响的事实。 你可能会看到它们开始出现在漏洞扫描器结果中。

管理员需要的操作

Kubernetes 项目建议采用通过配置确保安全方法来管理这些持续风险：

漏洞操作项严重性评分（等级）命令/配置
CVE-2020-8561限制日志详细程度4.1（中）确保 --v 设置为 < 10 且 --profiling=false。
CVE-2020-8562强制 DNS 一致性3.1（低）在控制平面节点上部署 dnsmasq 或类似的缓存解析器。
CVE-2021-25740加固 RBAC3.1（低）使用 kubectl auth reconcile 从广泛角色中移除 Endpoints 写访问权限。

CVE-2021-25740 的 RBAC 操作适用于你的集群使用 RBAC 授权模式的场景， 这是使用标准 Kubernetes 工具创建的集群的默认设置。 管理员应在非生产环境中独立测试和验证这些配置，根据其特定的威胁模型和风险承受能力评估架构风险。

结语：通过透明性走向成熟

协调这些记录的努力是安全生态系统走向成熟的标志。 通过摆脱“仅打补丁”的心态并准确记录架构债务， Kubernetes 项目为社区提供了保护现代云原生基础设施所需的高保真数据。

我们要感谢发现这些风险的安全研究人员——QiQi Xu、Javier Provecho 等人， 以及继续完善我们官方源的 SIG Security Tooling 贡献者。 特别感谢 Rory McCune 通过他的博客文章分享了有关这些 CVE 的信息。

最后修改 May 31, 2026 at 7:27 PM PST: [zh-cn]Add blog: reconciling-unfixed-kubernetes-cves (5f56dca6ec)