Bitwarden Helm Chart Vulnerability: What Admins Need to Know

Short answer: The Bitwarden Helm chart vulnerability affects self-hosted Bitwarden servers first installed with the bitwarden/self-host Helm chart before version 2.0.0 using the default generated identity certificate. That certificate's password is the public value map[].

Upgrading the chart does not fix it. Admins must check the password and rotate it manually.

Bitwarden told self-hosted customers on August 31, 2026, in its August 2026 product update for Business plans, to rotate their identity certificate if they first deployed with a Helm chart earlier than 2.0.0 and kept the default chart-generated certificate. Bitwarden describes the issue as "a possible vulnerability" and links to a rotation guide.

Key facts

• Announced: August 31, 2026, on the Bitwarden blog
• Affected: bitwarden/self-host Helm chart deployments first installed before chart 2.0.0 with the default generated certificate
• Fixed in: chart 2.0.0, released June 1, 2026; chart 2.3.0 and later block upgrades while the defective password is in place
• CVE and CVSS: none found on September 17, 2026; no GitHub security advisory is published for the repository
• Status: fixed for new installs; existing installs need manual rotation
• Primary source: Bitwarden blog and Bitwarden help article

What happened

Bitwarden's Identity Server signs access and refresh tokens with a PKCS#12 (.pfx) certificate. According to Bitwarden's rotation guide, Helm chart versions before 2.0.0 set the .pfx password to the fixed value map[] on every install. Because the value is public and identical everywhere, the guide says anyone who obtains identity.pfx "via a backup, snapshot, support bundle, or pod access" can decrypt it and recover the token-signing private key.

The defect was reported publicly in GitHub issue #118 on February 26, 2024, against chart version 2024.2.2. The self-host-2.0.0 release on June 1, 2026 lists "Fixed cert password gen", and Bitwarden closed the issue on June 25, 2026. The self-host-2.3.0 release on August 12, 2026 added a check that blocks install and upgrade when the vulnerable password is detected.

Bitwarden has not said whether any deployment was exploited.

Who is affected

According to Bitwarden's guide, rotation is required only when all three conditions are true:

• the server was deployed with the bitwarden/self-host Helm chart;
• the deployment was first installed on a chart version earlier than 2.0.0;
• it uses the default chart-generated certificate (secrets.identityCertificate.generate: true).

Bitwarden's notice covers Helm deployments only. It does not mention Bitwarden-hosted cloud accounts or other self-hosting methods.

Watch out: Older charts used calendar version numbers such as 2024.2.2, which look higher than 2.0.0 but predate it. Run Bitwarden's check command instead of comparing version numbers.

What to do now

These steps come from Bitwarden's Rotate a Helm Identity Certificate Password guide. You need kubectl rights to read, delete and create secrets, openssl, and your release name and namespace (helm list -A).

1. Check the stored password with the kubectl get secret <release>-identity-cert-password command in the guide. If it prints map[], you are affected.
2. Plan a short maintenance window. The guide says the identity and sso pods restart, so expect a brief interruption to sign-in and token refresh.
3. Export identity.pfx, generate a random password with openssl rand, and re-encrypt the certificate with it, as the guide shows.
4. Apply the rotated certificate and the new password to the two Kubernetes secrets, confirm the password secret no longer reads map[], and restart the identity and sso deployments.
5. Delete the local identity.pem and .pfx files, then confirm users can sign in.

Admin tip: Rotation re-encrypts the existing certificate, so issued access tokens stay valid and users are not signed out, according to the guide. Bitwarden notes that a replacement certificate would invalidate every issued token and sign out all users.

What we do not know yet

• Whether Bitwarden will publish a CVE or a GitHub security advisory. Vulnerability scanners that rely on CVE feeds will not flag this issue until one exists.
• Whether Bitwarden recommends a new certificate and key, rather than a new password, when old backups or snapshots of identity.pfx may have been exposed. The guide's rotation keeps the same private key, and it does not address this case.
• How many deployments are affected. Bitwarden has not published a number.

What this means for buyers

The defect is limited to one deployment method: self-hosting Bitwarden on Kubernetes with the Helm chart. Bitwarden fixed the chart for new installs in June 2026, added an upgrade block in August 2026, and published step-by-step rotation instructions.

Teams comparing hosting options should note that Helm self-hosting makes certificate and secret handling your team's job. Our Bitwarden review covers self-hosting requirements and the plans that include them.

Bottom line

If you run self-hosted Bitwarden from the Helm chart, run the password check today. If it returns map[], schedule the rotation in your next maintenance window, and restrict who can reach old backups of the identity certificate until Bitwarden says more. To see how self-hosting fits the wider market, start with the password management software hub, or use the shortlist builder if this defect has you reconsidering self-hosting altogether. For the encryption and incident record behind password manager safety generally, see are password managers safe.