EUVD-2026-37932Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Default cassandra:cassandra credentials remain valid over the network CQL protocol, granting unauthenticated superuser access with full read, write, and destructive capability.
Primary rating from Vendor (vmware).
CVSS VectorVendor: vmware
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
3DescriptionCVE.org
Bitnami Cassandra container images are affected by a retained default superuser vulnerability. When a custom administrator account is configured via the CASSANDRA_USER environment variable, the container initialization script creates the new superuser account but fails to drop the built-in cassandra account in certain scenarios. This leaves the default cassandra:cassandra superuser active as an unintended access path.
Affected versions - Container image: 4.0.x prior to 4.0.20-photon-5-r7; 4.1.x prior to 4.1.11-photon-5-r7; 5.0.x prior to 5.0.8-photon-5-r4 / 5.0.8-debian-12-r3.
AnalysisAI
Authentication bypass in Bitnami Cassandra container images (4.0.x, 4.1.x, 5.0.x lines) allows remote attackers to access the database as superuser using the built-in cassandra:cassandra credentials, even when operators configure a custom administrator via CASSANDRA_USER. The container init script provisions the new superuser but, in certain scenarios, fails to drop the default account, leaving an unintended privileged login path. No public exploit identified at time of analysis, but the trivially guessable default credentials make discovery and abuse straightforward once the CQL port is reachable.
Technical ContextAI
Bitnami's Cassandra images bundle a first-boot initialization script that bootstraps the Cassandra cluster, including creating administrator roles based on environment variables such as CASSANDRA_USER and CASSANDRA_PASSWORD. Apache Cassandra ships with a built-in 'cassandra' superuser (password 'cassandra') used for initial PasswordAuthenticator bootstrapping; correct hardening procedure is to create a replacement superuser and then DROP ROLE cassandra (or ALTER it to a non-superuser with a strong password). The flaw, classified under CWE-798 (Use of Hard-coded Credentials), is that the Bitnami init logic does not consistently execute that final drop/demotion step when a custom admin is provided, so the well-known cassandra:cassandra account remains a valid superuser. Affected artifacts are identified by cpe:2.3:a:bitnami:bitnami/cassandra:*, covering the Photon- and Debian-based variants of the 4.0, 4.1, and 5.0 image streams.
RemediationAI
Patch available per vendor advisory: upgrade to Bitnami Cassandra image tags 4.0.20-photon-5-r7, 4.1.11-photon-5-r7, 5.0.8-photon-5-r4, or 5.0.8-debian-12-r3 (or later), per https://github.com/bitnami/containers/security/advisories/GHSA-8q3j-37vg-8fc2. Until upgrade is possible, operators should connect to each cluster with cqlsh and explicitly run ALTER ROLE cassandra WITH PASSWORD = '<long random>' AND SUPERUSER = false, or DROP ROLE cassandra after confirming the replacement superuser works - this directly removes the unintended access path with no functional side effects beyond preventing legacy scripts that still use the default credential from logging in. As a network-layer compensating control, restrict TCP/9042 (CQL) and 7000/7001 (internode) to known application subnets via NetworkPolicy, security groups, or service mesh policy; the trade-off is that misconfigured client pods will lose connectivity, so stage the change. Audit existing clusters with LIST ROLES to confirm whether the 'cassandra' role is still present and is_superuser=True before declaring an environment clean.
Same weakness CWE-798 – Use of Hard-coded Credentials
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today