ClickHouse 于 10 月 30 日披露一处严重漏洞，编号 CVE-2026-116366，CVSS 4.0 评分 9.5。具备网络访问能力的未认证攻击者在特定条件下可在 ClickHouse Server 上执行任意代码。ClickHouse Cloud 与 BYOC 部署已由厂商侧完成修复，自建集群、Docker 与 Kubernetes 部署需要自行升级。
事件概述
漏洞由 ClickHouse 官方安全变更日志披露，同日发布修复版本，并回溯到多个仍在维护的分支。修复版本包括：
- 26.10.3.7-stable
- 26.9.27.3-stable
- 26.8.36.3-lts
- 26.3.62.3-lts
- 25.12.1.1713 及同批其他发布
官方对漏洞的表述相当克制：「在特定条件下，可能允许具备网络访问的未认证用户执行任意代码」。公告没有说明这些条件具体是什么，也没有说明涉及哪个端口、漏洞如何从内存破坏走到代码执行。
技术细节
CVE 记录把缺陷归类为 CWE-190，即整数溢出。CVSS v4.0 向量里的攻击复杂度被标为 High——按 FIRST 的定义，AC:H 意味着攻击者需要绕过地址空间随机化之类的防护，或者需要目标特有的秘密信息。
但打分的 CNA 与报告者对严重性的判断存在落差。CVE 记录中署名研究者 Elshad Toklayev 在 10 月 30 日于 X 上称，这是一个「只需要公开主机名就能打」的未认证 RCE。ClickHouse 官方并未重复这一说法。这个落差直接决定防守方的判断：如果真是「有公网域名就行」，那么所有把 8123 或 9000 端口暴露在外的实例都处在风险中；如果条件严格，风险面会小一些。在厂商补充技术细节之前，按前者准备更稳妥。
另一个容易被忽略的点是「未认证」的含义。认证发生在登录环节，而这个漏洞在登录之前就可以触发，因此强密码、按用户下发的访问控制规则都不构成防护。真正构成防护的是可达性——攻击者连不上的服务，就没有可攻击的入口。
影响评估
CISA 已于 10 月 30 日 16:36 UTC 为该记录补充富化信息，评估利用状态为 none、可自动化程度为 no，但技术影响为 total。也就是说，官方情报口径认为暂未被在野利用，一旦被利用则是完全失陷。
截至 10 月 30 日，该漏洞不在 CISA KEV 目录中，Exploit-DB、Metasploit 与 GitHub 上也未检索到公开利用代码。这两项结论都不能排除已被私用，只能说明目前没有公开痕迹。
需要关注的暴露面是四个端口：8123（HTTP）、8443（HTTPS）、9000（原生 TCP）、9440（原生 TLS）。国内大量 ClickHouse 部署用于日志分析和实时数仓，为方便 BI 工具直连，把 8123 直接开在公网的情况并不少见。
修复建议
按以下顺序推进，先修暴露节点，再修内网节点：
- 盘点。执行
SELECT version()记录每台节点的构建号与归属人，包含 Docker 与 K8s 中的实例。 - 测可达性。从自己的网络外部探测 8123、8443、9000、9440 四个端口，确认哪些实例能被公网直接访问。
- 收敛端口。用防火墙、私有网络或 Cloud IP 访问列表关掉不该公开的端口，这一步能在升级前先把风险压下去。
- 升级。把暴露节点先升到所在分支的修复构建，再处理其余节点，升级后逐台确认版本号。
- 观察。重点看崩溃、新增子进程、异常外连流量三类迹象。
如果实例确实需要对外提供查询服务，建议在前面加一层反向代理做认证与限速，不要让 ClickHouse 自己承担公网入口的角色。