Apache Cassandra on the internet: where the exposed port is not the service

A distributed database is a data store first and a service second. The interesting exposure is not whether a port answers but whether a client can complete a handshake and issue a query. For Cassandra those two questions are separated by a default configuration that surprises people: the native transport is often left bound to loopback while the cluster communication port is not.

Context and method

Counts were collected through the ZoomEye SDK on 2026-09-26 UTC using the exact dorks shown.

• app="Cassandra": 5,017
• port="9042": 9
• port="9042" && service="native": 0 The application fingerprint count is in the low thousands, which is plausible for a widely used database. Port 9042 is the native client transport port, and it is nearly empty in this dataset, which matches the common practice of binding the native transport to loopback and reaching the database through an application instead. The combined port and service query returns nothing, because the service label used for the native protocol is not an HTTP service label. The two zero and near-zero results are not evidence that the database is rare; they are evidence about which ports administrators expose.

What the ports carry

Port 9042 carries the CQL native protocol used by drivers, and it is where queries and results travel. Port 7000 carries internode communication within a data centre and 7001 across data centres, and these carry replication traffic and gossip about cluster membership. An exposed internode port is not a query interface, but it is information about the cluster: which nodes exist, their state, and the topology. The JMX port, when enabled and reachable, is a management interface that can expose internals and, in some configurations, allow operations.

The configuration that decides the risk

The native transport address and port are separate settings from the listen address, and authentication and authorisation are enabled through a configurable authenticator and authorizer. A cluster with the default permissive authenticator accepts CQL connections without credentials from anything that can reach 9042. TLS is a further separate setting. Because few deployments expose 9042, the more common finding is an exposed JMX or internode port on a host whose administrator assumed the database was private.

Checks worth running

Attempt a CQL connection from outside the intended network only against a host you own, and observe whether the server responds to a handshake. On the deployment, list every listening socket and compare it with the set the documentation says is needed for the roles in that node. Confirm the authenticator and authorizer settings, then confirm the same settings apply to all nodes, because a configuration file copied to one node and not the others is a real pattern. Check whether JMX is enabled and whether it is reachable from anywhere but a management host.

References

• Apache Cassandra documentation, security and authentication configuration
• Apache Cassandra documentation, ports and networking
• Apache Cassandra documentation, JMX access and monitoring options