DEV Community

SorrelThorncroft
SorrelThorncroft

Posted on

127,120 ClickHouse Fingerprints and the Default User Behind Them

#clickhouse #analytics #accesscontrol #defaultuser

127,120 ClickHouse Fingerprints and the Default User Behind Them

Analytics engines occupy an unusual position. They are usually fed by a pipeline from production systems, which means they hold copies of the data those systems contain, in a form that is fast to query and often less carefully guarded than the originals.
ZoomEye measurements collected on 28 October 2026 show 127,120 assets matching app="ClickHouse" and 1,031 matching title="ClickHouse". The gap between the two is worth noting: the app fingerprint finds the native protocol surface, while the title match finds only the deployments that serve a page naming the product.

The user named default

ClickHouse documentation on access rights and account management explains the model in a way that repays a careful read. There are two configuration files, users.xml and config.xml, and a recommended SQL-driven workflow that sits alongside them. Both methods work simultaneously, which is a source of understandable confusion: a change made in SQL and a change made in XML can disagree, and the effective result depends on which is read first.
The documentation also states plainly that the default user account is used in any case where a username is not defined, for example at login from a client or in distributed queries. In distributed query processing, a default user account is used if the server or cluster configuration does not specify the user and password properties.
That sentence describes a convenience that becomes a security property. The engine has an answer ready when the caller does not name a user, and the answer is a real account with real privileges. Whether it has a password is a configuration choice.
For the default user, the documentation describes enabling SQL-driven access control and account management by setting access_management and named_collection_control to 1. Other users have both settings enabled by default, which is the sort of asymmetry worth remembering during a review: the default account is the one that needs the explicit toggle.

Where the risk actually sits

Exposure here is not a single misconfiguration. It is the combination of an account that answers when unnamed, a network that allows the native protocol port to be reached, and a data set that contains something worth reading.
The analytics pattern amplifies all three. A data warehouse feeding dashboards is queried by tools, not by people, so the credentials live in a tool's configuration. Those credentials are frequently the default account because that is what the connection wizard accepted on day one, and they are rarely revisited because the dashboards keep working.
Consider what an unauthenticated reader finds. Table names that describe the business. Column names that match the production schema. Row counts that reveal scale. In many deployments the data itself is a de-identified copy, and the schema alone still maps the organisation.

A short review

Confirm whether the default user has a password and whether it is reachable from outside the host. On a single-node deployment started from a package, both answers are frequently "no" and "yes" respectively, which is the combination that matters.
Then enumerate the users and their grants through the SQL interface. The documentation's SQL-driven workflow exists precisely so that this is a query rather than a file inspection, and the results are easier to audit than XML.
Check which network interfaces the server binds. A cluster node that only needs to talk to other cluster nodes does not need to accept connections from the internet, and the HTTP interface that serves queries has its own access considerations separate from the native protocol.
Finally, look at what the pipeline writes. An analytics store is a copy, and the classification of the copy is usually inherited from the source without any of the controls that the source carries. That gap is older than any specific product and worth closing independently of the tool in use.

Reading the number correctly

The 127,120 figure counts assets that match a ClickHouse fingerprint. It does not count installations with an unauthenticated default user, and it cannot: that state has no signature.
What it does indicate is that a widely deployed engine now sits in a large number of environments, many of them small, many of them started by a data team rather than by an infrastructure team. Small deployments with default settings are the ordinary case, not the exceptional one, and the fix is a configuration change rather than a project.

References

Top comments (0)