On this page
ClickHouse disclosed CVE-2026-116366 on Friday, Oct 30: a bug in ClickHouse Server that lets someone with network access and no credentials run code on the server, "under certain conditions." The ClickHouse CNA rates it CVSS 4.0 9.5, files it as an integer overflow (CWE-190), and ships fixes in 26.3.62.3-lts, 26.8.36.3-lts, 26.9.27.3-stable and 26.10.3.7-stable. ClickHouse says Cloud and BYOC deployments are already patched. If you run ClickHouse yourself, check the version and get onto one of those four builds today.
clickhouse-client --query "SELECT version()"Anything below the fixed build on your train is vulnerable. If you are on 26.7, 26.4 to 26.6, 26.1, 26.2 or any 25.x, there is no patch for your line at all. You have to move to a supported train.
What ClickHouse has said
Very little. The whole public description is one sentence: "An issue has been discovered in ClickHouse Server that, under certain conditions, could allow an unauthenticated user with network access to execute arbitrary code on the ClickHouse Server." The CVE record adds the CWE-190 tag, a CAPEC-248 (command injection) impact label and a credit to reporter Elshad Toklayev. There is no GitHub security advisory yet, no named interface, no list of the "certain conditions," no proof of concept and no write-up from the reporter.
So we cannot tell you whether the bad input arrives over the HTTP interface on 8123, the native protocol on 9000, TLS native on 9440, or something else. Anyone who claims to know the trigger today is guessing. The CVSS vector carries one hint: attack complexity is rated High. In CVSS terms that means success depends on conditions the attacker does not fully control, such as timing or memory layout. That makes it harder to pull off, not safe to ignore, because no login stands in the way.
The bug is not in CISA's Known Exploited Vulnerabilities catalog (checked against the Oct 29 release), and ClickHouse has not said it is being exploited.
How to fix
Upgrade to the fixed build on your train. On Debian or Ubuntu installs from packages.clickhouse.com:
sudo apt-get update
sudo apt-get install --only-upgrade clickhouse-server clickhouse-client clickhouse-common-static
sudo systemctl restart clickhouse-server
clickhouse-client --query "SELECT version()"The stable repository already serves 26.10.3.7 and 26.9.27.3, and the LTS repository serves 26.8.36.3 and 26.3.62.3. On RPM installs, sudo yum update clickhouse-server clickhouse-client does the same job.
On Docker, pin the exact tag:
docker pull clickhouse/clickhouse-server:26.8.36.3
docker pull clickhouse/clickhouse-server:26.3.62.3
docker pull clickhouse/clickhouse-server:26.9.27.3
docker pull clickhouse/clickhouse-server:26.10.3.7One detail from Docker Hub helps here. The floating tags latest, 26.10, 26.9, 26.8 and 26.3 already point at the fixed images, and they have since Oct 25 and 26. The fixes went out days before the CVE was public. If you track one of those tags and pulled and restarted after Oct 26, you may already be fixed. Do not assume it. Run SELECT version() on every node, including replicas and Keeper hosts that also run the server.
If you are on an unsupported train, the target is 26.8.36.3-lts or 26.3.62.3-lts. Read the backward-incompatible changes section of the changelog for every release you skip before a jump that size.
Who is exposed
A self-managed ClickHouse that untrusted machines can reach. That covers more than the analytics cluster your data team runs. A lot of observability and LLM tracing software ships ClickHouse as its storage layer:
- Langfuse v3 self-hosted uses ClickHouse for traces. The current Langfuse
docker-compose.ymlpinsclickhouse/clickhouse-server:25.12, a train ClickHouse no longer supports, so a Langfuse install on the default image gets no backported fix. - SigNoz stores logs, traces and metrics in ClickHouse. Its Docker install docs show
clickhouse/clickhouse-server:25.5.6, also off support.
Neither project has said whether those versions carry this bug. The CVE record only lists the four supported trains, and its default status for everything else is "affected." Until ClickHouse or the projects say otherwise, treat older bundled images as vulnerable and override the image tag to a fixed build. Check that the app still starts and migrates before you roll it out widely.
Who is not in scope
ClickHouse Cloud and BYOC customers. ClickHouse says the fix has been applied to all of those deployments, so there is nothing for you to upgrade.
Network placement also matters. The Langfuse compose file binds 8123 and 9000 to 127.0.0.1 on the host, and SigNoz's Docker install keeps ClickHouse on the internal Docker network without publishing the ports. In those layouts a stranger on the internet cannot reach ClickHouse directly. Any other container on the same network, or anything already running on the host, still can. Network restriction lowers the risk. It does not replace the upgrade.
Check your exposure
See what ClickHouse is listening on:
sudo ss -ltnp | grep -E ':(8123|8443|9000|9440|9009) 'Anything bound to 0.0.0.0 or a public address needs a firewall rule in front of it before the upgrade window. The listen_host setting in /etc/clickhouse-server/config.xml (or a file under config.d/) controls this. Set it to an internal address and restrict the interfaces with security groups or iptables so only your app servers and other cluster nodes can connect. An unauthenticated /ping on 8123 that answers Ok. from outside your network means the server is reachable, and reachability is the condition this bug needs.
A strong password on the default user does not help with this CVE, because the bug works before login. Set one anyway; Langfuse's compose file ships clickhouse as the default password.
What this is not
This is not a confirmed in-the-wild exploit, and there is no public exploit code. It is also not a ClickHouse Cloud problem. Right now it is a vendor-confirmed pre-auth code execution bug with almost no public detail. Patch first and investigate when ClickHouse or the reporter publishes more.
HOL Guard keeps the source record for this CVE in its CVE-2026-116366 evidence pack. This post is the operator write-up.
What do people ask about CVE-2026-116366?
Which ClickHouse versions fix CVE-2026-116366?
26.3.62.3-lts, 26.8.36.3-lts, 26.9.27.3-stable and 26.10.3.7-stable. Earlier builds on those trains are affected. Unsupported trains such as 26.7 and 25.x get no fix.
Is ClickHouse Cloud affected?
ClickHouse says the fix is already applied to all ClickHouse Cloud and BYOC deployments.
How do I check my ClickHouse version?
Run clickhouse-client --query "SELECT version()" on each node, or run SELECT version() from any SQL client connected to the server.
Is CVE-2026-116366 being exploited?
ClickHouse has not reported exploitation, it is not in the CISA KEV catalog as of Oct 30, and no public exploit code has appeared.
Which port is vulnerable?
ClickHouse has not said. Treat every ClickHouse listener (8123, 8443, 9000, 9440 and 9009) as in scope until it does.
I run Langfuse or SigNoz. What should I do?
Both bundle ClickHouse images from trains that no longer get security fixes. Override the ClickHouse image to a fixed build such as 26.8.36.3, confirm the app still starts, and keep ClickHouse off public interfaces.
