Meanwhile, Bitwarden themselves state that end users were almost never affected: https://community.bitwarden.com/t/bitwarden-statement-on-che...
You had to install the CLI through NPM at a very short time frame for it to be affected. If you did get infected, you have to assume all secrets on your computer were accessed and that any executable file you had write access to may be backdoored.
I promptly removed the bw cli programme after that, and I definitely won't be installing it again.
I use ghostty if it matters.
They probably caused it themselves, somehow, and then blamed bitwarden. Note in the original comment they aren't even entirely sure what the command was, and they weren't familiar with it or they wouldn't have been surprised by its output... so how can they be sure what else they did between that command and the weechat thing?
If the terminal or tmux fed terminal history into weechat, that's also not bw's problem.
There is a time and place for where it makes sense and a password manager CLI written in TypeScript importing hundreds of third-party packages is a direct red flag. It is a frequent occurrence.
We have seen it happen with Axios which is one of the biggest supply chain attacks on the Javascript / Typescript ecosystem and it makes no sense to build sensitive tools with that.
The full strength of the SOP applies by default. CORS is an insecurity feature that relaxes the SOP. Unless you need to relax the SOP, you shouldn't be enabling CORS, meaning you shouldn't be sending an Access-Control-Allow-Origin header at all.
If your front-end at www.example.com makes calls to api.example.com, then it's simple enough to just add www.example.com to CORS.
I found the default bwcli clunky and unacceptable, and it's why I don't use it, even though I still have a BitWarden subscription.
Edit: The CLI itself apparently does not, which will have limited the damage a bit, but if it's installed as a snap, it might. Incidents like this should hopefully cause a rollback of this dumb system of forcefully and frequently updating people's software without explicit consent.
Also the time range provided in https://community.bitwarden.com/t/bitwarden-statement-on-che... can help with knowing if you were at risk. I only used the CLI once in the morning yesterday (ET), so I might not have been affected?
Assuming you had it already installed, you would be safe.
Quite bizarre to think much much of my well-being depends on those secrets staying secret.
I have 1Password configured to require password to unlock once per 24 hours. Rest of the time I have it running in the background or unlock it with TouchID (on the MacBook Pro) or FaceID (on the iPhone).
It also helps that I don’t really sign into a ton of services all the time. Mostly I log into HN, and GitHub, and a couple of others. A lot of my usage of 1Password is also centered around other kinds of passwords, like passwords that I use to protect some SSH keys, and passwords for the disk encryption of external hard drives, etc.
Also a great way of missing out on one of the best protections of password managers; completely eliminating phishing even without requiring thinking. And yes, still requires you to avoid manually copy-pasting without thinking when it doesn't work, but so much better than the current approach you're taking, which basically offers 0 protection against phishing.
Rouge browser extensions for example could redirect you away from the bank website (if the bank website has poor security) when you go there, so even if you use the URL from the password manager, if you don't use the autofill feature, you can still get phished. And if the autofill doesn't show, and you mindlessly copy-paste, you'd still get phished. It's really the autofill that protects you here, not the URL in the password manager.
Concretely, I think for redirect browser extension users I'd use "webRequest" permission, while for in page access you'd need a content-script for specific pages, so in practice they differ in what the extension gets access to.
Likewise I have links in the bookmarks bar on desktop.
I use these links to navigate to the main sites I use. And log in from there.
I don’t really need to think that way either.
But I agree that eliminating the possibility all-together is a nice benefit of using the browser integration, that I am missing out on by not using it.
If you're used to the clunkier workflow of copy-pasting from a separate app, then it's much easier to absent-mindedly repeat it for a not-quite-right url.
That password cannot be cracked because it will always display as ** for anyone else.
My password is *****. See? It shows as asterisks so it's totally safe to share. Try it!
... Scnr •́ ‿ , •̀
~/.npmrc:
min-release-age=7 (npm 11.10+)
~/Library/Preferences/pnpm/rc:
minimum-release-age=10080 (minutes)
~/.bunfig.toml
[install]:
minimumReleaseAge = 604800 (seconds)
This would have protected the 334 people who downloaded @bitwarden/cli 2026.4.0 ~19h ago (according to https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi...). Same for axios last month (removed in ~3h). Doesn't help with event-stream-style long-dormant attacks but those are rarer.(plug: released a small CLI to auto-configure these — https://depsguard.com — I tried to find something that will help non developers quickly apply recommended settings, and couldn't find one)
My two most precious digital possessions - my email and my Bitwarden account - are protected by a Yubikey that's always on my person (and another in another geographical location). I highly recommend such a setup, and it's not that much effort (I just keep my Yubikey with my house keys)
I got a bit scared reading the title, but I'm doing all I can to be reasonably secure without devolving into paranoia.
If you see any package that has hundreds of libraries, that increases the risk of a supply chain attack.
A password manager does not need a CLI tool.
Why not? Even macos keychain supports cli.
I don't think macOS Keychain uses NPM and it isn't in TypeScript or Javascript and, yes it does not need a CLI either.
The NPM and Java/Typescript ecosystem is part of the problem that encourages developers to import hundreds of third-party libraries, due to its weak standard library which it takes at least ONE transitive dependency to be compromised and it is game over.
You still have not said why this is an issue of having a CLI.
I complained about both. What does this say from the start?
>> Once again, it is in the NPM ecosystem.
> You still have not said why this is an issue of having a CLI.
Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault. The breach itself if run in GitHub Actions would just make it a coveted target to compromise it which makes having one worse not better and for easier exfiltration.
So it makes even more sense for a password manager to not need a CLI at all. This is even before me mentioning the NPM and the Javascript ecosystem.
I need one because I am not always using a graphical interface. What exactly in a GUI do you think makes it harder/less attractive for an attacker?
If the GUI code is compromised in the same way as the CLI, it'll have the same level of access to your vault as soon as you enter your master password.
JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.
A password manager absolutely does need a CLI tool??
Not to mention that a graphical application is just as vulnerable to supply chain attacks.
That's a wild statement. The CLI is just another UI.
The problem in this case is JS and the NPM ecosystem. Go would be an improvement, but complexity is the enemy of security. Something like (pass)age is my preference for storing sensitive data.
I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.
Plus, now you're responsible for everything. Backups, auditing etc.
To date there have been zero instances when I needed to significantly change a password/service/login/credential solely from my phone and I was unable to access my laptop.
Additionally the file gets synchronized to a workstation that sits in my home office accessible by personal VPN, where it can be accessed in a shell session with the keepass CLI: https://tracker.debian.org/pkg/kpcli
You can use an extremely wide variety of your own choice of secure methods for how to get the file from the primary workstation (desktop/laptop) to your phone.
Password habits for many people are now decades-old, and very difficult to break.
https://cyberpress.org/hackers-exploit-keepass-password-mana...
It's only a matter of time until _they_ are also popped :(.
> The beacon established command and control over HTTPS
This wasn't a case where KeePass was compromised in any way, as far as I can tell. This appears to be a basic case of a threat actor distributing a trojanized version via malicious ads. If users made sure they are getting the correct version, they were never in danger. That's not to say that a supply chain attack couldn't affect KeePass, but this article doesn't say that it has.
Long term keepass users aren't going to be affected. If you mention software to others make sure you send them a link to a known safe download location instead of having them search for one (as new users searching like that are more at risk of stumbling on a malicious copy of the official site hosting a hacked version).
I wrote a version in Python and then rust back before the official CLI was released. Now you can use https://github.com/doy/rbw instead, much better maintained (since I don't use Bitwarden anymore).
So bold and so cowards at the same time...
obvious misdirection, but it does serve to make it very obvious it was a state actor.
Lol no, lots of groups do this, non-state ones too.
The irony! The security "solution" is so often the weak link.
> Bitwarden’s Chrome extension, MCP server, and other legitimate distributions have not been affected yet.
You're still pulling a lot of dependencies. At least they're pinned though.
Takes what, maybe 15 seconds to compile on a high-core machine from scratch? Isn't the end of the world.
Worse is the scope to have to review all those things, if you'd like to use it for your main passwords, that'd be my biggest worry. Luckily most are well established already as far as I can tell.
Praying to the security gods.
It seems like we've have non-stop supply chain attacks for months now?
Also didn't Microsoft (the owner of GitHub) got access to Claude Mythos in order to "seCuRe cRitiCal SoftWaRe InfRasTructUre FoR teh AI eRa"? Hows securing GitHub Action going for them?
Keep the password manager as a separate desktop app and turn off auto update.
I've also been preferring to roll things on my own in my side projects rather than pulling a package. I'll still use big, standalone libraries, but no more third-party shims over an API, I'll just vibe code the shim myself. If I'm going to be using vibe code either way, better it be mine than someone else's.
It is mind boggling how an app that just lists a bunch of items can be so bloated.
nozzlegear•1h ago
adityamwagh•1h ago
righthand•1h ago
palata•1h ago