Live data from Hacker News

Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

socket.dev

141–150 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#141
post #109

Earlier quoted context omitted.

> What can I do to prevent it? My two most precious digital possessions - my email and my Bitwarden account - are protected by a Yubikey that's always on my person (and another in another geographical location). I highly recommend such a setup, and it's not that much effort (I just keep my Yubikey with my house keys) I got a bit scared reading the title, but I'm doing all I can to be reasonably secure without devolvi…

If the software gets poisoned then your YubiKey will not save you.

I think they mean to secure your most valuable accounts with a hardware token rather than in a normal password manager, so they aren't at risk if your password manager has an issue.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#142
post #15

Never used the CLI, but I do use their browser plugin. Would be quite a mess if that got compromised. What can I do to prevent it? Run old --tried and tested-- versions? Quite bizarre to think much much of my well-being depends on those secrets staying secret.

We need cooldowns everywhere , by default. Development package managers, OS package managers, browser extensions. Even auto-updates in standalone apps should implement it. Give companies like Socket time to detect malicious updates. They're good at it, but it's pointless if everyone keeps downloading packages just minutes after they're published.

Exactly this. For anyone who wants to do it for various package managers:

  ~/.npmrc: 
  min-release-age=7 (npm 11.10+)

  ~/Library/Preferences/pnpm/rc: 
  minimum-release-age=10080 (minutes)

  ~/.bunfig.toml 
  [install]: 
  minimumReleaseAge = 604800 (seconds)

This would have protected the 334 people who downloaded @bitwarden/cli 2026.4.0 ~19h ago (according to https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi...). Same for axios last month (removed in ~3h). Doesn't help with event-stream-style long-dormant attacks but those are rarer.

(plug: released a small CLI to auto-configure these — https://depsguard.com — I tried to find something that will help non developers quickly apply recommended settings, and couldn't find one)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#143

Earlier quoted context omitted.

We need cooldowns everywhere , by default. Development package managers, OS package managers, browser extensions. Even auto-updates in standalone apps should implement it. Give companies like Socket time to detect malicious updates. They're good at it, but it's pointless if everyone keeps downloading packages just minutes after they're published.

Exactly this. For anyone who wants to do it for various package managers: ~/.npmrc: min-release-age=7 (npm 11.10+) ~/Library/Preferences/pnpm/rc: minimum-release-age=10080 (minutes) ~/.bunfig.toml [install]: minimumReleaseAge = 604800 (seconds) This would have protected the 334 people who downloaded @bitwarden/cli 2026.4.0 ~19h ago (according to https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... ). Same…

https://cooldowns.dev/#javascript-ecosystem ;-)

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#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 versions").

Same story for the malicious axios (@1.14.1 and @0.30.4, removed within ~3h), ua-parser-js (hours), and node-ipc (days). Wouldn't have helped with event-stream (sat for 2+ months), but you can't win them all.

Some examples (hat tip to https://news.ycombinator.com/item?id=47513932):

  ~/.npmrc
  min-release-age=7 # days

  ~/Library/Preferences/pnpm/rc
  minimum-release-age=10080 # minutes

  ~/.bunfig.toml
  [install]
  minimumReleaseAge = 604800 # seconds

  # not related to npm, but while at it...
  ~/.config/uv/uv.toml
  exclude-newer = "7 days"

p.s. shameless plug: I was looking for a simple tool that will check your settings / apply a fix, and was surprised I couldn't find one, I released something (open source, free, MIT yada yada) since sometimes one click fix convenience increases the chances people will actually use it. https://depsguard.com if anyone is interested.

EDIT: looks like someone else had a similar idea: https://cooldowns.dev

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#146
post #143

Earlier quoted context omitted.

Exactly this. For anyone who wants to do it for various package managers: ~/.npmrc: min-release-age=7 (npm 11.10+) ~/Library/Preferences/pnpm/rc: minimum-release-age=10080 (minutes) ~/.bunfig.toml [install]: minimumReleaseAge = 604800 (seconds) This would have protected the 334 people who downloaded @bitwarden/cli 2026.4.0 ~19h ago (according to https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... ). Same…

https://cooldowns.dev/#javascript-ecosystem ;-)

Love it, I'll link to it!

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#147
From my understanding the checkmarx attack could have been prevented by the asfaload project I'm working on. See https://github.com/asfaload/asfaload

It is:

- open source

- accountless(keys are identity)

- using a public git backend making it easily auditable

- easy to self host, meaning you can easily deploy it internally

- multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected

- validating a download transparantly to the user, which only requires the download url, contrary to sigstore

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#148
post #20

KeePass users continue to live the stress free live. I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.

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?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#149
post #134
post #38

Earlier quoted context omitted.

Keepass is just a single file, you can share it between devices however you want (google drive, onedrive, dropbox, nextcloud, syncthing, rsync, ftp, etc); as long as you can read and write to it, it just works. There are keepass clients for just about everything (keepassxc for desktops, keepass2android or keepassdx for android, keepassium for iphone).

How is the quality of browser extensions compared to Bitwarden?

I don't have any points of comparison since I've never used Bitwarden, but it works well enough for my purposes. It'll match the url, offer to autofill (sometimes those multiflow sites like Microsoft will trip it up, but you can always just right click -> enter username/password for a site and that'll work), and it does TOTP filling too.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#150

Earlier quoted context omitted.

Syncthing can synchronize Keepass files between devices quite well.

What happens if you add a new item on two devices simultaneously?

It renames one of them to $hostname_conflicted, or something like that. Keepass has a built in tool for reconciling two databases, you can use that in this scenario.
Post reply on HN