ClickHouse CVE-2026-116366: patch pre-auth RCE without losing cluster control

ClickHouse disclosed CVE-2026-116366 on October 30, 2026, describing a Critical vulnerability that can let an unauthenticated network user execute arbitrary code on ClickHouse Server under certain conditions. ClickHouse published fixed open-source builds for the supported 26.3 LTS, 26.8 LTS, 26.9 stable and 26.10 stable lines, and says the fix is already applied to all ClickHouse Cloud and BYOC deployments.

The public advisory is deliberately sparse. It does not identify the exact parser, protocol message or listener that reaches the vulnerable path, and the primary sources reviewed for this article do not claim active exploitation. That uncertainty changes the response: do not invent a port-specific workaround or test public exploit strings. Restrict every reachable ClickHouse listener, upgrade each server process to a fixed build, prove the old processes have gone, and review host and query evidence separately from the patch rollout.

This article separates documented vendor facts from engineering guidance. The vulnerability description, fixed versions, supported branches and Cloud/BYOC status are documented by ClickHouse. The cluster rollout, verification queries, containment controls and evidence model below are operational recommendations, verified against the public sources on October 31, 2026.

Answer first

If you operate ClickHouse Server, move immediately to one of these fixed builds:

Do not keep an unsupported 25.x or unsupported 26.x branch as an emergency rollback target. ClickHouse's security policy currently marks 26.10, 26.9, 26.8 and 26.3 as supported; it marks 26.7, 26.6, 26.5, 26.4, 26.2, 26.1 and older major lines unsupported.

Until the fixed build is serving everywhere, restrict network reachability to the smallest trusted client and inter-node set. Because ClickHouse has not disclosed the specific listener or triggering message, treat HTTP, HTTPS, native TCP, secure native TCP and inter-server paths as in scope when they are reachable in your deployment. This is a conservative engineering boundary, not a vendor statement that every protocol is vulnerable.

inventory -> restrict listeners -> verified fixed artifacts
          -> replica-by-replica canary -> replace old processes
          -> cluster-wide version proof -> functional checks
          -> evidence review -> close or escalate incident

What ClickHouse actually says

The ClickHouse security changelog says CVE-2026-116366 can, under certain conditions, allow an unauthenticated user with network access to execute arbitrary code on ClickHouse Server. It names the four fixed open-source builds above and states that all ClickHouse Cloud and BYOC deployments have received the fix.

The official package repository labels the issue Critical and publishes DEB, RPM and TGZ artifacts for the fixed release lines. It also provides SHA-512 checksum files beside TGZ downloads. The public CVE record, assigned by ClickHouse, gives a CVSS v4.0 base score of 9.5 and classifies the weakness as CWE-190, integer overflow or wraparound.

Those facts establish urgency, but they do not establish that your host was compromised. The public vendor sources reviewed here do not document a proof of concept or in-the-wild exploitation. Keep these states distinct:

1. vulnerable build existed;
2. untrusted network path could reach it;
3. suspicious request or crash was observed;
4. the vulnerable code path was reached;
5. unauthorized execution or persistence was confirmed.

Only evidence should move an incident between those states.

Build an inventory that reflects the running cluster

Start with the process that is actually serving, not an image tag or deployment manifest.

SELECT hostName() AS host, version() AS version;

SELECT
    hostName() AS host,
    version() AS version
FROM clusterAllReplicas('default', system.one)
ORDER BY host;

The second query is an example. Replace default with the cluster definition that matches your environment, and do not assume one successful coordinator query reaches every shard, replica, Keeper node, standby host or disaster-recovery environment.

For each instance, record:

• hostname, cloud instance or Kubernetes pod identity;
• ClickHouse version returned by the live process;
• package build or container image digest;
• process start time and parent service unit;
• shard, replica and availability-zone role;
• exposed listeners, load balancers, firewall rules and service meshes;
• inter-server credentials and certificate policy;
• package repository, artifact checksum and signature evidence;
• configuration revision, user-policy revision and deployment owner.

Compare three sources: desired state, package or image state, and the live server response. A new image in the registry does not prove a pod restarted. A package database update does not prove the old PID exited. A single SELECT version() does not prove every replica changed.

Contain uncertainty without breaking the cluster

The advisory withholds trigger details, so containment should reduce reachability without depending on a guessed payload.

1. Remove direct internet exposure from ClickHouse listeners.
2. Allow only named application, administration and inter-node identities.
3. Require TLS on externally traversed paths and verify client identities where supported.
4. Deny unused listener ports at the network policy, security group and host firewall layers.
5. Restrict administrative users and rotate exposed credentials when compromise evidence exists.
6. Preserve logs and host telemetry before replacing nodes if incident review is required.

Do not disable the native protocol or inter-server traffic blindly on a live cluster; that can stop replication, distributed queries or recovery. Apply a reviewed allowlist that preserves required peers. Network isolation buys time, but it is not a complete fix for a pre-auth server flaw. The upgrade remains mandatory.

Choose a supported target, not merely a higher number

Map the current line to the nearest supported fixed build. For 26.3 and 26.8 LTS, remain on the corresponding LTS line unless a planned migration has already been tested. For 26.9 or 26.10 stable, use the fixed stable build or a later supported build containing the fix.

If the fleet is on an unsupported branch, move to a supported LTS or stable line through a tested path. Do not infer that 26.7 is safe because its number is higher than 26.3. Security support follows the vendor's release policy, not numeric ordering alone.

Before deployment:

• download from the official repository or your controlled mirror;
• verify repository metadata and package signatures;
• for TGZ artifacts, verify the adjacent SHA-512 file;
• pin the exact package build or container digest;
• capture config, metadata backups and rollback evidence;
• verify that the rollback target is also fixed;
• rehearse restore and failover for the topology you actually run.

Roll out replica by replica

A ClickHouse upgrade is a distributed-systems change. Keep enough healthy replicas for reads, inserts, merges and replication while a node is replaced.

Before each node:

SELECT database, table, is_leader, queue_size, absolute_delay
FROM system.replicas
ORDER BY absolute_delay DESC, queue_size DESC;

SELECT database, table, mutation_id, command, is_done, latest_fail_reason
FROM system.mutations
WHERE NOT is_done;

Use these queries as starting points, not universal health criteria. Account for expected long-running mutations, asynchronous replication and topology-specific maintenance operations.

Recommended sequence:

1. pause or bound high-risk maintenance jobs that can obscure signals;
2. drain application traffic from one replica where the topology allows it;
3. preserve required diagnostics and configuration evidence;
4. install or start the fixed immutable artifact;
5. prove the new process version and start time;
6. verify replica queue, delay, merges, mutations and error logs;
7. run representative reads, inserts and distributed queries;
8. return the replica to service;
9. observe a defined stability window before moving to the next node;
10. repeat across every shard, replica, standby and recovery environment.

Keeper is a separate component and should not be treated as patched merely because ClickHouse Server changed. Inventory and maintain it according to its own version and support policy, but do not claim CVE-2026-116366 affects Keeper unless ClickHouse publishes that fact.

Verify the fix at three layers

### 1. Artifact proof

Record the exact package release or container digest, repository origin and checksum or signature result. Mutable tags such as latest or stable are not audit evidence.

### 2. Process proof

Query version() from each live server and record the service start time. Confirm that no process or pod running a pre-fix build still accepts traffic. Check maintenance hosts, autoscaling templates and disaster-recovery images as well as the active cluster.

### 3. Behavior proof

Run safe, ordinary application workflows through every supported interface:

• authenticated read and insert paths;
• distributed queries across shards;
• replication catch-up and failover;
• schema changes used by deployment pipelines;
• backup and restore smoke tests;
• monitoring, logs, materialized views and dictionaries;
• client-driver connection, TLS and timeout behavior.

Do not validate by sending a public or guessed exploit to production. The absence of a crash proves little, while a malformed request could damage a shared service.

Review evidence without calling every anomaly a breach

Because public trigger details are limited, start with broad host and service evidence:

• unexpected ClickHouse crashes, core dumps or restarts before patching;
• child processes or executable mappings not explained by the deployment;
• outbound network connections from the server to unusual destinations;
• modified binaries, libraries, configuration files or service units;
• new users, SSH keys, cron jobs, systemd units or container changes;
• requests from untrusted networks reaching ClickHouse listeners;
• authentication failures followed by server faults or unexplained recovery;
• query-log gaps that do not match load or retention behavior;
• cloud audit events showing security-group, image or identity changes;
• persistence or credential use after the host was rebuilt.

ClickHouse logs alone may not capture a pre-auth memory-corruption path. Correlate load-balancer, firewall, endpoint, kernel, container-runtime and cloud-control-plane evidence. A scan or crash is an investigation lead; unauthorized execution, persistence or data access requires stronger evidence.

If evidence suggests code execution, isolate the node, preserve forensic material according to policy, rotate credentials reachable from that host, rebuild from a trusted fixed artifact, review neighboring systems and escalate through the incident-response process. Do not declare the incident resolved solely because the version changed.

Best practices

• Keep ClickHouse off public networks and authorize clients explicitly.
• Track live versions per shard and replica, not only deployment manifests.
• Follow supported LTS or stable lines and subscribe to security notifications.
• Pin immutable images or exact package builds.
• Verify repository metadata and SHA-512 checksums for direct archives.
• Maintain at least one tested fixed rollback artifact.
• Upgrade one failure domain at a time and watch replication state.
• Retain host, network and control-plane telemetry long enough for investigation.
• Separate patch completion from compromise assessment.
• Recheck the vendor advisory as technical details evolve.

Anti-patterns and limits

• Guessing that only port 9000 or only HTTP is affected.
• Exposing a fixed node while vulnerable replicas remain reachable.
• Rolling back to an unsupported or vulnerable image after an application regression.
• Treating ClickHouse Cloud's patched status as proof that a self-managed cluster is safe.
• Assuming a version label in CI matches the running server.
• Running exploit code against a production database.
• Calling a suspicious request a confirmed compromise.
• Calling a clean log search proof that exploitation did not occur.
• Mixing an urgent security update with an untested major architecture migration.

The public disclosure does not reveal enough detail to construct a path-specific detection signature. Network containment, a supported fixed build, live process proof and evidence preservation are therefore more reliable than speculative filtering.

Executive checklist

1. Inventory every ClickHouse Server process and network listener.
2. Map each node to a supported fixed release line.
3. Restrict reachability to required clients and peers.
4. Verify official packages, checksums and immutable image digests.
5. Preserve evidence needed for incident review.
6. Upgrade one replica or failure domain at a time.
7. Prove version and process replacement on every node.
8. Verify replication, queries, inserts, backups and client connectivity.
9. Review host, network and control-plane evidence for unauthorized effects.
10. Keep only a fixed rollback target and monitor vendor updates.

Related reading: Apache Traffic Server security rollout, Docker Desktop credential-response guide, GitLab critical patch guide, the Cloud, DevOps and Kubernetes hub, and backend and API engineering services.

Primary references

• ClickHouse — Security changelog
• ClickHouse — Official packages and fixed builds
• ClickHouse — Security vulnerability response and supported versions
• CVE Program — CVE-2026-116366
• Wikimedia Commons — SPNN file server rack
• Creative Commons — Attribution 4.0 International

Prepared by: Noor Yasser

Prepared by: Noor Yasser