CVE-2024-23689

What it actually does

Affected ClickHouse Java components, including clickhouse-r2dbc, com.clickhouse:clickhouse-jdbc, and com.clickhouse:clickhouse-client before 0.4.6, can include the client certificate password in exception text when TLS client-certificate configuration uses the sslkey option and a ClickHouseException, SQLException, or related database operation error is thrown. The flaw is an information disclosure issue in error handling and logging: sensitive authentication material that should remain in memory or protected configuration can be written to application logs, centralized log platforms, crash reports, monitoring systems, or support bundles. If an attacker can both trigger relevant failures and access the resulting logs, they may recover the certificate password and potentially use it with associated certificate/private-key material to authenticate to ClickHouse or related services.

Why it matters to the business

This issue can expose database client credential material through normal operational logs, turning routine application errors into a credential-leak path. If logs are broadly accessible, exported to third-party observability tooling, or retained for long periods, the exposure window may be significant. Compromise of ClickHouse client certificate passwords can lead to unauthorized database access, data theft, data tampering, service disruption, and costly credential/certificate rotation. Although it is not listed in CISA KEV and the EPSS score is currently low, exploit code is available and the vulnerability has been public since 2024-01-19, so affected deployments should be treated as overdue for remediation.

How an attack unfolds

An attacker first identifies an application or service that uses a vulnerable ClickHouse Java driver/client version with TLS client-certificate settings that include sslkey. The attacker then causes a database operation to fail, for example by submitting input that results in an invalid query, malformed parameter, failed connection, timeout, authentication error, or other condition that causes the ClickHouse client to throw a ClickHouseException or SQLException. The application or framework logs the exception message, and the vulnerable client includes the client certificate password in that message. The attacker then obtains the logs through application log access, a compromised low-privileged account, exposed log aggregation tooling, support bundle access, container logs, CI/CD job output, or another log-read path. With the leaked password, the attacker attempts to decrypt or use the corresponding client key/certificate if available, then connects to ClickHouse or pivots through services that trust that certificate, potentially reading, modifying, or disrupting data depending on the privileges assigned to that client identity.

How to fix it

Upgrade all affected ClickHouse Java dependencies to version 0.4.6 or later. For source-based builds, include the upstream fix commit dd91e1776b94a30e32fecf9c82354685295169a6 or a later commit containing the fix. Review Maven, Gradle, shaded JARs, application server libraries, container images, and transitive dependencies for com.clickhouse:clickhouse-jdbc, com.clickhouse:clickhouse-client, and clickhouse-r2dbc versions below 0.4.6. After upgrading, rotate any client certificate passwords, private keys, and certificates that may have been present in logs, and invalidate old credentials where possible. Remove sensitive historical logs or restrict their access according to retention and legal requirements. Add log redaction for sslkey-related parameters, certificate passwords, private-key passphrases, JDBC URLs, and database connection properties. Restrict log access to least privilege and avoid sending sensitive exception payloads to third-party systems unless protected by appropriate access controls and retention limits.

How to confirm the fix worked

Confirm dependency versions with build tooling such as mvn dependency:tree, gradle dependencies, software composition analysis, or SBOM inspection, and verify that no deployed artifact contains ClickHouse Java client, JDBC, or R2DBC components below 0.4.6. For source builds, verify that commit dd91e1776b94a30e32fecf9c82354685295169a6 or a later fixed revision is present. In a non-production test environment, configure a ClickHouse connection using equivalent TLS client-certificate settings and intentionally trigger a connection or query exception; the resulting exception message and logs must not contain the certificate password, sslkey secret material, private-key passphrase, or full sensitive connection string. Search current and historical logs for leaked values and verify that log redaction rules remove sensitive connection properties. Validate that certificate/key rotation completed by confirming old credentials no longer authenticate and updated applications continue to connect successfully.

Typical attack path

1. Find an application using vulnerable ClickHouse Java components: clickhouse-r2dbc, com.clickhouse:clickhouse-jdbc, or com.clickhouse:clickhouse-client before 0.4.6.
2. Confirm the application uses TLS client-certificate configuration involving sslkey and a protected client key.
3. Trigger a database exception through malformed input, invalid query behavior, failed connection conditions, or other controllable error paths.
4. Wait for the application, framework, container runtime, or observability agent to log the thrown ClickHouseException, SQLException, or related stack trace.
5. Access application logs, centralized log storage, support bundles, CI/CD logs, or monitoring output that contains the exception text.
6. Extract the exposed client certificate password from the logged exception message.
7. Use the password with any obtainable client key/certificate material to authenticate to ClickHouse or impersonate the affected client identity.
8. Perform unauthorized data access, modification, deletion, or lateral movement according to the privileges granted to that certificate identity.

How to detect it

To determine whether this was already exploited or resulted in credential exposure, review application logs, container stdout/stderr, Java exception logs, centralized SIEM/log aggregation data, APM traces, crash reports, support bundles, CI/CD job output, and incident/debug logs for ClickHouse exceptions that include connection properties or TLS key settings. Focus on time periods when applications used ClickHouse Java client, JDBC, or R2DBC versions below 0.4.6 and had sslkey configured. Search for ClickHouseException or SQLException stack traces near sslkey, certificate, private-key, passphrase, password, or JDBC URL fields. Investigate whether users or service accounts accessed log records containing these secrets, including downloads, exports, dashboard views, support bundle retrievals, or API queries against log platforms. Correlate any suspected leak time with ClickHouse authentication logs, query logs, and network telemetry for unusual use of the affected certificate identity, new source IPs, abnormal query volume, data export behavior, failed authentication attempts, schema changes, or destructive operations. Because this vulnerability leaks secrets through logs rather than producing a unique network exploit signature, the strongest evidence is the presence of sensitive sslkey/certificate password material in exception logs followed by suspicious access to those logs or unusual database activity using the same client identity.

• com.clickhouse.client.ClickHouseException
• java.sql.SQLException
• ClickHouseException
• SQLException
• sslkey=
• sslkey:
• sslcert=
• sslrootcert=
• client certificate password
• certificate password
• private key password
• key password
• passphrase
• jdbc:clickhouse://
• clickhouse-jdbc
• clickhouse-client
• clickhouse-r2dbc
• com.clickhouse:clickhouse-jdbc
• com.clickhouse:clickhouse-client

What your security team should do

• Prioritize upgrade of all ClickHouse Java client, JDBC, and R2DBC components below 0.4.6, especially internet-facing applications, multi-tenant services, and systems whose logs are accessible to developers, support users, or third-party platforms.
• Immediately search application, container, database access, CI/CD, and centralized logging systems for ClickHouse exceptions containing sslkey-related connection properties or certificate password values.
• Rotate any client certificate passwords, private keys, and certificates that may have appeared in logs; treat exposed secrets as compromised rather than merely mislogged.
• Restrict access to historical logs and support bundles until searches and cleanup are complete.
• Implement log redaction for JDBC URLs, ClickHouse connection properties, sslkey values, certificate passphrases, and generic password-like fields.
• Review ClickHouse permissions for affected client identities and reduce privileges to the minimum required to limit impact if credentials were exposed.
• Add dependency/SBOM policy gates to prevent introduction of com.clickhouse ClickHouse Java artifacts below 0.4.6.
• Monitor for suspicious ClickHouse authentications or queries using certificate identities associated with vulnerable applications, especially after logged exception spikes.