マリウス . I Do Not Recommend Bitwarden

Almost four years ago I published a guide on how to
run your own LastPass on hardened OpenBSD, in which I explained how
to set up an OpenBSD instance, either as a cloud instance or as a Raspberry Pi
bare metal installation, that would host Vaultwarden as a backend
for the Bitwarden client applications. After having used a similar
approach for myself for several years now, I came to the conclusion that I do
not recommend the use of Bitwarden any longer. Let me explain.

Freemium dual-license password manager

Wikipedia describes Bitwarden as _a freemium open-source password
management service that is used to store sensitive information […] owned and
developed by Bitwarden, Inc., and that is now almost ten years old. The
company behind the software is not only developing the Bitwarden server, as
well as client applications for most platforms, but it is also offering a SaaS
product for users who don’t want to put up with hosting this unwieldy beast on
their own. More on this in just a moment.

Bitwarden’s pricing for their hosted offering is similar to their competitors’
offerings, albeit with differences in terms of functionality. Regardless of
whether one picks their hosted offering or decides to self-host, however, the
client applications remain the same.

Since 2022, Bitwarden is also
backed by $100M of PSG growth equity, joined by Battery Ventures.
A password manager that wants to remain open-source is one thing, but the same
password manager with an investor on its board that needs to see a return on
$100M is another. Without wanting to sound overly cynical, this is usually the
point in time in which the rent-seeking begins and the product slowly
shifts from serving its users to serving its investors.

Unwieldy beast

If you decide to self-host Bitwarden, however, you will relatively quickly
find yourself in what I would describe as enterprise software hell. The
standard Bitwarden server deployment is a heavy-weight C# backend that ships
with MSSQL Express and won’t work with more Linux-native databases like
PostgreSQL or MariaDB. Depending on the size of the deployment and the
requirements with regard to high availability, you might want to utilize
Kubernetes, which in turn adds additional overhead and complexity.

Because of this, many smaller to medium-sized deployments prefer to look into
Vaultwarden instead, which is an unofficial Bitwarden-compatible
server written in Rust™. The simple and lightweight nature of
Vaultwarden compared to the official Bitwarden server makes such a big
difference for administrators that the unofficial server project has seemingly
three times the stargazers on GitHub as compared to Bitwarden’s official
implementation. This should make you think, especially as a series B-funded
company with $100M, whether your (technical) users appreciate the current
direction your software stack is heading towards, or whether you might want to
look into bringing the people that built a vastly more successful backend
implementation on-board to optimize and accelerate your official stack.

And surely that’s what Bitwarden decided to do, right?

Bitwarden lite

Sadly, however, it seems that Bitwarden’s NIH syndrome was too strong
to simply take over Vaultwarden as an official project. Instead, the company
seemingly hired the main developer of the Vaultwarden project and decided to
publish a “lighter” version of their existing backend dubbed Bitwarden
unified lite, which is still a service built on Microsoft’s .NET, and
which still appears to require more than three times the RAM a Vaultwarden
instance usually consumes.

Regarding the open-source part of Bitwarden, things have been getting
murkier over the past year or so. In late 2024, users started noticing
that a new dependency, @bitwarden/sdk-internal, had been pulled into the
clients. Its license read:

You may not use this SDK to develop applications for use with software other
than Bitwarden (including non-compatible implementations of Bitwarden) or to
develop another SDK.

For a product that prides itself on being open-source, this is a fairly
significant plot twist. After considerable backlash in the community,
however, Bitwarden called it a “packaging bug” and eventually
relicensed the SDK under GPLv3. Technically, the issue is resolved.
Philosophically, however, this episode tells you all you need to know about
where Bitwarden is heading: The freeware parts are bait, the
actual product is the SaaS subscription, and the community is there to
contribute issues and translations as long as it doesn’t cost the company
anything.

The real culprit

Setting aside the backend, however, the real culprit with regard to Bitwarden
are the client applications. Advertised functions do not work as expected, basic
features are non-existent (after ten years!) and the user interface is poor to
put it mildly, especially when compared to equally priced alternatives. And
don’t get me wrong, if Bitwarden was purely a FOSS-effort and not funded by
venture capital all these flaws could be brushed aside because, after all, it
would be a community effort. However, Bitwarden isn’t a community effort,
which is reflected very noticeably in the bureaucratic processes they drowned
the community in, but more on this in a moment.

Migrating vaults

About a year ago, I supported someone who tried to switch from a competitor to
Bitwarden under the thought of rather supporting open-source software with a
yearly subscription than some proprietary platform that one has no insights
into. Part of the migration was naturally importing existing vaults from the
previous password manager into the new Bitwarden account. As can be seen in
my bug report on GitHub, however, this went sideways very quickly,
and resulted in at least one vault requiring significant technical workarounds
for the import to work.

The response from what sounded like an official Bitwarden employee left me
frankly stunned. Despite the migration/import feature being advertised in
multiple places throughout Bitwarden’s marketing materials and documentation,
and despite dozens of users having already complained about the exact same
issue, Bitwarden simply decided to ignore the issue report and instead
requested opening another likely dead-ended discussion in their community forum.

This level of corporate bureaucracy is not at all what open-source software
should look and feel like, and it is definitely completely unjustified for a
feature that is being advertised on both the open-source software, as well as
the paid product, but that simply does not work as advertised.

Similarly, many other issues are funneled through this process of community
discussions, which more often than not turn out as not much more than lengthy
threads of pointless back-and-forth, and almost never materialize in actual
implementations.

Moving items between vaults

Migration pain is not limited to the initial import. Even when you’re already
inside Bitwarden and simply want to shuffle entries between an
organization vault and your individual vault, or the other way around, there
is, to this day, no proper “move the selected items to …” feature. For a
handful of logins you can clone/edit each one manually, but anyone who has ever
tried this with a few hundred items (say, after cleaning up a collection,
leaving a company, or consolidating several organizations) knows that this
quickly becomes a carpal tunnel-inducing exercise.

The official workaround that Bitwarden support and
community threads recommend is to export the source vault as
unencrypted JSON, edit the file, and then re-import it into the destination
vault. Setting aside the obvious security footgun of having 500+ credentials
sitting in plain text in ~/Downloads, or worse, a directory that’s silently
synced to the cloud (think Dropbox, OneDrive, iCloud, …) while you
figure out where to put them, the process happily loses a non-trivial amount of
data along the way:

[…] if there are file attachments in any of your vault items, then these
will not be included in the export […] the export will not include items in
the Trash, or any password histories or timestamps.

For any organization that relies on attachments (e.g. SSH key files, licence
keys, recovery codes as images) or on password history for compliance/audit
reasons, this is plainly unacceptable. For a product whose entire job is to be
the source of truth for your credentials, the complete absence of a “move these
500 items to that vault, keep everything intact, click OK” button in year ten
of its existence speaks volumes about where Bitwarden’s engineering priorities
lie.

Client updates breaking things

Another example concerns client updates. It appears that Bitwarden pushes new
updates to their clients that can lead to vaults becoming inaccessible (on the
client side) at random, without any heads-up to the users. I personally
encountered this issue while travelling.

When I had my phone plugged-in overnight, F-Droid decided it’s a good time
to update a few apps, one of which was Bitwarden. The next morning I had to
log into my banking and when I opened the Bitwarden app on my phone I was
unable to access my vault. It took some time to
figure out what was going on (via Vaultwarden), and I was
lucky that I had my UPDC (which hosts my Bitwarden backend) with
me, as otherwise I could have ended up in a pretty bad situation with my whole
vault being unavailable.

The sheer irresponsibility with which Bitwarden appears to push what looks
like breaking protocol changes between the clients and the backend is
frightening. As someone who relies heavily on my password manager to work in
offline mode, this experience taught me that Bitwarden cannot be trusted. From
that moment on, I disabled automatic updates for the Bitwarden clients and
exported a current snapshot of all passwords to a local backup in
KeePassChi/KeePassXC/KeePassDX.

User experience

Aside from the aforementioned technical details, Bitwarden is (and has always
been) one of the subjectively worst applications on my phones and my desktop in
terms of user interface. The UI/UX is in fact so horrible, that even after years
of use I still dread opening the ungoogled-chromium extension, let alone any
of the desktop and mobile apps.

Aside from the fact that building the Electron-based desktop app from source
is a huge PITA and that the pre-built Flatpaks are
not working properly on Wayland, one more general, major issue
that I’m experiencing with the Bitwarden client applications (and extensions)
is the fact that while they clearly support offline use, they’re not
intentionally built for it. Hence, whenever I open the mobile app or the browser
extension, there’s a noticeable delay that sometimes takes literal seconds or
even minutes, in which the client application seemingly tries to reach the
backend, which often isn’t around (because I’m not hosting my Bitwarden
backend on the open internet). While this sounds like a nitpick, it truly slows
down things whenever one has to unlock Bitwarden (which is almost always, as I
do not trust especially the browser extension to remain unlocked all the time).
Sadly, there seems to be no way to turn off syncing when unlocking the vault to
prevent the clients from waiting unnecessarily.

Another example of a bad user experience is the logins overview (titled
Vault). Whenever I am on a website (in my desktop browser) and I would like
Bitwarden to fill the login form, I tend to click the extension’s icon in the
toolbar and then click the entry in the list. This has been how all other
password manager UIs that I have used in the past have worked; Not Bitwarden,
though. There, you need to click the small Fill button on the right side of
the list item. If you click the big list item itself, which is highlighted on
mouse-over, you simply open that item to show its details. Instead of allowing
the user to click the big UI element (which is the whole list item), Bitwarden
forces them to click a significantly smaller, harder to hit UI element (a button
on top of a clickable list item). As with the syncing feature, there’s also no
way to flip this behavior, so that clicking the list item would fill in the
form, while clicking the tiny button would open the item’s details page.

CLI

Speaking about lists, the Bitwarden CLI has an equally bad user interface. For
example, the list command of the bw tool will unexpectedly output
every detail of every item, including passwords and TOTP codes, without the need
for an additional e.g. --show-credentials flag. There’s no way that reasonable
engineers looked at this and said “Yep, that’s how we do things, because we
cannot imagine a single situation in which anyone might mistakenly pipe
bw list to some place and unintentionally expose all their credentials”.

Also, can we take a step back and talk about the fact that the Bitwarden CLI
is a terminal tool built in TypeScript? Not only because it requires a metric
ton of runtime and dependencies, but also because JavaScript isn’t exactly the
stack anymore that you’d run carefree on your continuous integration
environments. “Why?”, you ask? Hold my beer…

Security track record

A password manager has, essentially, one job: Keeping the user safe, by
keeping their credentials safe. For a product that has been around since 2016,
Bitwarden has accumulated a surprisingly long list of incidents in which it at
least partially failed at exactly that task. And no, I’m not talking about
theoretical vulnerabilities, I’m talking about things that actually shipped
to production.

2023: KDF

In January 2023, shortly after the LastPass breach had the entire industry
questioning the real-world strength of cloud-hosted password vaults, security
researcher Wladimir Palant published an analysis showing that
Bitwarden’s advertised 200,001 PBKDF2 iterations were, in practice, closer
to 100,000. The reason was that the additional server-side iterations were
only applied to the master password hash used for login, but not to the
encryption key protecting the vault data. An attacker with access to a leaked
vault could therefore bypass the server entirely and was left with the same
effective security as with LastPass.

Additionally, the default client-side iteration count was still at 100,000,
below OWASP recommendations at the time, and a concern that had been
raised as far back as 2020. Bitwarden eventually raised the default
to 600,000 and added Argon2 support, but (mirroring LastPass’ earlier
mistakes) the change initially applied only to new accounts, leaving existing
users responsible for manually updating their own KDF settings.

2023: Windows Hello bypass

Still in 2023, RedTeam Pentesting disclosed “Bitwarden Heist”
(CVE-2023-27706), a vulnerability in the Windows desktop client
that allowed attackers with domain-administrator access to extract the vault
decryption key from the local DPAPI storage without ever prompting Windows
Hello or the master password. In the words of the researchers:

Any process running as the low-privileged user session can simply ask DPAPI
for the credentials to unlock the vault, no questions asked.

The fix eventually shipped in version 2023.4.0, months after initial
disclosure.

2023: Cross-origin autofill

Also in 2023, CVE-2023-27974 was disclosed. The vulnerability was
about the Bitwarden browser extension, which happily offered to fill
credentials into cross-domain iframes embedded on trusted pages, as long as
the base domain matched. Meaning, if trusted.com embedded an iframe from
attacker.trusted.com (e.g. on a subdomain controlled by a third party),
credentials could be stolen. Bitwarden’s response was that iframes “must be
handled this way for compatibility reasons”, and that “Auto-fill on page
load” was not enabled by default. Small comfort if you did enable it.

2025: DOM-based clickjacking

Fast-forward to August 2025, when security researcher Marek Tóth
publicly disclosed a class of DOM-based clickjacking attacks that could trick
the Bitwarden browser extension into autofilling credit card details and
personal information after a single click on a malicious page. The
vulnerability had been reported four months earlier, in April 2025, but was
classified by Bitwarden as “moderate severity” and was not patched until
version 2025.8.2, shipped on the very day the researcher’s embargo expired.

2026: Shai-Hulud

And then, a few days before I started writing this post, news broke that the
official Bitwarden CLI client (2026.4.0)
was compromised in the ongoing Checkmarx supply chain attack:

The affected package version appears to be @bitwarden/cli2026.4.0, and the
malicious code was published in bw1.js, a file included in the package
contents. The attack appears to have leveraged a compromised GitHub Action
in Bitwarden’s CI/CD pipeline, consistent with the pattern seen across other
affected repositories in this campaign.

…

Organizations that installed the malicious Bitwarden npm package should
treat this incident as a credential exposure and CI/CD compromise event.

The payload downloaded the Bun runtime, decrypted a second-stage
Shai-Hulud worm and started harvesting GitHub and npm tokens, SSH keys,
shell history, AWS, GCP, Azure credentials, GitHub Actions secrets, and
even MCP configuration files used by AI tooling. The data was then exfiltrated
by auto-creating a public repository on the victim’s own GitHub account and
uploading the stolen credentials there. Bitwarden’s npm distribution
pipeline stayed compromised for approximately 19 hours and 334 developers had
enough time to pull the malicious package before it was caught.

Bitwarden’s official statement emphasised that no end-user vault data was
accessed, which is technically true and entirely beside the point. Everyone
running bw in a CI pipeline just handed the attackers whatever else happened
to live on that machine. For a company whose one job is keeping secrets safe,
distributing an actively malicious CLI through its official channels is not a
great look. It also ties back nicely to the earlier rant about shipping a
password manager CLI as a Node package. Had bw been a single
statically-linked binary in Go or Rust (as most of the ecosystem has moved
towards) the npm-shaped blast radius simply wouldn’t exist in that form. And
while supply-chain attacks within the Go and Rust ecosystems are on the rise as
well, the barriers for successful attacks are still higher.

The way forward

As this post is not an ad-driven hit-piece by any of Bitwarden’s competitors,
you won’t be reading anything along the lines of “… switch to now and get 50% off your first year with promo code SWORDFISH”

.
Instead, I will describe the approach that I’m taking moving forward, which
might be something that you, as an equally frustrated long-time Bitwarden
user, might be interested in exploring as well.

Divide and conquer

Over the past years, I came to the conclusion that there’s no single password
manager that will work perfectly for every use case and setup. For example, in
my personal life, I do not need the ability to share vaults or individual
passwords with other people. In my professional life, however, that is a fairly
common occurrence. Similarly, the login credentials for bank accounts or
insurance portals do not need to be available through a CLI tool, but they have
to be available across multiple devices. Secrets for cloud storage or SSH
private keys for deployments, however, don’t need to sync to any of my
phones, but they do need to be accessible from a command-line tool that
can be invoked programmatically.

With these requirements in mind, it only makes sense to think of a way to better
compartmentalize each set of credentials, rather than trying to find a single
software or platform that can kill ten birds with one stone. Also, looking at it
from a security perspective, it makes total sense to split up these password
groups into different softwares and services in order to minimize the impact
that a data breach might have.

Generally, the approach that I came up with splits my credentials into the
following groups:

• A: Credentials for professional/client projects (think platform logins,
  etc.)
• B: Credentials for accounts containing PII (think bank accounts, online
  shops, etc.)
• C: Credentials for accounts that do not contain PII (think accounts on
  internet forums, online platforms, etc.)
• D: Credentials for infrastructure (think server logins, SSH keys)
• E: One-off credentials (think API keys, tokens, etc.)

Group A: Professional/client projects

For group A I’m going with a SaaS password manager that offers proper
vault sharing, integrates with the tools clients actually use (SSO, browser
extensions on corporate machines, audit logs), and takes the hosting burden off
my plate. The platform is proprietary, which I would normally not be thrilled
about, but given that the scope of this group is client work only, I’m
accepting the trade-off.

Group B: Accounts containing PII

For group B, the rationale is a bit counter-intuitive at first. The accounts
tied to these credentials already contain personal information like name,
address, date of birth, maybe payment details, which is regularly leaked by the
very same services anyway, as a quick look at Have I Been Pwned
confirms. A breach of the password manager itself would therefore not
meaningfully expand the attacker’s knowledge. With TOTP and Passkeys in place,
it frankly doesn’t even matter anymore at this point. What does matter here is
cross-device availability, realiability and offline capabilities. I’m using a
second, separate cloud-based password manager for this group, from a different
vendor, with a different master password and different recovery mechanisms, so
that a compromise of group A doesn’t automatically compromise group B and
vice-versa. As I will be running their mobile app on at least one
GrapheneOS device, I prefer a solution that doesn’t depend on
Google Play Services and ideally offers an open-source/source-available
client.

Group C: Accounts without PII

Group C covers all the accounts I have on internet forums, websites,
privacy-respecting services, and anything that doesn’t hold PII. For these, I
don’t need, nor do I want, a cloud service. I’m using
KeePassChi/KeePassXC/KeePassDX with the database
file sitting in a folder that is being synced across my devices via
Syncthing, which is an approach I have
already written about in the past. The .kdbx file is itself
encrypted, which means that even if Syncthing were compromised (and the
attacker somehow got their hands on the file), they would still need to break
the KeePassChi/KeePassXC encryption to get anything useful out of it. On
mobile, KeePassDX on Android reads the same file without fuss.

Group D: Infrastructure

For group D, I’m using a mixed approach of storing personal credentials
using the same approach taken in group C, and credentials that are actually
used by scripts, CI jobs, and remote servers, using HashiCorp Vault,
which is the same one I was already running for PKI in my OpenBSD setup.
Vault is a bit of an overkill for a single user, but it gives me proper access
policies, token-based authentication for automated agents, short-lived
credentials for things that support it, and audit logs. Having that said, I’m
looking into Infisical.

Group E: One-off credentials

For group E, the API keys, personal access tokens, and random secrets that I
only ever use from the command line, I’ve settled on the venerable
pass utility. It stores each secret as an individual
GPG-encrypted file in a Git repository, which is conceptually simple, easy to
audit, and cooperates perfectly with shell scripts and my
dotfiles. The Git repository lives on my own infrastructure, not
on GitHub, and it’s only synced manually when I actually need to access it
from a different machine.

Bottom line

After several years of self-hosting Bitwarden, I’ve come to the conclusion
that the product has drifted further and further away from what I originally
signed up for. The enterprise-first architecture that barely fits on a
Raspberry Pi, the half-hearted attempt at a “lighter” backend, the SDK
licensing situation, the slow pace at which features are being addressed, the
avoidable UX paper-cuts that haven’t been fixed in years, and finally the string
of security issues that shouldn’t have shipped in the first place, all paint a
picture that I find hard to reconcile with the “open-source password manager
for everyone” narrative.

I’m not suggesting that the alternatives are universally better or free of their
own issues, because password managers are simply hard, and every player in
this space has its fair share of skeletons. What I am suggesting is that you
take a hard look at how much trust you are placing into a single piece of
software for all of your credentials, and whether that bet is still the right
one, which for me, it no longer was.