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

351–360 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#351

Post by girvo »

wombatpm wrote: post #350
nirvdrum wrote: post #280

Earlier quoted context omitted.

The lack of a comprehensive standard library for JavaScript also results in projects pulling many more third party dependencies than you would with most other modern environments. It’s just a bigger attack surface. And if you can compromise a module used for basic functionality that you’d get out of the box elsewhere, the blast radius will be enormous.

So why hasn’t someone created a batteries include JS library? I don’t program in JS on the backend so I don’t know how feasible something like that is.

Everyone’s ideas of what batteries should be included differ

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#352

Post by NetMageSCW »

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…

Isn’t the problem with a minimum age release that the opposite would also occur - a high priority fix of zero day under exploit wouldn’t be fixed and you could be compromised in the window?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#353

Post by eranation »

NetMageSCW wrote: post #352
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…

Isn’t the problem with a minimum age release that the opposite would also occur - a high priority fix of zero day under exploit wouldn’t be fixed and you could be compromised in the window?

It is! It’s a tough problem to balance. The good news is that you can always override for specific cases. Linking to my other reply here: https://news.ycombinator.com/item?id=47880149

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#354

Post by eranation »

arianvanp wrote: post #213
eranation wrote: post #210

Earlier quoted context omitted.

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

The chainguard folks built sigstore :)

Yep yep, hence the ask, expected for containers, wondering if also for build from source.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#355

Post by ornornor »

vlovich123 wrote: post #348
Ukv wrote: post #279

Earlier quoted context omitted.

> presumably this comprise was only found out because a lot of people did update This was supposedly discovered by "Socket researchers", and the product they're selling is proactive scanning to detect/block malicious packages, so I'd assume this would've been discovered even if no regular users had updated. But I'd claim even for malware that's only discovered due to normal users updating, it'd generally be better to…

Better for the cool down to be managed guaranteed centrally by the package forge rather than ad-hoc by each individual client.

That’s tricky, sometimes you really need the new version to be available right away.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#356

Post by eranation »

neya wrote: post #320
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.

Yes but it has nothing to do with the language, and everything to do with the ecosystem (npm tried to make thing such as mandatory MFA etc, npmjs is so big maintainers pushed back)

TypeScript on its own is a great language, with a very interesting type system. Most other type systems can’t run doom.

https://simonwillison.net/2025/Feb/27/typescript-types-can-r...

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#357

Post by riteshnoronha16 »

Ukv wrote: post #279
abustamam wrote: post #255

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.

> presumably this comprise was only found out because a lot of people did update This was supposedly discovered by "Socket researchers", and the product they're selling is proactive scanning to detect/block malicious packages, so I'd assume this would've been discovered even if no regular users had updated. But I'd claim even for malware that's only discovered due to normal users updating, it'd generally be better to…

[dead]

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#358

Post by masklinn »

saghm wrote: post #329
wycats wrote: post #310

Earlier quoted context omitted.

As one of the original authors of Cargo, I agree. lockfiles are for apps and CLIs are apps. QED.

Since you're here, and you happened to indirectly allude to something that seems to have become increasingly common in the Rust world nowadays, I can't help but be curious about your thoughts on libraries checking their lockfiles into version control. It's not totally clear to me exactly when or why it became widespread, but it used to be relatively rare for me to see in open source libraries in the first few post-1.…

> It's not totally clear to me exactly when or why it became widespread

It’s not exactly a tough nut to crack: it changed 2-ish years ago after guidance (and cargo’s defaults) changed: https://blog.rust-lang.org/2023/08/29/committing-lockfiles/

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#359

Post by NamlchakKhandro »

MetaWhirledPeas wrote: post #245
PunchyHamster wrote: post #223

Earlier quoted context omitted.

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

Other package managers are magically immune?

yes obviously.

isn't it obvious?

it should be obvious.

why isn't obvious?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#360

Post by wolfi1 »

girvo wrote: post #351
wombatpm wrote: post #350

Earlier quoted context omitted.

So why hasn’t someone created a batteries include JS library? I don’t program in JS on the backend so I don’t know how feasible something like that is.

Everyone’s ideas of what batteries should be included differ

I, for one, root for AAA
Post reply on HN