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

391–400 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#391

Post by piaste »

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.

The cooldown is a defence against malicious actors compromising the release infrastructure.

Having the forge control it half-defeats the point; the attackers who gained permission to push a malicious release, might well have also gained permission to mark it as "urgent security hotfix, install immediately 0 cooldown".

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#392

Post by neobrain »

akimbostrawman wrote: post #373
nathanmills wrote: post #335

Earlier quoted context omitted.

Why are browser extensions not sane in your opinion?

Browser password manager extensions are like putting a dog door on your reinforced vault door. Giant increase in attack surface.

Quite the contrary, actually: not using a browser extension makes you much more susceptible to phishing attacks, since your password manager won't be able to protect you from copy-pasting credentials into an imposter website.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#393

Post by yard2010 »

Groxx wrote: post #341
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?

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?

Maybe we can let people that don't care about privacy try them first

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#394

Post by duskdozer »

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…

Update dependencies when you need something in them, not just because there's a new version available.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#395

Post by tombh »

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…

Are we talking about `cargo build` here? Because my understanding is that if a lockfile is present and `Cargo.toml` hasn't changed since the lockfile was created then the build is guaranteed to use the versions in the lockfile.

If however `Cargo.toml` has changed then `cargo build` will have to recalculate the lockfile. Hence why it can be useful to be explicit about `cargo build --locked`.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#396

Post by nedt »

duskdozer wrote: post #394
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…

Update dependencies when you need something in them, not just because there's a new version available.

But then at the same time you should always update because it might fix a security vulnerability. Otherwise you end up running nodejs 10 because you don't need the new stuff.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#397

Post by gcolella »

Supply chain attacks via package managers are exactly the nightmare scenario. A few months ago I had a production issue where a composer dependency got silently nuked from our vendor/ — the package was setasign/fpdf. Before restoring it, my first instinct was "did someone compromise the repo?". Turned out to be local, but the 10 minutes between discovery and confirmation were terrifying. Now we pin every dependency by hash in composer.lock and review any change in it before deployment. Still not enough — if the registry itself is compromised, the hash pin saves you only from drive-by tampering, not from poisoned-at-origin uploads. Feels like we need something like Sigstore-level attestation for PHP/npm at minimum.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#398

Post by Ukv »

SV_BubbleTime wrote: post #183
1024kb wrote: post #26

Earlier quoted context omitted.

I need my passwords to be accessible from my infrastructure and my phone. How do you achieve this with KeePass? I assumed it was not possible, but in fairness, I haven't really gone down that rabbit hole to investigate.

Someone is about hop on and tell you how they simply run a Dropbox/GDrive to host their keepass vault and how that’s good enough for me (which should be Keepass’s tagline) and mobile they use a copy or some other manually derived and dependency ridden setup. They will support ad hoc over designed because their choice of ad hoc cloud is better than a service you use.

> and how that's good enough for me

I'd go further than that and say for me personally, the fact it's just a file is a selling point, not a "good enough" concession. I can just put passwords.kdbx alongside my notes.txt and other files (originally on a thumbdrive, now on my FTP server) - no additional setup required.

There will be people who use multiple devices but don't already have a good way to access files across them, but even then I'm not fully convinced that SaaS specifically for syncing [notes/passwords/photos/...] really is the most convenient option for them opposed to just being a well-marketed local maximum. Easy to add one more subscription, easy to suck it up when terms changes forbid you syncing your laptop, easy to pray you're not affected by recurring breaches, ... but I'd suspect often (not always) adds up to more hassle overall.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#399

Post by fc417fc802 »

stevekemp wrote: post #368
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.

https://github.com/stdlib-js/stdlib was is one of several attempts at that, but yes the issue is that different people have very different views of what should be standard.

That doesn't seem like it should be an issue in practice? Rather than a single standard library endorsed by the language stewards if the community at large converges on a small handful of "standard" solutions that seems like it would satisfy the security aspect of things.
Post reply on HN