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

211–220 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#211

Post by eranation »

madduci wrote: post #209
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…

Renovate can do it as well

Yep, depsguard has support for renovate and dependabot cooldown settings too.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#213

Post by arianvanp »

eranation wrote: post #210
prdonahue wrote: post #176

Earlier quoted context omitted.

> 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)? Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period. For the long tail…

Build from source is a great idea, I assume you provide SLSA/sigstore like provenance as well?

The chainguard folks built sigstore :)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#214

Post by eranation »

4ndrewl wrote: post #184
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.

Well, luckily, those who find the malicious activity are usually companies who do this proactively (for the good of the community, and understandably also for marketing). There are several who seem to be trying to be the first to announce, and usually succeed. IMHO it should be Microsoft (as owners of GitHub, owners of npm) who should take the helm and spend the tokens to scan each new package for malicious code. It gets easier and easier to detect as models improve (also gets easier and easier to create, and try to avoid detection on the other hand)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#215

Post by pprotas »

harshreality wrote: post #131
trinsic2 wrote: post #17

Earlier quoted context omitted.

Wow. Thats crazy. Is there an extension for bwcli in weechat? BTW I didnt even know BW had a cli until now. I use keepass locally.

It's crazy because it's not default bw behavior, or even any bw behavior... I don't use the cli, but I don't see any built-in capacity to copy bw output to the clipboard. (In the UNIX way, you'd normally pipe it to a clipboard utility if you wanted it copied, and then the security consequences are on you.) They probably caused it themselves, somehow, and then blamed bitwarden. Note in the original comment they aren't…

`bw list` shows plaintext credentials in the CLI https://bitwarden.com/help/cli/#list

I know this because I had the same surprised reaction

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#216

Post by eranation »

giantfrog wrote: post #212

How the hell are most people supposed to balance the risk of not updating software against the risk of updating software?

It's a hard decision, I would say a cooldown by default in the last few months would have prevented more attacks than not upgrading to the latest version due to an immediate RCE, zero-click, EPSS 100%, CVSS 10.0, KEV mentioned Zero Day CVE. But now that the Mythos 90 days disclosure window gets closer, I don't know what tsunami of urgent patches is in our way... it's not an easy problem to solve.

I lean toward cooldown by default, and bypass it when an actual reachable exploitable ZeroDay CVE is released.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#217

Post by Ritewut »

tredre3 wrote: post #205
brightball wrote: post #48

Earlier quoted context omitted.

The problem is that the UX with a browser extension is so much better.

> The problem is that the UX with a browser extension is so much better. It's better, but calling it so much better [that it's unreasonable to forgo the browser extension] is a bit silly to me. 1. Go to website login page 2. trigger the global shortcut that will invoke your password manager 3. Your password manager will appear with the correct entry usually preselected, if not type 3 letters of the site's name. 4. Pr…

The tradeoff is that you need to know how to setup a global shortcut or even know it's even possible. I wish people would stop minimizing the knowledge they have as something everyone just knows.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#218

Post by lxgr »

reactordev wrote: post #113
cobolcomesback wrote: post #107

Earlier quoted context omitted.

Not to mention utter nonsense. There’s no possible way that BW CLI somehow injected command history into a remote server. That was 100% something the GP did, a bug in their terminal, or a config they have with ssh/tmux, not Bitwarden.

that's our future... with AI. Engineers that don't know the difference between client-side convenience and server-side injection, how to configure `php.ini`, or that no synchronized password manager is safe. While the OAuth scope is `*`, and CORS is what you drink on the weekend.

We've had all those well before AI.

> no synchronized password manager is safe

Care to elaborate? I'd agree that the security/availability tradeoff is different, but "not safe" is as nonsensical a blanket statement as "all/only offline/paper-based/... password managers are safe".

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#219

Post by elAhmo »

embedding-shape wrote: post #129
mayama wrote: post #112

Earlier quoted context omitted.

That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others. https://lib.rs/crates/rbw

326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. 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.

"326 seems large, but not abnormal" was the state of JS in the past as well.

Chance of someone auditing all of them is virtually zero, and in practice no one audits anything, so you are still effectively blindly trusting that none of those 326 got compromised.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#220

Post by lxgr »

rvz wrote: post #79
nicce wrote: post #47

Earlier quoted context omitted.

I thought that CLI would be efficent when I looked for using it and then I figured it is JavaScript

Exactly. That is the 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.

> importing hundreds of third-party packages

But how else are you going to check if a number is even or odd? Remember, the ONLY design goal is not repeating yourself (or in fact anything anyone has ever thought of implementing).

Post reply on HN