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

161–170 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#161

Post by eranation »

tadfisher wrote: post #155
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…

Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.

I agree, even without project glasswing (that Microsoft is part of) even with cheaper models, and Microsoft's compute (Azure, OpenAI collaboration), it makes no sense that private companies needs to scan new package releases and find malware before npm does. I'm sure they have some reason for it (people rely on packages to be immediately available on npm, and the real use case of patching a zero day CVE quickly), but until this is fixed fundamentally, I'd say the default should be a cooldown (either serverside or not) and you'll need to opt in to get the current behavior. This might takes years of deprecation though, I'm sure it was turned on now, a lot of things would break. (e.g. every CVE public disclosure will also have to wait that additional cooldown... and if Anthropic are not lying, we are bound for a tsunami of patched CVEs soon...)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#162

Post by traderj0e »

mayama wrote: post #112
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.

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

For a given tool, I'd expect the Rust version to have even more deps than the JS version because code reuse is more important in a lower-level language. I get the argument that JS users are on average less competent than Rust users, but we're talking about authors who build serious tools/libs in the first place.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#163

Post by npodbielski »

zie wrote: post #85
isatty wrote: post #21

Writing a cli with JavaScript? No thank you.

It's typescript and pretty sure all of the Official Bitwarden clients are written in it. 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).

What do you use?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#165

Post by [deleted] »

tadfisher wrote: post #155
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…

Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.

[deleted]

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#166

Post by gsnedders »

xvedejas wrote: post #139
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

Does this take into account feature flags when summing LOC? It's common practice in Rust to really only use a subset of a dependency, controlled by compile-time flags.

Also just unit tests in the source files, which again aren’t included in the binary via compile-time flags!

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#167

Post by NewsaHackO »

embedding-shape wrote: post #106
NewsaHackO wrote: post #99

Earlier quoted context omitted.

My point is that it could still be Russia, as they know that we know it is used as a false flag.

My point is; what changes if we knew for a fact it was Russia or that it was someone else?

>My point is; what changes if we knew for a fact it was Russia or that it was someone else?

Is this a serious question?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#168

Post by woodruffw »

tadfisher wrote: post #155
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…

Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.

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

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#170

Post by tadfisher »

eranation wrote: post #161
tadfisher wrote: post #155

Earlier quoted context omitted.

Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.

I agree, even without project glasswing (that Microsoft is part of) even with cheaper models, and Microsoft's compute (Azure, OpenAI collaboration), it makes no sense that private companies needs to scan new package releases and find malware before npm does. I'm sure they have some reason for it (people rely on packages to be immediately available on npm, and the real use case of patching a zero day CVE quickly), but…

There are so many ways to self-host package repos that "immediate availability" to the wider npm-using public is a non-issue.

Exceptions to quarantine rules just invites attackers to mark malicious updates as security patches.

If every kind of breakage, including security bugs, results in a 2-3 hour wait to ship the fix, maybe that would teach folks to be more careful with their release process. Public software releases really should not be a thing to automate away; there needs to be a human pushing the button, ideally attested with a hardware security key.

Post reply on HN