Consul 修复五项漏洞，涉及网格私钥、ACL 绕过及 API 拒绝服务

HashiCorp 于 10 月 26 日披露五项 Consul 相关漏洞。它们属于同一发布批次，但并不存在通用的未认证攻击路径。L3： 这些问题涉及主流服务发现与网格授权边界；公告没有确认恶意利用，也未提供受害者数量。

能够访问启用 ACL 的 agent HTTP API 的主体，可通过叶证书 API 漏洞读取已有缓存的服务证书及其私钥。这并不自动暴露所有网格身份：所请求证书必须已经缓存在该 agent。普通 agent 通常缓存其管理的 sidecar 身份，为 Consul Dataplane 提供服务的服务器可能缓存更多。HTTP API 默认绑定回环地址，因此远程暴露取决于部署方式，不可信本地进程仍需考虑。被窃取的身份只能访问相应网格 intentions 允许的服务；这不是根 CA 私钥泄露。

注册漏洞要求已认证主体拥有代理及其目标服务的写权限，但没有 mesh write。受影响版本中，等价拼写的 Envoy 覆盖配置键可以避开较窄的权限检查。HashiCorp 描述了可能发生在该代理内部的代码执行、流量读取或修改，以及该处的 intentions 绕过；不能将其描述成无条件的 Consul 服务端 RCE。独立的健康检查漏洞要求拥有同一节点上另一个服务的写权限，可操纵目标服务的健康及服务发现结果。

内存耗尽漏洞要求能够访问 API，但不需要有效 ACL 令牌。大请求体在授权前就会被处理，单纯启用 ACL 并不足够。修复也会改变兼容性：多数写端点将请求体限制为 512 KiB。

对于 consul-k8s，关键条件是 global.acls.manageSystemACLs=true。能够在其他 Kubernetes 命名空间创建 ServiceAccount、取得其令牌并访问 Consul API 的用户，可能冒充 Consul 组件并获得其关联权限。这不是匿名互联网攻击，也不能据此认定所有 Kubernetes 用户都能成为集群管理员。关闭系统 ACL 管理的部署不受此特定问题影响。

厂商列出的适用修复版本为 Consul CE 2.1.0、Enterprise 2.1.0 或 1.21.19，以及 consul-k8s 2.1.0 或 1.8.18。需特别注意，HCSEC-2026-47 将 Enterprise 1.22.12 列为受影响版本，却未单列 1.22 修复版本；应采用受支持的升级路径，不要猜测版本或盲目降级。由于产品和受影响版本集合不同，这里不提供自动版本检查器。限制或阻断单一端点只是叶证书私钥问题的临时缓解，不能替代整批更新。