CVEs, ClickHouse®, and Altinity.Cloud: Separating Signal from Noise

You are reviewing your morning security report. A scanner has flagged a CVE against ClickHouse — severity: Critical. Your pulse quickens. Is production data exposed? Should you page the on-call team right now?

Probably not. Here’s why:

Security scanners, automated dependency checks, and AI-assisted research are producing more CVE reports than ever. Some of them look alarming, especially when they come with a high severity score. What these tools cannot do is tell you whether a specific CVE matters in your specific environment. That requires context, and in most cases, when you apply that context, a “Critical” CVE becomes a scheduled maintenance item rather than a 2 a.m. incident.

A CVE does not automatically mean your ClickHouse environment is exposed. Real exposure depends on a short checklist:

1. Is the affected component actually used?
2. Is the vulnerable feature enabled?
3. Can an attacker reach it from outside?
4. Does exploitation require authentication or elevated privileges?
5. Is there already a platform-level mitigation in place?

For Altinity.Cloud customers, many common attack paths are blocked by design before this checklist even becomes relevant. ClickHouse clusters are isolated per tenant, connections are encrypted, internal services are not reachable from the internet, and production environments can run entirely over private connectivity: VPC peering, private endpoints, or VPN.

This guide walks through the main CVE categories you will encounter and explains how to assess each one calmly and practically.

How to Assess a CVE Before Reacting

When a CVE lands in your inbox, work through these six questions before escalating:

A CVE only becomes urgent when the vulnerable component is present, enabled, reachable, and accessible to a plausible attacker. In practice, one of those conditions is usually not met.

The rest of this article explains how to apply this framework to the most common CVE categories you will see in practice.

ClickHouse CVEs

These are the most directly relevant ones, and even here, practical impact is heavily configuration-dependent.

ClickHouse is a large, feature-rich system. Many vulnerabilities are confined to a specific table engine, function, protocol, bridge, file access path, or configuration option. A CVE in a feature your cluster does not use, or one that requires privileges your application users do not have, is not an immediate threat.

That is why the severity score alone is not enough to make a decision.

In many cases, a ClickHouse CVE can be mitigated before upgrading. CVE-2024-22412, for instance, can be addressed by disabling the query cache for untrusted users; CVE-2025-1385 by closing the library bridge port. Upgrading remains the cleanest long-term solution, but concrete workarounds like these usually give you the time to plan it properly rather than rush an emergency upgrade.

What to do:

• Apply patch releases within your current branch regularly — these are low-risk and routinely include security fixes.
• Plan a major version upgrade roughly once per year to stay on a supported release line.
• Disable optional features that are not needed in your environment.
• Grant application users only the permissions they actually require, not admin access “just in case.”
• Avoid shared administrator accounts.

Container and OS Package CVEs

This is where security scanners generate the most noise, and where the gap between scanner output and actual risk is widest.

Standard ClickHouse container images are built on top of Linux distributions and include many OS packages. A scanner will report every CVE in every package, including packages that are installed but never executed and never reachable through any ClickHouse code path.

ClickHouse is distributed as a self-contained binary. Its only runtime dependency is glibc (and there are active plans to move to musl, which would eliminate even that). Most other packages in the image exist for OS completeness, not because ClickHouse loads or calls them. The exception is auxiliary binaries shipped alongside the server — such as the ODBC bridge — but those run as separate, isolated processes by design. The ODBC bridge exists precisely to contain potential vulnerabilities in third-party ODBC drivers: if a driver has a flaw, it is isolated from the main server process.

Choosing a minimal base image is one of the most effective ways to reduce scanner noise structurally. Both Altinity Stable and upstream ClickHouse publish Alpine variants — altinity/clickhouse-server:24.8.14.10546.altinitystable-alpine and clickhouse/clickhouse-server:26.3.10-alpine — that ship significantly fewer OS packages than their Ubuntu/Debian counterparts, though note that Alpine images still include glibc from Ubuntu, so the server’s runtime dependency remains unchanged. For the most aggressive noise reduction, upstream ClickHouse started to publish distroless images since April 2026 (clickhouse/clickhouse-server:26.3.10-distroless): these cut scanner output to the bare minimum, at the cost of having no shell available inside the container for debugging.

A CVE in an unused package sitting on the container filesystem is fundamentally different from a CVE in a running service. The scanner cannot tell the difference. That’s where humans come in.

What actually matters:

• Vulnerabilities in ClickHouse Server itself
• Vulnerabilities in glibc (the server’s only runtime library dependency)
• Vulnerabilities in ODBC drivers used via the ODBC bridge (the bridge itself is isolated from the server for exactly this reason)
• Vulnerabilities in services that are running and reachable
• Packages used by customer-managed scripts, sidecars, or custom images

What to do:

• Use supported Altinity or upstream images and keep them updated.
• When reviewing scanner output, ask “is this code actually reachable?” — not just “is this package present?”
• Treat vulnerabilities in ClickHouse itself, glibc, and running services as higher priority than unloaded OS packages.
• Apply extra scrutiny to custom containers that add tools, scripts, or additional services.
• Contact your vendor if you still have doubts. Altinity users can log findings as a support case. 

Kernel and Kubernetes CVEs

Kernel vulnerabilities sound alarming. Most of them carry a critical precondition: the attacker must already be executing code on the same node as your workload. That is a remote code execution scenario — an entirely different threat from a remotely exploitable network service.

Consider CVE-2026-31431 (“Copy Fail”): it requires an attacker to already be executing specially crafted code on the node. Since the node in Altinity.Cloud runs nothing but ClickHouse, the attack surface does not exist unless the attacker has already compromised the system through an entirely separate vulnerability, at which point the kernel CVE is the least of your problems. In fact, thinking about this exact example prompted me to write the blog article you are now reading. 

Kubernetes CVEs follow the same logic. Exploiting a Kubernetes vulnerability typically requires access to the cluster’s internal API, a node, or a privileged pod — none of which are normally reachable from outside the platform.

In ClickHouse itself, remote code execution is not possible without cluster-admin privileges. Features that execute external code — executable UDFs and executable dictionaries — require explicit cluster-wide configuration (<user_defined_executable_functions_config> etc.) that only cluster administrators can set. Application users cannot trigger code execution on the host.

In Altinity.Cloud, these threat models are further reduced by infrastructure isolation:

• Customer workloads are not co-located with unrelated or untrusted tenant workloads, eliminating the classic “malicious neighbor exploits a kernel bug to escape to my node” scenario.
• Tenant isolation goes all the way down: each customer environment runs on a completely independent Kubernetes cluster — its own network, its own node groups, its own cloud infrastructure, its own administrative scope — with nothing shared across customer environments.
• This holds true in BYOC and BYOK deployments as well: access to one customer environment does not grant privileges in another.

For Altinity-managed deployments, Altinity monitors and maintains the underlying Kubernetes and infrastructure layers. For BYOC and BYOK deployments, some infrastructure responsibilities are shared or customer-owned depending on the deployment model.

What to do:

• Protect access to your cloud account and administrative interfaces — this matters more than most CVEs.
• Use strong IAM policies with least-privilege access.
• Avoid exposing Kubernetes, node, or internal service endpoints outside the private network.
• Keep customer-managed components updated where applicable.

Network Exposure

Network exposure is often the single factor that separates a theoretical vulnerability from an actual incident.

A vulnerability reachable from the public internet with no authentication required is a critical emergency. The exact same vulnerability that requires private network access, valid credentials, and specific ClickHouse privileges is a controlled risk you can address on a normal schedule.

One of the strongest network controls available — and one that applies to most databases, not just ClickHouse — is restricting connections to a known, approved set of clients: your application backend, specific BI tools, scheduled scripts, and nothing else. If an unrecognized source cannot connect at all, it cannot send malformed packets, probe protocol parsers, or attempt exploit delivery — regardless of which CVEs exist in the version you are running. Treating any unrecognized source as unauthorized by default is a more robust posture than reacting to individual vulnerabilities as they are disclosed.

In Altinity.Cloud, direct access to internal platform services is not possible from the outside. The external surface is the customer-facing ClickHouse endpoint, and connections are encrypted. Internal services, operators, and infrastructure components are not directly reachable.

For sensitive production workloads, disabling public internet access entirely and relying on private connectivity is the strongest posture available — and the one we recommend for any environment handling regulated or sensitive data.

What to do:

• Prefer VPC peering, private endpoints, or VPN for production environments.
• Disable public internet access where possible.
• Allowlist approved clients by source — application backends, BI tools, known scripts — and deny everything else by default. 
• Use IP allowlists when public access is required.
• Do not expose internal ClickHouse or infrastructure ports directly.
• Keep TLS enabled.

Access Control, Quotas, and Dangerous Features

Some CVEs only matter if an attacker already has an authenticated session with broad permissions. Good access hygiene cuts this risk significantly — and has the added benefit of containing the blast radius if credentials are ever compromised.

Application users should not have administrator-level access. Different teams, services, and environments should use separate accounts. Powerful features — broad filesystem access, external URL fetching, executable integrations, powerful table engines like S3 or URL — should be restricted to users who genuinely need them.

remote_url_allow_hosts should be on your configuration checklist for every ClickHouse deployment. It whitelists the destinations ClickHouse is permitted to connect to, preventing it from being used as a pivot to scan internal networks and cutting off a broad class of server-side request forgery and data exfiltration risks at the root. Any host not on the list cannot be reached by functions like url(), s3(), or remote dictionary sources — even if a user has the privileges to call them:

<clickhouse>
    <remote_url_allow_hosts>
        <host>trusted-host.example.com</host>
        <host_regexp>^.*\\.myhost\\.com$</host_regexp>
    </remote_url_allow_hosts>
</clickhouse>

To block all outbound connections entirely, an empty tag is sufficient:

<clickhouse>
    <remote_url_allow_hosts />
</clickhouse>

ClickHouse also ships with a set of opt-in access control improvements worth enabling on any security-conscious deployment. They are off by default for backwards compatibility, but together they close several gaps in the default access model:

<clickhouse>
    <access_control_improvements>
        <!-- users without row policies are denied, not allowed -->
        <users_without_row_policies_can_read_rows>false</users_without_row_policies_can_read_rows>
        <!-- ON CLUSTER queries require an explicit CLUSTER grant -->
        <on_cluster_queries_require_cluster_grant>true</on_cluster_queries_require_cluster_grant>
        <!-- system tables and information_schema require explicit SELECT grants -->
        <select_from_system_db_requires_grant>true</select_from_system_db_requires_grant>
        <select_from_information_schema_requires_grant>true</select_from_information_schema_requires_grant>
        <!-- settings constraints from roles replace rather than merge -->
        <settings_constraints_replace_previous>true</settings_constraints_replace_previous>
        <!-- table engines like S3, URL, HDFS require explicit grants -->
        <table_engines_require_grant>true</table_engines_require_grant>
    </access_control_improvements>
</clickhouse>

On the same theme, it is worth explicitly forbidding weak password configurations at the server level:

<clickhouse>
    <!-- forbid plaintext and empty passwords -->
    <allow_plaintext_password>0</allow_plaintext_password>
    <allow_no_password>0</allow_no_password>
    <allow_implicit_no_password>0</allow_implicit_no_password>
</clickhouse>

Without these, it is possible to create users with no password or a plaintext password stored in configuration — both of which are easy to miss in a security review.

Denial-of-service vulnerabilities are best addressed through the same operational controls that protect against ordinary runaway queries: query quotas, concurrency limits, memory limits, execution-time limits, monitoring, and workload isolation. These controls make your environment more resilient against both CVEs and accidental resource exhaustion.

Profile settings alone are not enough — without constraints, users can override them per query. A user could set max_memory_usage=0 to remove memory limits entirely, or disable query logging to avoid audit trails. Setting constraints locks the boundaries so users can tune within a range but cannot escape them:

<clickhouse>
  <profiles>
    <strict_profile>
      <log_queries>1</log_queries>
      <max_memory_usage>10000000000</max_memory_usage>
      <max_execution_time>600</max_execution_time>
      <max_concurrent_queries_for_user>10</max_concurrent_queries_for_user>
      <constraints>
        <!-- users cannot disable query logging -->
        <log_queries><readonly/></log_queries>
        <log_query_threads><readonly/></log_query_threads>
        <!-- users can tune memory and time limits, but not remove them -->
        <max_memory_usage>
          <min>1</min>
          <max>10000000000</max>
        </max_memory_usage>
        <max_execution_time>
          <min>1</min>
          <max>1200</max>
        </max_execution_time>
        <!-- concurrency limit is fixed -->
        <max_concurrent_queries_for_user><readonly/></max_concurrent_queries_for_user>
      </constraints>
    </strict_profile>
  </profiles>
</clickhouse>

What to do:

• Use separate users for different applications and teams. For larger organizations, ClickHouse supports LDAP and Kerberos for centralized access control, and OAuth is supported in Altinity builds — all preferable to managing local credentials manually at scale.
• Grant only the permissions each user actually needs.
• Avoid shared admin credentials.
• Restrict powerful or dangerous features to explicitly trusted users.
• Configure quotas, memory limits, and execution-time limits on all environments.
• Monitor for abnormal query patterns.
• Isolate risky or experimental workloads from production.

Credentials, Object Storage, and Backups

Not every security risk comes with a CVE number. Some of the most consequential incidents come from exposed credentials, overly broad object-storage permissions, misconfigured backups, or filesystem access granted to users who do not need it.

In Altinity.Cloud’s SaaS model, Altinity follows a least-privilege approach for platform-managed access: role-based access is preferred over static keys, backup storage permissions are narrowly scoped, and backups are encrypted. In BYOC and BYOK deployments, backup storage is customer-owned and customer-configured — the recommendations below apply directly to you.

What to do:

• Prefer role-based access over long-lived static credentials.
• Scope object-storage permissions narrowly for backup and data access.
• Encrypt backups and verify they are landing in the right accounts, regions, and buckets.
• Rotate credentials regularly and immediately when personnel change.
• Restrict ClickHouse features that allow broad filesystem, S3, or external-URL access.

For step-by-step backup configuration, see the Altinity.Cloud backup guide and the BYOK backup guide.

The Bigger Picture: CVEs Are Only Part of Security

Here is something the CVE databases do not show you: CVEs, taken by themselves, are rarely the whole story.

In practice, most serious incidents are not caused by someone discovering a zero-day and exploiting an unpatched CVE against a well-configured, properly isolated database cluster. They are caused by:

• Credentials that were too broad and were accidentally exposed
• A service that was open to the internet when it should not have been
• An admin account shared across teams with no rotation
• Backups stored in an overly accessible location
• A misconfigured permission that gave an application user write access to a table it should only read

Good security is a combination of layers: keeping software reasonably current, limiting network exposure, managing credentials carefully, maintaining least-privilege access, and tracking CVEs and acting on the ones that actually matter.

CVE hygiene is one tile in that mosaic. Treating it as the entire picture leads to alarm fatigue, misprioritization, and a false sense of security when the scanner is green.

When in Doubt, Ask

Security assessments do not have to be a solo exercise.

If you have received a scanner report, seen a disclosure, or spotted something that concerns you, contact Altinity support. The team can help you determine whether a specific CVE affects your deployment, what platform-level mitigations are already in place, and whether any action is required on your side.

If you think you have found a new CVE, do not file a public issue on GitHub. Instead, send an email to security at altinity dot com if you are using Altinity builds, including the Altinity Kubernetes Operator for ClickHouse or the Altinity Backup for ClickHouse. For ClickHouse upstream builds, follow the ClickHouse Security Vulnerability Response Policy. 

You do not need to figure this out alone.

Summary

CVEs are worth taking seriously. They are not worth panicking over.

For Altinity.Cloud customers, the platform provides meaningful baseline protections: tenant isolation, encrypted connections, restricted internal access, managed infrastructure, private connectivity options, and a limited runtime attack surface. These defenses reduce the practical impact of many CVEs before you even begin your assessment.

Your responsibilities are straightforward: keep ClickHouse reasonably current, limit network exposure, use least-privilege access, avoid shared credentials, and configure limits for untrusted workloads.

When something looks worrying, apply the six-question framework above. If the answer is still unclear, reach out to Altinity support — that’s what the team is there for.

Altinity monitors CVEs and platform security continuously. The strongest posture combines platform protections with regular upgrades, careful access hygiene, and a clear-eyed approach to risk — one CVE at a time.