Bitnami Cassandra Images Leave a Default Password Active: CVE-2026-47846, Update Now

A flaw has been found in the official container images of Apache Cassandra, the popular database that spreads large volumes of data across many servers: a well-known default password can be left active even after you think you replaced it. Published on June 18, 2026 as CVE-2026-47846, it is rated 9.8 out of 10 (critical), close to the maximum.

The problem is in the Bitnami build of the Cassandra image, widely used for shipping containers. Even when an administrator sets up their own user, the built-in cassandra account can quietly survive, letting anyone log in from the outside with it and read or write the entire database. It was disclosed in the vendor's security advisory, and fixed versions are out.

What is Cassandra, and why is the Bitnami image so widely used?

Apache Cassandra is a "distributed database" that splits data across multiple servers when it no longer fits on a single machine. Companies worldwide use it for ever-growing data such as social media post histories, the steady stream of records sent by IoT devices, and access logs. Data is exchanged using CQL (Cassandra's query language), and it connects to the outside over communication port 9042.

What is affected here is the container image that packages Cassandra into a ready-to-run box. A container is a small portable box that bundles an app with the parts it needs, used together with Docker and Kubernetes (a platform that manages large numbers of containers). Bitnami is a well-known provider that has distributed many such images for free, now run by Broadcom's VMware. Because its images are downloaded so heavily and used everywhere from test setups to production, a flaw in even a single image has a wide blast radius.

Cases of "the convenient official building block itself having a hole" have been frequent lately. On this site we have covered a container-escape flaw that broke isolation and was actually exploited, and a migration tool that leaked administrator credentials and Kubernetes keys. The more widely a foundational part is used, the more one mistake spreads across real-world sites.

Who logs in with this default account, and what do they walk off with?

"A default password was just left behind" may sound like a minor oversight. But from an attacker's point of view, CVE-2026-47846 is an unlocked back door left wide open. Picturing exactly who comes to try that door, without the jargon, makes it clear why this cannot be left alone.

Those who come in are attackers who roam the internet mechanically trying classic ID-and-password pairs like "cassandra," "admin," and "root"; theft rings that steal and resell corporate data; ransomware operators who encrypt your data and demand payment; and people who blend in by posing as a competitor or a partner. What they get is the names and email addresses of the users stored in Cassandra, order and payment histories, the sensor readings sent by devices, the behavioral trail left in access logs, and the administrator power to rewrite or delete the entire database. If the default account survives and port 9042 is open to the outside, they need no trickery at all: typing a known passphrase puts them in front of this mountain of data.

Technically, an attacker uses internet-wide scanning tools to find servers with port 9042 open and tries to log in with the universally known default pair "cassandra / cassandra." On an image with this flaw, even if the administrator created a new user and believed the default account was gone, that default account survives, so the login succeeds. Once inside, the attacker can read and rewrite all data, plant other data to use as a stepping stone, or encrypt the stored data to make it unusable, carrying the attack to its next stage.

The "9.8 severity" figure is only a gauge of technical seriousness. For anyone who entrusts business data to Cassandra, what is truly lost is the pile of personal data handed over by customers, and the trust and compensation owed when it leaks. What makes this flaw frightening is that it needs no hard preparation and is reachable with a single known passphrase.

What actually happens with CVE-2026-47846

The core of the flaw is a failure to delete the default account. Technically it is classified as use of hard-coded default credentials (CWE-798, the problem of a fixed, pre-embedded ID and password being left in place). By default Cassandra has an administrator account named "cassandra" with the password "cassandra." Since this value is known worldwide, the iron rule in production is to always replace it with a different account.

In the Bitnami image, specifying your own user name via the environment variable CASSANDRA_USER at startup makes the initialization script create a new administrator account. However, according to the vendor advisory, under certain conditions the script failed to drop the built-in "cassandra" account after creating the new one. So even though the administrator thinks they replaced it with their own account, the default passphrase remains as a back door.

When this back door is abused, an attacker who can reach port 9042 authenticates with the default "cassandra / cassandra" and acts as an administrator with full read and write access to all keyspaces (groups of data) and tables. The NVD (the U.S. government's vulnerability database) rates it at the top tier of 9.8 (critical), noting it requires no prior privileges and no user interaction and can compromise confidentiality, integrity, and availability over the network.

In the same "database gets operated without permission" family, we have covered the Spring AI flaw that lets a database be manipulated without logging in and the Langroid case where AI-written SQL hijacks a database. This time the hole is not in the app's logic but in how the distributed image handles its initial setup. As of disclosure, there are no reports of actual exploitation.

Am I affected, and which versions are at risk?

You are affected if you use the Bitnami Cassandra container image and are still on an old version. Check your version against the table below.

Note that this is specific to "the image distributed by Bitnami" and is not a bug in Apache Cassandra itself. If you build Cassandra from scratch you are not affected, but even then it is wise to confirm separately that you have not left the default account in place.

How should I respond?

The basic response is to update the Bitnami Cassandra image to a fixed version. Replace it with the fixed version of your branch from the table above (4.0.20-photon-5-r7, 4.1.11-photon-5-r7, or 5.0.8-photon-5-r4 / 5.0.8-debian-12-r3) or later. Steps are available in the official repository and the security advisory GHSA-8q3j-37vg-8fc2.

If you cannot update right away, the advisory lists two stopgaps. One is to run DROP USER 'cassandra'; via CQL to manually delete the leftover default account. The other is to restrict outside access to port 9042 using a firewall or a Kubernetes NetworkPolicy (a setting that limits who is allowed to communicate). Both are temporary measures; the real fix is updating to a patched version.

If you cannot fully track which container images and versions you run, a tool like an open-source vulnerability scanner that automatically flags risky versions from a list of the parts you use helps prevent oversights. Bitnami also publishes vulnerability information in a dedicated database, so it is worth checking the latest status of the images you run on a regular basis.

Why is a "leftover default password" this dangerous?

Default-password issues are frightening because the attacker needs to research nothing in advance. A product's default account and password are public, so attackers simply add them to a brute-force list and try them mechanically against servers worldwide. There is no need to find a hole or to deceive a user. That is exactly why such leftover defaults tend to swing to the top severity.

Convenient container images sell themselves on being "ready to use the moment you run them," which means how they handle initial setup directly determines their safety. A case like this one, where a back door remains even though the user correctly configured their own account, is not the user's fault but a flaw in what was distributed. When you build on foundational parts, subscribing to the provider's security notices and pulling in fixes promptly is the strongest defense.

Frequently asked questions

Q. Am I safe if I properly set up my own account?

A. No. The point of this flaw is that even after you set up your own account, the built-in "cassandra" account can be left undeleted. A back door may remain despite your configuration, so you need to update to a fixed version or manually delete the default account.

Q. Is this irrelevant if I use Apache Cassandra itself?

A. This vulnerability is specific to the container image distributed by Bitnami. That said, Cassandra ships with a default "cassandra / cassandra" administrator account, so even if you build it yourself, it is wise to confirm you have not left that default account in place.

Q. What should I do if I can't update right away?

A. Delete the default account via CQL (DROP USER 'cassandra';), or restrict outside access to port 9042 with a firewall or NetworkPolicy. Both are stopgaps; ultimately you need to update to a fixed version.

Summary

CVE-2026-47846 is a flaw in the Bitnami build of the container image for the distributed database Apache Cassandra, where the built-in "cassandra" account can be left undeleted. Rated a high 9.8 (critical), it can let an attacker who can reach port 9042 read and write the entire database as administrator using nothing more than a universally known default passphrase.

The affected images are old 4.0.x, 4.1.x, and 5.0.x builds, each with a fixed version released. If you cannot update right away, manually deleting the default account and restricting access to port 9042 are stopgaps. The more convenient an official part is, the more its handling of initial setup decides its safety. Subscribing to the provider's security notices and pulling in fixes promptly is the best preparation.

References

• ▸ NVD - CVE-2026-47846 Detail
• ▸ Bitnami Containers Security Advisory - GHSA-8q3j-37vg-8fc2
• ▸ CVE.org - CVE-2026-47846 Record
• ▸ Bitnami Vulnerability Database
• ▸ Apache Cassandra Official Site