Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

socket.dev

Post reply on HN
Print view View original

181–190 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#181

Post by fauigerzigerk »

eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

I use a separate dev user account (on macOS) for package installations, VSCode extensions, coding agents and various other developer activities.

I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#182

Post by eipi10_hn »

kelvinjps10 wrote: post #98
mobeigi wrote: post #20

KeePass users continue to live the stress free live. I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.

the only thing I can't find to do with keepass is how back up it in the cloud, like if you encrypt your back up, then where do you save that password, then where do you save the password for the cloud provider?.

Same as Bitwarden? You just need to remember Keepass password, just like remember Bitwarden password.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#183

Post by SV_BubbleTime »

1024kb wrote: post #26
mobeigi wrote: post #20

KeePass users continue to live the stress free live. I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.

I need my passwords to be accessible from my infrastructure and my phone. How do you achieve this with KeePass? I assumed it was not possible, but in fairness, I haven't really gone down that rabbit hole to investigate.

Someone is about hop on and tell you how they simply run a Dropbox/GDrive to host their keepass vault and how that’s good enough for me (which should be Keepass’s tagline) and mobile they use a copy or some other manually derived and dependency ridden setup. They will support ad hoc over designed because their choice of ad hoc cloud is better than a service you use.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#184

Post by 4ndrewl »

eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

The problem with cooldowns is that the more people use them, the less effective they become.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#185

Post by n_e »

eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

> Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)?

With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow).

Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm).

These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#186

Post by harshreality »

epistasis wrote: post #115
stvnbn wrote: post #95

Earlier quoted context omitted.

I love how the first comment is a complain having nothing to do with the actual subjec

Password managers are all about trust, the main link is about a compromise, so it's not surprising that the first comment is also about trust too, even if it's not directly about this particular compromise. 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.

Where's the evidence that 1024kb's issue had anything to do with bw? How is that vaguely recalled anecdote a trust issue with bw? It was probably caused by accidentally copying something to the clipboard or some other buffer which was then transferred via ssh and imported into weechat, possibly with the help of custom terminal, ssh, tmux, or weechat settings making it too easy for data to be slung around like that.

I can't think of a plausible explanation for how bw is at fault for its terminal output ending up, across a ssh session and tmux invocation, in the chat history of weechat. Even if bw auto-copied its output to the clipboard (which as far as I could tell by glancing at the cli options, it doesn't and can't), and the clipboard is auto-copied to remote hosts, clipboard contents shouldn't appear in an irc client's history without explicit hacking to do that.

The claim is just noise, particularly because it doesn't seem to have ever been investigated.

It seems prudent, if someone wants to use a cli, to use rbw rather than bw, or even just pass or keypassxc-cli (and self-managed cloud backup or syncing). However, that's based on bw being a javascript mess, not based on the unlikely event of bw injecting its output through ssh into irc clients.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#187

Post by SV_BubbleTime »

prima-facie wrote: post #57

This is precisely why I don't use BW CLI. Use pass or gopass for all your CLI tokens and sync them via a private git repo. Keep the password manager as a separate desktop app and turn off auto update.

A supply chain issue that hadn’t happened to BW CLI before is exactly why you use other CLIs that seem to be identically vulnerable to the same issues?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#188

Post by doctorpangloss »

eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

Haha what if there's an urgent security fix in an updated package?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#189

Post by woodruffw »

tadfisher wrote: post #177
woodruffw wrote: post #168

Earlier quoted context omitted.

"Just" is doing a lot of work; most ecosystems are not set up or equipped to do this kind of server-side queuing in 2026. That's not to say that we shouldn't do this, but nobody has committed the value (in monetary and engineering terms) to realizing it. Perhaps someone should. By contrast, a client-side cooldown doesn't require very much ecosystem or index coordination.

Yeah, I should work on avoiding that word.

I think the rest of your analysis is correct! I'm only pushing back on perceptions that we can get there trivially; I think people often (for understandable reasons) discount the social and technical problems that actually dominate modernization efforts in open source packaging.
Post reply on HN