Port 9042 – Cassandra (CQL Native Transport)

Port 9042 is the default port for the CQL native transport — the modern client protocol of Apache Cassandra, the wide-column NoSQL database. The Cassandra daemon listens here and speaks CQL (Cassandra Query Language) to the cqlsh shell and to every application driver; it replaced the old Thrift interface (still on 9160) as the way clients talk to a cluster. The marquee risk is blunt: Cassandra ships with authenticator: AllowAllAuthenticator — authentication is disabled by default — so an exposed port 9042 frequently means anyone who can reach it connects with cqlsh <target> 9042, then reads, dumps, or overwrites every keyspace and table and creates their own roles. Even where password auth has been switched on, the database is seeded with a well-known default superuser, cassandra / cassandra, that is routinely left unchanged. An exposed Cassandra is, in practice, full data access with no exploit required. The same port is used by API-compatible variants DataStax and ScyllaDB, so all three share this attack surface.

Why It’s Open

Cassandra is built to be spoken to constantly: application servers, ETL jobs, and admin tooling all open CQL connections to port 9042, and cqlsh connects here for day-to-day operations. In a sound deployment that traffic stays on a private network, but Cassandra is frequently stood up on cloud VMs, in Docker containers, and on Kubernetes services where a -p 9042:9042 mapping or an over-broad security group quietly publishes the native transport to the internet.

The defaults make an exposed port dangerous rather than merely noisy. Stock cassandra.yaml sets authenticator: AllowAllAuthenticator and authorizer: AllowAllAuthorizer, which means no login is required and every operation is permitted. Operators who do enable PasswordAuthenticator inherit a bootstrap superuser account, cassandra, whose initial password is also cassandra — and because rotating it requires a deliberate ALTER ROLE, it is often still valid months later. Around the native transport sit the rest of a cluster’s ports: 7000 (and 7001 for TLS) carry inter-node gossip and replication, 7199 exposes the JMX management interface, and 9160 is the deprecated legacy Thrift RPC port that predates CQL. Each of those is its own surface — the JMX side on 7199 in particular has historically been the RCE path — but for clients and attackers alike, 9042 is the front door to the data.

Common Risks

• Unauthenticated access (the big one). With the default AllowAllAuthenticator, a Cassandra reachable on 9042 grants full read and write to every keyspace to anyone who can connect. No exploit, no credentials — just cqlsh, DESCRIBE KEYSPACES, and SELECT *.
• Default superuser cassandra / cassandra. When password auth is enabled but the seeded superuser is left at its default password, an attacker logs straight in with full administrative rights and can create new roles to persist.
• Wholesale data exfiltration and tampering. Once connected, an attacker can dump entire tables, COPY data out, TRUNCATE/DROP keyspaces, or plant data — the same ransom-and-wipe playbook seen against other exposed NoSQL stores.
• Password-hash theft for offline cracking. The system_auth.roles table stores role password hashes (bcrypt). A reader can dump them and crack them offline, then reuse the credentials elsewhere.
• UDF sandbox escape to RCE. With scripted user-defined functions enabled and their thread isolation turned off, a user who can create functions can break out of the sandbox and run code on the host (CVE-2021-44521 — see below).
• Information disclosure. system.local and system.peers reveal the exact release version, cluster name, and topology, telling an attacker precisely which bugs apply and where the other nodes live.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The first question on an open 9042 is whether it asks for credentials at all. If it doesn’t, you are one command from the entire dataset. Confirm the service, then attempt an unauthenticated CQL session before anything heavier.

Detect the service and version

nmap -sV -p 9042 <target>

Cassandra’s native transport fingerprints as apache-cassandra under -sV; note the version so you can map it to known issues.

Connect over CQL with no credentials (the critical test)

cqlsh <target> 9042

If you land at a cqlsh> prompt without being asked for a password, the instance is running AllowAllAuthenticator — that no-auth condition is itself the finding. If it does prompt, try the seeded superuser:

cqlsh <target> 9042 -u cassandra -p cassandra

Enumerate and sample data

DESCRIBE KEYSPACES;
USE <keyspace>;
DESCRIBE TABLES;
SELECT * FROM <keyspace>.<table> LIMIT 10;
SELECT cluster_name, release_version FROM system.local;
LIST ROLES;
-- Dump role password hashes (bcrypt) for offline cracking:
SELECT role, is_superuser, salted_hash FROM system_auth.roles;

Crack dumped role hashes

Cassandra stores role passwords as bcrypt ($2a$...) in system_auth.roles. Feed the salted_hash values to hashcat’s bcrypt mode:

hashcat -m 3200 cassandra_hashes.txt /usr/share/wordlists/rockyou.txt

Legacy Thrift port (9160), if present

Nmap’s Cassandra NSE scripts speak the old Thrift protocol on 9160, not CQL on 9042 — run them only against a Thrift listener:

nmap -p 9160 --script cassandra-info <target>
nmap -p 9160 --script cassandra-brute <target>

cassandra-info returns cluster name and version; cassandra-brute performs credential brute-forcing. A live 9160 means the deprecated Thrift RPC interface is still enabled — extra attack surface worth flagging.

There is no dedicated Metasploit module for the CQL native transport itself; the only cassandra module in the framework (auxiliary/scanner/http/cassandra_web_file_read) targets the separate Cassandra Web management UI over HTTP, not port 9042, so don’t reach for it here.

Record every open port 9042, whether it accepted an unauthenticated cqlsh session, the keyspaces and tables you enumerated, and any credentials or hashes you recovered, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The single most important thing about port 9042 is that the biggest risk is not a CVE — it is the AllowAllAuthenticator no-auth default and the seeded cassandra / cassandra superuser. An open, unauthenticated Cassandra needs no exploit; the “attack” is simply connecting with cqlsh. Scope the actual vulnerabilities carefully, because Cassandra’s most famous remote-code-execution bugs live on the JMX management port (7199), not on the CQL native transport.

• CVE-2021-44521 — The one genuinely reachable over CQL/9042. In Apache Cassandra 3.0.x through 3.0.25, 3.11.x through 3.11.11, and 4.0.0–4.0.1, a cluster configured with scripted user-defined functions enabled (enable_user_defined_functions: true and enable_scripted_user_defined_functions: true) and UDF thread isolation turned off (enable_user_defined_functions_threads: false) lets a user who can create functions escape the Nashorn sandbox and execute arbitrary code on the host. CVSS 9.1 (Critical) per NVD; the Apache advisory rated it 8.4. It requires the create-function privilege — but on a no-auth instance, every connecting user has that privilege, chaining the default exposure straight into RCE. There is no Metasploit module; JFrog published the technique and a public proof-of-concept exists.

The two well-known Cassandra bugs below are verified and real, but they belong to the JMX interface on port 7199 — not the CQL port 9042 — so they are noted here for scope, not counted as 9042 vulnerabilities:

• CVE-2015-0225 — The default configuration in Cassandra 1.2.0–1.2.19, 2.0.0–2.0.13, and 2.1.0–2.1.3 bound an unauthenticated JMX/RMI interface to all network interfaces, allowing remote code execution via crafted RMI requests. CVSS 7.5. This is the classic Cassandra RCE, and it is entirely a JMX (7199) issue, not CQL.
• CVE-2020-13946 — In Cassandra before 2.1.22, 2.2.18, 3.0.22, 3.11.8, and 4.0-beta2, an attacker can manipulate the RMI registry to perform a man-in-the-middle attack and capture the credentials used to reach the JMX interface (remotely exploitable when paired with JRE bug CVE-2019-2684). CVSS 5.9 — again a JMX (7199) problem, not the native transport.

No wrong-service or fabricated CVEs are carried on this page: the CQL-reachable issue (CVE-2021-44521) is separated from the JMX-side bugs so neither is mislabeled as a port-9042 flaw, and no Exploit-DB ID is cited because none is verified for the UDF RCE.

Mitigation

• Enable authentication and authorization. Switch cassandra.yaml to authenticator: PasswordAuthenticator and authorizer: CassandraAuthorizer. This is the single highest-impact control for this port.
• Rotate the seeded superuser. Immediately ALTER ROLE cassandra WITH PASSWORD = '<strong-unique>', then create a separate named superuser and drop or demote the default cassandra account. Never leave cassandra / cassandra live.
• Bind to trusted interfaces and firewall the port. Set rpc_address/native_transport to a private address, and restrict 9042 — along with 7000/7001 (inter-node), 7199 (JMX), and 9160 (Thrift) — to application servers and cluster members via security groups or host firewalls. Nothing on the public internet should reach them.
• Lock down JMX. Enable JMX authentication and bind 7199 to localhost or a management network to neutralise the CVE-2015-0225 / CVE-2020-13946 class of issues.
• Disable Thrift and unused UDF scripting. Turn off the legacy Thrift RPC listener (9160) if nothing needs it, and leave scripted UDFs disabled — or keep UDF thread isolation on — to close CVE-2021-44521.
• Use TLS and patch. Enable client-to-node and node-to-node encryption, and keep the cluster on a supported, patched release.
• Enforce least privilege. Grant application roles only the keyspaces and permissions they need; reserve superuser rights for administrators.

Real-World Example

The cleanest illustration of the port-9042 risk isn’t a memory-corruption bug — it’s the default itself. Because Cassandra ships with AllowAllAuthenticator, internet-wide scans routinely turn up thousands of clusters that accept an unauthenticated cqlsh connection, and security researchers demonstrating the exposure need only connect and run DESCRIBE KEYSPACES to read (or wipe) production data — the same pattern that turned exposed MongoDB and Elasticsearch into mass data-breach and ransom targets. The 2022 disclosure of CVE-2021-44521 by JFrog sharpened the stakes: on a cluster running scripted UDFs with thread isolation disabled, the researchers chained the exact same “just connect” access into full remote code execution by defining a malicious function that escaped the Nashorn sandbox — turning a read-only data exposure into host takeover. The lesson of the port is consistent across both: the CQL native transport is designed for trusted clients, and every insecure default that reaches the open internet — no auth, an unrotated superuser, or an over-permissive UDF configuration — is a bigger practical risk than any obscure protocol flaw.

FAQ

What is port 9042 used for?

Port 9042 is the default port for the Apache Cassandra CQL native transport — the modern binary protocol that the cqlsh shell and application drivers use to query a Cassandra cluster. It replaced the older Thrift interface (port 9160) as the standard way clients talk to Cassandra, and it is also used by the API-compatible DataStax and ScyllaDB databases.

Is it dangerous to leave port 9042 open?

Yes, if the database is unauthenticated or reachable from untrusted networks. Cassandra defaults to AllowAllAuthenticator, so an exposed 9042 often means anyone who can connect gets full read and write to every keyspace with no credentials. Keep 9042 firewalled to trusted hosts and enable password authentication and authorization.

Does Cassandra require authentication by default?

No. The stock cassandra.yaml uses AllowAllAuthenticator and AllowAllAuthorizer, meaning no login is required and every operation is allowed. When you switch to PasswordAuthenticator, Cassandra seeds a superuser named cassandra with the password cassandra, which must be rotated immediately — it is one of the most common leftover credentials on exposed clusters.

What’s the difference between ports 9042, 9160, 7000, and 7199 on Cassandra?

9042 is the CQL native transport (the modern client port). 9160 is the deprecated Thrift RPC port that predates CQL. 7000 (and 7001 for TLS) carries inter-node gossip and replication between cluster members. 7199 is the JMX management interface — and, notably, the JMX side is where Cassandra’s classic remote-code-execution CVEs live, not the CQL port.

How do I check whether my Cassandra is exposed?

Try to connect without credentials: cqlsh <host> 9042 and run DESCRIBE KEYSPACES. If you reach a cqlsh> prompt and can list keyspaces without a password, authentication is off and the instance is exposed. nmap -sV -p 9042 <host> confirms the service remotely, and you should also check 7199, 7000, and 9160 for the rest of the cluster’s surface.

How do I secure port 9042?

Enable PasswordAuthenticator and CassandraAuthorizer, rotate the default cassandra superuser password (and replace the account), bind the native transport to a private address, firewall 9042/7000/7001/7199/9160 to application servers and cluster members, enable client and inter-node TLS, disable the legacy Thrift listener and unneeded scripted UDFs, and keep the cluster patched. Rescan with nmap -p 9042 <host> to confirm it is no longer openly reachable.

TL;DR

• Service: Apache Cassandra CQL native transport (also DataStax and ScyllaDB); legacy Thrift on 9160, inter-node on 7000/7001, JMX on 7199
• Default port: 9042/TCP
• Biggest risk: the AllowAllAuthenticator no-auth default plus the seeded cassandra / cassandra superuser — full read/write and dump of every keyspace with no exploit; and CVE-2021-44521 UDF sandbox-escape RCE when scripted UDFs are enabled with thread isolation off
• Mitigation: enable password auth and authorization, rotate the cassandra superuser, bind to private interfaces, firewall 9042/7000/7199/9160, enable TLS, disable Thrift and scripted UDFs, and patch

Related open-database and data-store ports worth reviewing alongside Cassandra: MongoDB on port 27017 and Elasticsearch on port 9200 (the sibling no-auth NoSQL exposure stories), Redis on port 6379, and MySQL on port 3306. Capture every finding in your pentest reporting tool as you go.