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

341–350 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#341

Post by Groxx »

kjok wrote: post #274
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.

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?

It seems less likely that they'll find it before you're bitten by it if you intentionally race against them by choosing newest all the time, yea?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#342

Post by nikcub »

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…

compartmentalize. I do development and anything finance / crypto related / sensitive on separate machines.

If you're brave you can run whonix.

The issue is developers who have publish access to popular packages - they really should be publishing and signing on a separate machine / environment.

Same with not doing any personal work on corporate machines (and having strict corp policy - vercel were weak here).

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#343

Post by eipi10_hn »

nathanmills wrote: post #333
prmoustache wrote: post #283

Earlier quoted context omitted.

I don't autofill. It may be less user friendly but it is not that big of a deal.

I don't save browser cookies for obvious privacy reasons and it's absolutely a big deal to not need to pull up some program and copy paste my login details constantly for every site.

I usually just use another profile for the stuff that I clear cookies when closing the profile. The other profiles I just use for a limited of sites that need logging in, each site is in its own container and I don't browse other sites on those profiles.

If I ever need to fill the login, I just do any of these:

- KeepassXC has auto-type feature, so I just choose the needed one and let it auto-type - I enable the extension only when I need to log in and choose the one I need to fill (not auto-fill, but only fill when I click on the account from the extension pop-up dashboard).

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#344

Post by atdt »

seanw444 wrote: post #231
elAhmo wrote: post #219

Earlier quoted context omitted.

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

It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.

What exactly would you have done differently?

Cargo made its debut in 2014, a year before the infamous left-pad incident, and three years before the first large-scale malicious typosquatting attacks hit PyPI and NPM. The risks were not as well-understood then as they are today. And even today it is very far from being a solved problem.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#346

Post by hunter2_ »

subarctic wrote: post #299
kjok wrote: post #274

Earlier quoted context omitted.

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

For researchers who notice new releases as soon as they are published and discover malice based on that alone, I agree, and every step of that can be automated to some level of effectiveness.

But for researchers who aren't sufficiently effective until the first victim starts shouting that something went sideways, the malicious actor would be wise to simply ensure no victim is aware until well after the cooldown period, implementing novel obfuscation that evades static analysis and the like.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#347

Post by pavon »

bfivyvysj wrote: post #304
fragmede wrote: post #260

Earlier quoted context omitted.

But it goes the other way too. If there's a security vulnerability that was fixed in a later version, you want the system to automatically pick that up and apply it for you in an ideal scenario.

Why would you patch a security vuln in a later version? Should be patched in all versions.. that's what semver is for.

A patch updates is a newer version, and they are just as likely to be compromised by supply chain attacks as minor or major updates.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#348

Post by vlovich123 »

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…

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

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#349

Post by pico303 »

nirvdrum wrote: post #280
c2h5oh wrote: post #247

Earlier quoted context omitted.

They are not, but npm is uniquely bad in that regard. Refusal to implement security features that would have made attacks like this harder really doesn't help https://github.com/node-forward/discussions/issues/29

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.

Not to mention a culture of basically one-line packages ad infinitum. I downloaded a JS tool the other day to generate test reports and it had around 300 dependencies.

Needless to say I’m running all my JS tools in a Docker container these days.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#350

Post by wombatpm »

nirvdrum wrote: post #280
c2h5oh wrote: post #247

Earlier quoted context omitted.

They are not, but npm is uniquely bad in that regard. Refusal to implement security features that would have made attacks like this harder really doesn't help https://github.com/node-forward/discussions/issues/29

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.
Post reply on HN