Bitnami Cassandra EUVD-2026-37932

Requires a Bitnami Cassandra container deployed from a vulnerable image tag where the operator set the CASSANDRA_USER environment variable to provision a custom administrator - the bug specifically affects this code path, so images run with the stock 'cassandra' admin or without custom user vars are not in scope of this CVE (though they retain the default account by design). Exploitation further requires network reachability to the CQL native protocol port (TCP/9042, or whatever the deployment exposes) and that PasswordAuthenticator is the configured authenticator. The description's qualifier 'in certain scenarios' indicates the failure to drop the default role is conditional on the init script's branching, so not every CASSANDRA_USER deployment is guaranteed vulnerable - defenders should verify by listing roles. No user interaction, MFA, client certificate, or non-default tuning is needed once those conditions are met.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H = 9.8) is plausible for any deployment that exposes the CQL native protocol (TCP/9042) to attackers, since the default credentials are universally known and authentication is the only barrier - meaning AC:L and PR:N are well justified. EPSS and CISA KEV status were not provided in the input, and no POC or active-exploitation reporting is referenced, so this is best treated as a high-severity latent backdoor rather than a confirmed in-the-wild campaign. Real-world exposure depends heavily on network reachability: production clusters typically keep 9042 internal, which lowers practical risk, but cloud-managed Cassandra-on-Kubernetes installs that expose the service (or sit alongside compromised pods) effectively grant superuser access to anyone who tries the default login. Note the conflict worth flagging: the description says the issue triggers 'in certain scenarios' when CASSANDRA_USER is set, so not every custom-admin deployment is necessarily vulnerable - defenders should verify role membership rather than assume.

An attacker who can reach the CQL port (9042) of a Bitnami-deployed Cassandra cluster - for example via an exposed Kubernetes Service, a misconfigured cloud LoadBalancer, or lateral movement from a compromised application pod - simply runs cqlsh -u cassandra -p cassandra <host> and obtains superuser access despite the operator believing only their custom CASSANDRA_USER account exists. From that session the attacker can read or modify every keyspace, create new superuser roles for persistence, or DROP KEYSPACE for destructive impact. No public exploit identified at time of analysis, but exploitation requires no tooling beyond the standard cqlsh client.