CVE-2026-116366: ClickHouse Unauthenticated RCE and Patch Verification

CVE-2026-116366 is a critical ClickHouse Server vulnerability that can allow an unauthenticated user with network access to execute arbitrary code under certain conditions. En ClickHouse-authored CVE record assigns a CVSS 4.0 score of 9.5. The public record does not disclose a packet format, protocol field, parser path, or reliable exploitation indicator, so defensive work should focus on exact version state, reachable services, rapid patching, and evidence preservation rather than speculative payload testing. See ClickHouse security changelog.

The phrase “under certain conditions” matters. It means the vendor has confirmed more than a simple version match is involved, but it has not published enough detail to identify those conditions safely from configuration alone. Do not convert the absence of public exploit details into a low-priority decision. An unauthenticated network-to-code-execution boundary on a data platform warrants urgent treatment when the service is reachable by untrusted or broadly trusted networks. See ClickHouse security changelog.

What is confirmed

• The affected product is ClickHouse Server, with separate affected build data for ClickHouse Cloud.
• An unauthenticated user must have network access to the ClickHouse service.
• Successful exploitation can execute arbitrary code on the ClickHouse Server.
• The CVE identifies integer overflow or wraparound as CWE-190 and command injection as the associated impact pattern.
• The CVSS 4.0 vector is AV:N/AC:H/AT:N/PR:N/UI:N with high impact to confidentiality, integrity, and availability.

Attack complexity is rated high, but the vector still requires no privileges and no user interaction. High complexity describes exploit conditions; it is not evidence that an exposed server can safely remain unpatched.

Self-managed ClickHouse fixed versions

Version reference: ClickHouse security changelog.

The CVE record lists these supported branch thresholds. If a server uses an older, custom, vendor-embedded, or unfamiliar build, do not infer that it is safe because it does not match a table row. Obtain current ClickHouse guidance or move to a supported corrected release. Package revisions and appliance builds may not compare cleanly with upstream strings. See ClickHouse security changelog.

ClickHouse Cloud build thresholds

The following historical build thresholds come from the ClickHouse-authored CVE record.

Version reference: ClickHouse security changelog.

ClickHouse states in its October 30 security changelog that a fix has been applied to all ClickHouse Cloud and BYOC deployments. ClickHouse Cloud customers should use the vendor console, service communication, and support evidence to confirm remediation. An application-visible version can be useful context, but Cloud build interpretation belongs to the provider. Retain the service identifier, region, observed version, vendor notice, and confirmation time.

Inventory network reachability before testing anything

Start from the deployment inventory and approved network-control data. Identify native TCP, HTTP, HTTPS, interserver, proxy, load-balancer, Kubernetes service, and private-link exposure. The exact ports and interfaces depend on the deployment; do not scan networks outside the authorized scope.

# On a Linux host you administer
clickhouse-client --query "SELECT version()"

# Package observations; use the command appropriate to the host
dpkg-query -W 'clickhouse*'
rpm -qa | rg '^clickhouse'

# Review listening sockets locally
ss -ltnp | rg -i 'clickhouse'

A successful authenticated version query proves which server answered that request. It does not discover every cluster node, keeper node, standby image, old container, or separately exposed service. Correlate it with orchestration manifests, package inventory, cloud assets, load balancers, DNS, service discovery, and deployment pipelines.

Explore Penligent for authorized security testing and evidence review.

Exposure decision matrix

Version reference: ClickHouse security changelog.

Temporary risk reduction

Where an update cannot start immediately, remove public exposure, restrict source networks to the smallest justified set, require access through controlled application or proxy tiers, and block unused protocols and interfaces. Review anonymous and default accounts, but do not record authentication hardening as a complete mitigation because the CVE explicitly describes an unauthenticated path.

Protect backup repositories and credentials available to the ClickHouse service account. Data platforms often hold broad read access, object-storage keys, cluster secrets, dictionaries, user-defined functions, integration credentials, and export paths. These controls reduce blast radius; they do not repair vulnerable server code.

Patch and verify safely

1. Capture cluster topology, replicas, shards, keepers, proxies, images, packages, and the exact running version.
2. Select a current supported fixed release for each branch.
3. Back up configuration and validate recovery procedures.
4. Use the vendor-supported rolling or maintenance procedure.
5. Confirm every node and container was replaced or restarted onto the corrected build.
6. Run normal read, write, replication, backup, restore, and application compatibility checks.
7. Retain version output, package or image digest, change record, and cluster health evidence.

Do not send malformed unauthenticated requests to production to prove the fix. The vendor version boundary and runtime deployment evidence are safer and more reproducible acceptance criteria while technical exploit details remain restricted.

Detection and incident response

There is no authoritative universal exploit signature in the public record. Review unexpected unauthenticated connections, service crashes or restarts, unusual child processes, new files owned by the ClickHouse account, unexpected outbound connections, unauthorized configuration changes, suspicious queries, and access to credentials or external storage. Each signal needs environmental context. See ClickHouse security changelog.

If a vulnerable server was exposed to untrusted networks, preserve server logs, query logs, system logs, process telemetry, container or host snapshots, network records, deployment history, and identity-provider events. A clean version check after maintenance proves current code state, not that the earlier exposure window was free of compromise.

Conclusión

CVE-2026-116366 crosses an unauthenticated network boundary into code execution on a high-value data platform. Public technical details are intentionally limited, which makes disciplined version and exposure management more important, not less. Inventory every node, apply a supported fixed build, restrict unnecessary network paths, verify the runtime cluster, and preserve evidence for any period in which an affected server was reachable.