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

311–320 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#311

Post by hsbauauvhabzb »

erans wrote: post #262

The part that seems most important here is that npm install was enough. Once the compromise point is preinstall, the usual "inspect after install" mindset breaks down. By then the payload has already had a chance to run. That gets more interesting with agents / CI / ephemeral sandboxes, because short exposure windows are still enough when installs happen automatically and repeatedly. Another thing I think is worth pa…

Nobody inspects packages after install, your theory has been debunked multiple times, caring about npm install running scripts is moot when you’ll inevitably run the actual binary after install.

And besides, you could always pull the package and inspect before running install, which unless you really know the installer and understand/know guarantees deeply (e.g., whether it’s possible for an install to deploy files outside of node_modules) it’s insane to even vaguely trust it to pull and unpack potentially malicious code.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#312

Post by LegionMammal978 »

saghm wrote: post #292
pregnenolone wrote: post #91

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…

> 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.

Not quite: "1.2.3" = "^1.2.3" = ">=1.2.3, =1.2.0, =1.2.3, [0] https://doc.rust-lang.org/cargo/reference/specifying-depende...

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#313

Post by archargelod »

That's why I don't use any third-party password managers. You have to trust them not to fuck up security, updates, backups, etc. etc.

I wrote my own password generator - it's stateless, which has the advantage that I never have to back up or sync any data between devices. It just lets you enter a very long, secure master password, service name and a username then runs an scrypt hash on this with good enough parameters to make brute-force attacks unfeasible.

For anything important, I also use 2FA.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#314

Post by poly2it »

saghm wrote: post #292
pregnenolone wrote: post #91

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…

It should be fine to do this according to semver as long as the major version is above zero.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#315

Post by [deleted] »

PunchyHamster wrote: post #223
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…

Don't write anything backend or cli tool in NPM would be good start

[deleted]

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#316

Post by lousken »

d3Xt3r wrote: post #241
gbalduzzi wrote: post #148

Earlier quoted context omitted.

I don't understand how this solves the issue in this case. Bitwarden vaults were not compromised, there was a problem in a tool you used to access the secrets. What makes it impossible for KeePass access tools to have these issues?

It's not impossible, but most KeePass tools are written in sane languages and built with sane tooling, and don't use trash like Javascript and npm. Of course I'm not considering browser extensions or exclusive web-clients, but the main KeePass client has a good autotype system, so you don't really need to use the browser extension. In any case, the fact that the official BitWarden client (which uses Electron btw) and…

Fully agree, I can't wait for the day when developers finally stop using javascript for shit it was never designed for. .NET is decades ahead at this point.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#317

Post by dirtbag__dad »

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 guess this is the case for new installs, but for existing dependencies can’t you simply pin them to a patch release, and point at the sha?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#318

Post by personalcompute »

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…

Regarding doing more than just a minimum release age: The tool I personally use is Aikido "safe-chain". It sets minimum release age, but also provides a wrapper for npm/uv/etc where upon trying to install anything it first checks each dependency for known or suspected vulnerabilities against an online commercial vulnerability database.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#319

Post by saghm »

hsbauauvhabzb wrote: post #308
saghm wrote: post #293

Earlier quoted context omitted.

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)

So uninstall Reddit? That app is spyware at best and malware at worst.

I'm guessing you meant to respond to the sibling comment rather than mine

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#320

Post by neya »

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…

Stop using Javascript. Or Typescript or whatever excuses they have for the fundamentally flawed language that should have been retired eons ago instead of trying to get it fixed. Javascript, its ecosystem has always been a pack of cards. Time and again it has been proven again. I think this is like the 3rd big attack in the last 30 days alone.
Post reply on HN