Threat Advisory – ClickHouse CVE-2026-116366: Unauthenticated Remote Code Execution

Executive Summary

On 30 October 2026, ClickHouse disclosed CVE-2026-116366, a critical vulnerability in ClickHouse Server (CVSS v4.0 9.5). Under certain conditions, an unauthenticated attacker with network access to the server can execute arbitrary code. Third-party vulnerability trackers classify it as an integer overflow (CWE-190); ClickHouse has not confirmed this.

ClickHouse Cloud and BYOC deployments have already been patched, and ClickHouse reports no evidence of exploitation in Cloud. For self-hosted deployments, fixes are available in 26.3.62.3-lts, 26.8.36.3-lts, 26.9.27.3-stable and 26.10.3.7-stable, the versions currently supported under ClickHouse’s security policy. ClickHouse does not state whether older, unsupported versions are affected. Organisations running self-hosted ClickHouse should upgrade to one of these releases.

How It Works

ClickHouse has not released technical details, the trigger, the affected interface or exploitation behaviour. Every point below is stated in the vendor advisory or the CVE record.

1. Exposure: The exploitation requires only network access and no authentication. ClickHouse has not said which interface or port is affected. Default listeners are 8123 (HTTP), 9000 (native TCP), 8443 (HTTPS) and 9440 (native TLS).
2. Preconditions: No privileges and no user interaction are required. The vendor says exploitation works only “under certain conditions” and the score sets Attack Complexity to High.
3. Weakness: Third-party vulnerability trackers list CWE-190 (integer overflow); ClickHouse has not confirmed this.
4. Code execution: Successful exploitation executes arbitrary code on the ClickHouse server. The score rates confidentiality, integrity and availability impact as High on the server and on subsequent systems.

Key Affected Packages

Self-managed ClickHouse Server only. ClickHouse Cloud and BYOC are patched, and their customers need not act.

Key Affected Package	Vulnerable Versions	Safe Version
clickhouse-server 26.3 (LTS)	26.3.x before 26.3.62.3	26.3.62.3-lts
clickhouse-server 26.8 (LTS)	26.8.x before 26.8.36.3	26.8.36.3-lts
clickhouse-server 26.9	26.9.x before 26.9.27.3	26.9.27.3-stable
clickhouse-server 26.10	26.10.x before 26.10.3.7	26.10.3.7-stable

ClickHouse often ships inside other software, so it may not appear in your database inventory. For example:

• Langfuse (self-hosted LLM tracing): stores traces in ClickHouse. On 30 October Langfuse moved its Docker Compose file from ClickHouse 25.12 to the fixed 26.3.62.3-lts (PR langfuse/langfuse#19494). Installations made from an older copy still run 25.12, a line with no fix.
• PostHog (self-hosted product analytics): stores events in ClickHouse. Its compose file uses a custom build, clickhouse-posthog:26.9.5.2, numbered below the fixed 26.9.27.3. PostHog has not said whether its build includes the fix.
• Opik (self-hosted LLM evaluation by Comet): stores traces in ClickHouse. Its compose file pins clickhouse-server:26.3.16.16, which is below the fixed 26.3.62.3, so default installs are vulnerable.
• Sentry (self-hosted error tracking): stores events in ClickHouse through its Snuba service. Its compose file builds on altinity/clickhouse-server:25.8.33, a line with no fix whose status ClickHouse has not stated.

ClickHouse has not said whether the 25.12 and 24.12 lines are affected, and it publishes no fix for them. Other observability and analytics tools bundle ClickHouse the same way, so search the compose files and Helm charts on your servers for clickhouse. Query 8.3 below finds bundled instances in Kubernetes audit logs.

Remediation

If you suspect your environment or packages have been affected, follow these steps:

• Inventory every instance: Search servers, compose files, Helm charts and Kubernetes manifests for clickhouse: kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | grep -i clickhouse | sort -u. Include instances bundled in self-hosted products.
• Check versions: Run clickhouse-client --query "SELECT version()" on each server, or read the container image tag.
• Upgrade: Install the fixed build for your line from packages.clickhouse.com or the official Docker image, e.g. clickhouse/clickhouse-server:26.3.62.3-lts. Pin exact tags rather than floating tags such as latest or 26.3.
• Remove internet exposure: Block port 8123, 9000, 8443 and 9440 from the internet at the security group or firewall. Bind to 127.0.0.1 or private interfaces via listen_host. Verify from an external network with nc -vz <ip> <port>.
• Hunt for compromise on exposed hosts: ClickHouse has published no exploitation artefacts, so use generic host review: child processes of clickhouse-server (ps -eo pid,ppid,user,cmd --forest | grep -A3 clickhouse), recently changed files, and outbound connections from the server.
• Review suppressed scanner findings: Suppressing an Inspector, Wiz or SCC finding for ports 8123, 9000, 8443 or 9440 does not close the port. Re-check those findings on every ClickHouse host.
• Rotate integration secrets if compromise is suspected: S3 and cloud keys, Kafka and database credentials in table engines, and ClickHouse user passwords.

Finding ClickHouse in Your Coralogix Data

Logs are not the right way to check for this vulnerability. If you have a vulnerability management tool, check there first. If you don’t, use the queries below to see whether you run ClickHouse, or use the Olly agent to check your environment below.

Olly Prompt

Check whether ClickHouse Server is used in this environment and, if it is, whether it
runs a fixed version for CVE-2026-116366 (unauthenticated remote code execution). Use
only the data in this account; don't look anything up.

Fixed versions: 26.3.62.3, 26.8.36.3, 26.9.27.3, 26.10.3.7 or later on the same line.
Lower on those lines is vulnerable. Any other line (for example 23.x-25.x) has no fix.
ClickHouse Cloud is already patched.
Where to look (last 30 days): host names, DNS, container images, Kubernetes pods, cloud
or scanner assets, ClickHouse's own logs, and apps that bundle it (Langfuse, SigNoz,
PostHog, Sentry).
Only count servers, not client libraries or docs. If no version is shown, say "version
not in logs". Reply with a table: server, location, version, fixed / vulnerable / no fix,
internet-facing (yes/no), and the query you used.

Result

DataPrime Queries

8.1 ClickHouse hostnames and DNS records

source logs | wildfind 'clickhouse'
| create raw from $d:string
| extract raw into h using regexp(
    e=/(?i)(?<host>([a-z0-9-]+\.)*[a-z0-9-]*clickhouse[a-z0-9-]*(\.[a-z0-9-]+)+)/)
| filter h.host != null
| groupby $l.applicationname as app, $l.subsystemname as subsystem, h.host:string as hostname
    aggregate count() as hits
| orderby hits desc | limit 50

Finds: internal service names (for example clickhouse.<env>.internal) and public DNS records containing clickhouse. Check first any public record that points at a self-managed server. Ignore vendor domains such as clickhouse.com and clickhouse.cloud. Needs: Route 53 or resolver query logs, proxy, WAF or any log carrying hostnames.

8.2 ClickHouse Server and Application Logs: Self-Reported Build

source logs | wildfind 'official build'
| create raw from $d:string
| extract raw into v using regexp(
    e=/version (?<version>2[0-9]\.[0-9]{1,2}\.[0-9]+\.[0-9]+) \(official build\)/)
| filter v.version != null
| groupby $l.applicationname as app, $l.subsystemname as subsystem, v.version:string as version
    aggregate count() as hits, min($m.timestamp) as first_seen, max($m.timestamp) as last_seen
| orderby hits desc | limit 20

Finds: the exact build ClickHouse prints as “version X (official build)” in errors and stack traces. Its server log lines often do not contain the word clickhouse, so a keyword search alone can miss them. Needs: ClickHouse server or container logs (CloudWatch, Kubernetes, OpenTelemetry).

8.3 Kubernetes Audit and Container Logs: Image Tags

source logs | wildfind 'clickhouse'
| create raw from $d:string
| extract raw into ch using regexp(
    e=/(?i)(?<image>[a-z0-9._\/-]*clickhouse[a-z0-9._\/-]*):(?<tag>[0-9]{2}\.[0-9]+[a-z0-9.\-]*)/)
| filter ch.tag != null
| groupby $l.applicationname as app, ch.image:string as image, ch.tag:string as tag
    aggregate count() as hits
| orderby hits desc | limit 50

Finds: ClickHouse images and tags, including copies bundled with Langfuse or Plausible. A tag such as 25.12 or 26.7 is not a fixed build. Needs: Kubernetes or GKE/EKS audit logs, or any log carrying image:tag text.

8.4 CSPM Logs (for example Wiz): Assets, Binaries and Exposure

source logs | filter $d.vulnerableAsset.name:string.matches(/(?i).*clickhou.*/)
    || $d.locationPath:string.matches(/(?i).*clickhouse.*/)
    || $d.detailedName:string.matches(/(?i).*clickhouse.*/)
| create path_ver from $d.locationPath:string
| extract path_ver into p using regexp(e=/clickhouse-common-static-(?<build>[0-9.]+)/)
| groupby $l.applicationname as app, $d.vulnerableAsset.name:string as asset,
    p.build:string as clickhouse_build,
    $d.vulnerableAsset.hasWideInternetExposure:string as wide_internet_exposure
    aggregate count() as findings
| orderby findings desc | limit 50

Finds: cloud assets named after ClickHouse, ClickHouse binaries found by the scanner (the build is read from the clickhouse-common-static path) and the scanner’s internet-exposure flag. Needs: Wiz vulnerability findings or a CSPM feed with the same fields.

8.5 AWS Inspector: Instance Names and Reachability

// Instances whose name contains ClickHouse, with their Inspector findings
source logs | wildfind 'clickhouse'
| create raw from $d:string
| extract raw into t using regexp(e=/"(vmName|instanceName|Name)":"(?<name>[^"]*[Cc]lick[^"]*)"/)
| filter t.name != null
| groupby $l.applicationname as app, t.name:string as instance_name, $d.resource_id:string as instance,
    $d.detail.type:string as finding_type, $d.detail.status:string as status aggregate count() as hits
| orderby hits desc | limit 50

// ClickHouse ports reachable from an Internet Gateway
source logs | filter $d.detail.type:string == 'NETWORK_REACHABILITY'
| filter $d.detail.title:string ~ '8123' || $d.detail.title:string ~ '9000'
    || $d.detail.title:string ~ '8443' || $d.detail.title:string ~ '9440'
| create raw from $d:string
| extract raw into t using regexp(e=/"vmName":"(?<vm>[^"]*)"/)
| groupby $d.resource_id:string as instance, t.vm:string as name,
    $d.detail.title:string as finding, $d.detail.status:string as status aggregate count() as hits
| orderby hits desc | limit 30

Finds: EC2 instances whose name contains ClickHouse, and Inspector findings that a ClickHouse port is reachable from the internet. Include SUPPRESSED findings: suppression does not close the port. Needs: AWS Inspector findings.

8.6 AWS CloudTrail: ClickHouse Servers and ClickHouse-Named Resources

// ClickHouse servers (Cloud or self-managed) assuming your IAM roles, with their build
source logs | filter $d.userAgent:string ~ 'ClickHouse'
| groupby $l.applicationname as app, $d.userAgent:string as ua, $d.eventName:string as event,
    $d.userIdentity.accountId:string as caller_acct, $d.requestParameters.roleArn:string as role,
    $d.sourceIPAddress:string as src_ip aggregate count() as hits
| orderby hits desc | limit 30

// Roles, instance profiles, buckets and secrets with ClickHouse in the name
source logs | wildfind 'clickhouse'
| create raw from $d:string
| extract raw into ch using regexp(e=/(?i)(?<name>[a-z0-9._:\/-]{0,40}clickhouse[a-z0-9._\/-]{0,50})/)
| groupby $d.eventSource:string as service, $d.eventName:string as event, ch.name:string as resource
    aggregate count() as hits
| orderby hits desc | limit 40

Finds: ClickHouse servers that send “ClickHouse <build> (official build)” as the user agent when they assume your roles, and IAM roles, instance profiles, S3 buckets and secrets named after ClickHouse, which point at the hosts that run it. Needs: AWS CloudTrail.

8.7 Network Logs (ALB, VPC Flow): Traffic to ClickHouse Ports

// AWS ALB logs: clients reaching ClickHouse target ports through a load balancer
source logs | filter $d.target_port:string == '8123' || $d.target_port:string == '9000'
    || $d.target_port:string == '8443' || $d.target_port:string == '9440'
| groupby $l.applicationname as app, $d.target_port:string as target_port, $d.client_ip:string as client,
    $d.elb:string as lb, $d.user_agent:string as ua aggregate count() as hits
| orderby hits desc | limit 30

// AWS VPC flow logs: public sources reaching ClickHouse ports, with accept/reject
source logs | filter $d.dstport:string == '8123' || $d.dstport:string == '9000'
    || $d.dstport:string == '8443' || $d.dstport:string == '9440'
| create src_ip from $d.srcaddr:string
| filter !ipInSubnet(src_ip, '10.0.0.0/8') && !ipInSubnet(src_ip, '172.16.0.0/12')
    && !ipInSubnet(src_ip, '192.168.0.0/16')
| groupby $l.applicationname as app, $d.dstaddr:string as dst_ip, $d.dstport:string as dst_port,
    $d.action:string as action aggregate count() as hits, distinct_count(src_ip) as distinct_sources
| orderby hits desc | limit 50

Finds: who reaches ClickHouse ports through a load balancer, and public sources reaching ClickHouse ports with the accept or reject action. Port 9000 and 8443 are also used by other services, so confirm the destination is ClickHouse with another query. Needs: ALB access logs or VPC flow logs.

8.8 EDR and Endpoint Logs: Shells or Downloaders in ClickHouse Context

source logs | wildfind 'clickhouse'
| create raw from $d:string
| filter raw ~ '/bin/sh' || raw ~ '/bin/bash' || raw ~ '/bin/dash' || raw ~ 'curl '
    || raw ~ 'wget ' || raw ~ 'python' || raw ~ 'perl ' || raw ~ 'socat' || raw ~ 'ncat'
| groupby $l.applicationname as app, $l.subsystemname as subsystem aggregate count() as hits
| orderby hits desc | limit 50

Finds: records that mention ClickHouse together with a shell or downloader. This is a generic hunt, not a CVE-specific detection; expect noise from SQL comments and admin troubleshooting and read sample rows before escalating. Needs: EDR, auditd, Sysmon for Linux or Kubernetes audit logs.

Snowbit Response

• Customer environment scanning: Snowbit is scanning customer environments for ClickHouse deployments. Affected customers will be contacted individually.

Sources

• ClickHouse Trust Center advisory
• ClickHouse security changelog

Closing recommendations

Supported release lines (26.3, 26.8, 26.9, 26.10): We strongly recommend all customers audit every self-managed and bundled ClickHouse deployment for internet exposure and upgrade now to a fixed build: 26.3.62.3-lts, 26.8.36.3-lts, 26.9.27.3-stable or 26.10.3.7-stable. ClickHouse states the pull request containing the fix will be made public after 13 November 2026. Once the fix’s source code is public, developing an exploit against unpatched servers becomes significantly easier.

Unsupported release lines (25.x, 24.x and earlier): ClickHouse states the fix has been backported to all supported versions listed in its security.md. It has made no statement on whether older lines are affected and has published no fix for them. We recommend treating these deployments as exposed and migrating to a supported line at one of the fixed builds above, rather than waiting for a vendor statement.