Live data from Hacker News

Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

socket.dev

291–300 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#291
post #178

Earlier quoted context omitted.

I have family I need to support, so I use 1password. It also helped that work gives me a 1P family plan free. The practical differences to me: * 1P is aimed at non-tech users more than Bitwarden. * 1P lets you easily store things other than just passwords (serial #'s, license info, SSN's, etc) You can in Bitwarden, but it's a little annoying. * 1P lets you store SSH keys(by effectively being an ssh-agent): https://de…

Bitwarden can also act as an ssh-agent: https://bitwarden.com/help/ssh-agent/

Ah, nice!

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#292
post #51

https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16 You're still pulling a lot of dependencies. At least they're pinned though.

> At least they're pinned though.

Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it.

The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#293
post #51

https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.

Is there any downside to using the firefox builtin password manager?

Does it support autofill for other apps on mobile? I'd argue that putting passwords in your phone clipboard could itself be risky (although for someone who's extremely security conscious, maybe discouraging using apps isn't a downside)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#295
post #278
post #51

https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.

I wonder if this is going to push more software to stacks like .Net where you can do most things with zero third-party dependencies. Or, conversely, encourage programming languages to increase the number of features in their standard libraries.

A few months ago I tried to build a .NET package on Linux, and the certificate revocation checks for the dependencies didn't complete even after several minutes. Eventually I found out about the option `NUGET_CERTIFICATE_REVOCATION_MODE=offline`, which managed to cause the build to complete in a sane amount of time.

It's hard for me to take seriously any suggestion that .NET is a model for how ecosystems should approach dependency management based on that, but I guess having an abysmal experience when there are dependencies is one way to avoid risks. (I would imagine it's probably not this bad on Windows, or else nobody would use it, but at least personally I have no interest in developing on a stack that I can't expect to work reliably out of the box Linux)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#296
post #51

https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.

That’s my concern too. Rust has the same dependency concerns, which is how hackers get into code. VaultWarden has the same Rust dependency concern. Ironically we’re entering an age where C/C++ seems to have everything figured out from a dependency injection standpoint

Now all they need to figure out is how to actually make the C/C++ code that isn't from dependencies secure and they'll be all set

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#297

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 like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.

That assumes discovering a security bug is random and it could happen to anyone, so more shots on goal is better. But is that a good way to model it?

Ir seems like if you were at all likely to be giving dependencies the extra scrutiny that discovers a problem, you’d probably know it? Most of the people who upgraded didn’t help, they just got owned.

A cooldown gives anyone who does investigate more time to do their work.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#298

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…

But how do you know which one is good? If foo package sends out an announcement that v1.4.3 was hacked, upgrade now to v1.4.4 and you're on v1.4.3, waiting a week seems like a bad idea. But if the hackers are the one sending the announcement, then you'd really want to wait the week!

malicious versions are recalled and removed when caught - so you don't need to update to the next version

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#299
post #274

Earlier quoted context omitted.

I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.

Cooldown sounds like a good idea ONLY IF these so called security companies can catch these malicious dependencies during the cooldown period. Are they doing this bit or individual researchers find a malware and these companies make headlines?

Does it matter? The individual researchers could look at brand-new published packages just the same

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#300
post #292

Earlier quoted context omitted.

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16 You're still pulling a lot of dependencies. At least they're pinned though.

> At least they're pinned though. Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it. The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on ver…

Is there a plan to change this? I don't see why --locked shouldn't be the default
Post reply on HN