HashiCorp consul-k8s 被披露一个严重漏洞，CVE-2026-110720，CVSS 9.9，问题在 ACL 绑定规则的跨命名空间授权绕过，已有公开利用。
影响范围
0.42.0 及之后版本受影响，修复版本是 2.1.0 和 1.8.18。漏洞允许攻击者突破命名空间边界，拿到更高权限的 Consul 特权。在多租户 Kubernetes 集群里，这会破坏服务网格的隔离假设，让攻击者能从一个工作负载横向移动到别的命名空间的工作负载。
为什么 9.9 分是合理的
服务网格的整个信任模型建立在「命名空间是隔离边界」上。一旦这个边界可以绕过，网格内的 mTLS 身份、服务间授权策略、流量策略全部失效。而且拿到 Consul 的高权限通常意味着能改配置、能读到所有服务的证书，等于拿到了集群内的通用通行证。有公开利用这一点让它从「高危」升级为「现在就得处理」。
处置顺序
第一，先评估暴露面。检查 consul-k8s 的版本，确认 Consul server 的 API 有没有从集群外可达。如果 server 只在集群内可达，风险等级降一档但仍然是高的。
第二，升级到 2.1.0 或 1.8.18。注意两个分支的版本号差异较大，确认你的部署方式用的是哪个分支的 chart。
第三，审计 ACL token 与 binding rules。重点看有没有命名空间级的 token 被授予了跨命名空间的服务写权限，有没有 service identity 的绑定规则过于宽泛。
第四，轮换可能受影响的 token 和证书。假设已经泄露来处理，比事后发现被利用要便宜。
加固建议
给 Consul server 加网络策略，只允许必要的来源访问。开启审计日志。给不同租户用不同的 admin partition 而不仅仅是命名空间隔离，partition 是更硬的边界。
一句提醒
这类基础设施组件的漏洞，修补窗口应该以小时计而不是以周计。因为它不是业务代码的问题，是整栋楼的地基。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
