ClickHouse CVEs: Find Vulnerable Servers with Atlas
On October 30, 2026, ClickHouse published CVE-2026-116366, an unauthenticated remote code execution vulnerability in ClickHouse Server. Under certain conditions, a user with network access to the server can run arbitrary code on it without logging in. ClickHouse rates it Critical, with a CVSS v4.0 score of 9.5.
ClickHouse Cloud and BYOC deployments are already patched. Self-managed servers are not, and finding every
one of them across your environments is the hard part. Atlas can do that for you: atlas security scan now
checks the server version of each ClickHouse server against the Atlas Security Graph, and reports every
published CVE that affects it, this one included, along with the release that fixes it.
What We Know
The public record is short on purpose. ClickHouse has not described the conditions under which the attack works, and the record classifies the weakness as an integer overflow (CWE-190). The pull request with the fix is scheduled to become public after November 13, 2026. Once it is public, anyone can read the diff and work out how to trigger the bug, so plan to finish the upgrade before that date.
ClickHouse reports no evidence of exploitation in ClickHouse Cloud. The same releases also fix CVE-2026-111497, a flaw in the bundled Brotli decoder that lets a crafted compressed request crash the server, as listed on the ClickHouse Trust Center.
Fixed Versions
ClickHouse does not publish a workaround. The fix is to upgrade to a patched release:
| Release line | Fixed in |
|---|---|
| 26.3 LTS | 26.3.62.3-lts |
| 26.8 LTS | 26.8.36.3-lts |
| 26.9 | 26.9.27.3-stable |
| 26.10 | 26.10.3.7-stable |
A server on one of these lines below its fixed version is vulnerable. Older lines receive no patch, so a server running one of them has to move to a supported line. Patched builds are available from the official ClickHouse packages and Docker images.
To check a single server, ask it:
SELECT version();
That works for one server. It does not tell you which of the clusters across your staging, production, and regional environments still need the upgrade, and it will not tell you about the next CVE either.
Scanning ClickHouse with Atlas
atlas security scan connects to running databases and resolves what it finds
against the Atlas Security Graph. On ClickHouse, it matches the server
version against the CVEs published for the engine, so a server is reported with each CVE that affects it,
its severity, and the version to upgrade to, until it runs a release that carries the fix:
atlas security scan --url "clickhouse://root:pass@127.0.0.1:19000/"
Scanning 1 database for security issues:
-- clickhouse://root:xxxxx@127.0.0.1:19000/ (clickhouse 23.10.4.25):
-- Engine "clickhouse" version "23.10.4.25" is vulnerable to CVE-2023-48704 (HIGH):
Unauthenticated heap buffer overflow in Gorrila codec decompression. Upgrade database
engine "clickhouse" to version 23.10.5.20 or later to resolve CVE-2023-48704
-- Engine "clickhouse" version "23.10.4.25" is vulnerable to CVE-2024-22412 (ELEVATED):
ClickHouse's Role-based Access Control is bypassed when query caching is enabled. Upgrade
database engine "clickhouse" to version 23.12.6.19 or later to resolve CVE-2024-22412
-- Engine "clickhouse" version "23.10.4.25" is vulnerable to CVE-2026-116366 (CRITICAL):
Unauthenticated RCE vulnerability against ClickHouse Server. Upgrade database engine
"clickhouse" to version 26.3.62.3 or later to resolve CVE-2026-116366
-------------------------
-- 1.02642825s
-- 3 issues found: 1 critical, 1 high, 1 elevated
This server runs 23.10, a line with no patch for CVE-2026-116366, so the suggested upgrade is the oldest
fixed release, 26.3.62.3. The same report lists two older CVEs the server never picked up a fix for, so one
upgrade resolves all three. Once it is done, the server's line in the report reads
no issues found in the server version.
Credentials are redacted from the report, so it is safe to keep in CI logs. The scan reads the live server, so it needs neither a dev database nor a migration directory. Run it with a read-only database user. To match CVEs, Atlas sends the Security Graph the engine and its version.
To make findings fail the command, set the lowest severity that should break it:
atlas security scan --url "clickhouse://root:pass@127.0.0.1:19000/" --fail-on HIGH
Gate at the lowest severity you want to hear about. The scan grades on the level the Security Graph
assigns, and a record the CVSS rated below HIGH is graded ELEVATED. CVE-2024-22412 above is rated LOW,
so a scan gated at HIGH reports it without failing.
One scan for a mixed fleet
The check is not limited to ClickHouse. It matches the server version on PostgreSQL, MySQL, MariaDB, and
SQL Server too, and on PostgreSQL it checks the installed extensions as well. Pass --url more than once
to scan several servers in one run:
atlas security scan \
--url "clickhouse://root:pass@127.0.0.1:19000/" \
--url "postgres://postgres:pass@localhost:5432/app?sslmode=disable" \
--url "mysql://root:pass@localhost:3306"
A server that could not be reached is reported with the rest instead of ending the scan, and fails the
command, since its state is unknown. On an engine the check does not cover, such as SQLite, the scan
succeeds and reports no issues, so the line no issues found in the server version there does not mean
the version was checked. See Engines and extensions for
what is checked on each engine.
atlas security scan is available to Atlas Pro users with the Security Graph enabled in
their plan. Run atlas login to get started with a free trial.
Getting Alerted Next Time
CVE-2026-116366 won't be the last vulnerability found, and a scan you run once only tells you about the CVEs published up to that point. To keep your servers protected, run the scan on a schedule.
With Atlas, you can schedule scans where your pipelines or clusters already live, checked against a consistently updated list of CVEs. This gives you the peace of mind that if a CVE is released today, you'll know about it, and which of your servers it affects.
GitHub Actions
The security/scan action runs the scan in a workflow. This one scans staging and production every
morning and fails on a HIGH finding. Each finding of the server version is added as a warning annotation
that names the engine, and listed in the job summary:
name: Database Security Scan
on:
schedule:
- cron: '0 6 * * *'
workflow_dispatch:
jobs:
scan:
runs-on: ubuntu-latest
environment: monitoring
steps:
- uses: ariga/setup-atlas@v0
with:
cloud-token: ${{ secrets.ATLAS_CLOUD_TOKEN }}
- uses: ariga/atlas-action/security/scan@v1
with:
urls: |
${{ secrets.STAGING_CLICKHOUSE_URL }}
${{ secrets.PROD_CLICKHOUSE_URL }}
fail-on: HIGH
Keep the database URLs in an environment that only the default branch can use, so a pull request cannot run with them.
Kubernetes Operator
On a cluster running the Atlas Kubernetes Operator, the AtlasSecurityScan
resource scans on a schedule and grades the findings against a policy. Store the database URL and an
Atlas bot token in Secrets:
kubectl create secret generic clickhouse-db \
--from-literal=url='clickhouse://root:pass@clickhouse.app:9000'
kubectl create secret generic atlas-token --from-literal=ATLAS_TOKEN="$ATLAS_TOKEN"
Then create a scan that runs every morning and fails the policy on a HIGH finding:
apiVersion: db.atlasgo.io/v1alpha1
kind: AtlasSecurityScan
metadata:
name: clickhouse
spec:
urlFrom:
secretKeyRef:
name: clickhouse-db
key: url
cloud:
tokenFrom:
secretKeyRef:
name: atlas-token
key: ATLAS_TOKEN
schedule: "0 6 * * *"
timeZone: UTC
policy:
minSeverity: ELEVATED
failOn: HIGH
The first scan runs as soon as the resource is created. The verdict is exposed as Kubernetes conditions:
Ready says whether the scan ran, and Compliant whether the server is within the policy, so
kubectl wait --for=condition=Compliant works as a deployment gate.
The status of the scan holds only the number of findings and their levels. The server version and the CVE
identifiers are stored in an AtlasSecurityReport, which has its own RBAC role, so read access to the scan
does not reveal which CVEs a server is exposed to:
kubectl get atlassecurityreport clickhouse -o yaml
For the server above, the report lists all three CVEs as findings of the engine. The last one reads:
- cvssSeverity: CRITICAL
description: 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.
engine: clickhouse
extension: ""
id: CVE-2026-116366
level: CRITICAL
suggestion: Upgrade database engine "clickhouse" to version 26.3.62.3 or later
to resolve CVE-2026-116366
title: Unauthenticated RCE vulnerability against ClickHouse Server
version: 23.10.4.25
Add triggers to scan again whenever an AtlasSchema or AtlasMigration applies a change. See
Security Scanning with the Operator for waivers, triggers, and
failure handling.
Slack notifications
A notify block in atlas.hcl posts the result to a webhook whenever the scan finds something or cannot
reach a server, and sends nothing when it is clean:
variable "slack_webhook" {
type = string
}
env "prod" {
url = getenv("CLICKHOUSE_URL")
security {
fail_on = HIGH
notify {
on = [FINDINGS, FAILURE]
http "slack" {
url = var.slack_webhook
headers = { "Content-Type" = "application/json" }
body = jsonencode({ text = scan.report })
}
}
}
}
The notification is sent before the command picks its exit code, so a scan that fails on fail_on still
posts to Slack. See Notifications for the fields available to the
message.
Wrapping Up
New CVEs don't wait for your next audit. With one command, atlas security scan reads the server version
of every ClickHouse server you point it at, matches it against the Atlas Security Graph, and names the
release that fixes each CVE it finds. Run it today to find the servers that need the CVE-2026-116366
upgrade before the fix goes public on November 13. Then put it on a schedule with GitHub Actions or the
Atlas Kubernetes Operator, and the next CVE published for your version shows up as a failed check or a
Slack message, not as a surprise.
The scan is part of Atlas Pro. Log in to start your free trial, and scan your first server:
atlas login
atlas security scan --url "clickhouse://root:pass@127.0.0.1:19000/"
To begin managing your ClickHouse databases with Atlas, follow the ClickHouse guide, or schedule a demo to see how scanning and the Security Graph fit your ClickHouse fleet.
Security Scanning
Security Scanning with the Operator