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"

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

But PSA: If something is critical to the business and you’re using npm, pin your dependencies. I’ve had this debate with other devs throughout the years and they usually point to the lockfile as assurance, but version ranges with a ^ mean that when the lockfile gets updated, you can pull in newer versions you didn’t explicitly choose.

If what you're building can put your company out of business it's worth the hassle.

I promptly removed the bw cli programme after that, and I definitely won't be installing it again.

I use ghostty if it matters.

Quite bizarre to think much much of my well-being depends on those secrets staying secret.

So bold and so cowards at the same time...

I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.

Once the compromise point is preinstall, the usual "inspect after install" mindset breaks down. By then the payload has already had a chance to run.

That gets more interesting with agents / CI / ephemeral sandboxes, because short exposure windows are still enough when installs happen automatically and repeatedly.

Another thing I think is worth paying attention to: this payload did not just target secrets, it also targeted AI tooling config, and there is a real possibility that shell-profile tampering becomes a way to poison what the next coding assistant reads into context.

I work on AgentSH (https://www.agentsh.org), and we wrote up a longer take on that angle here:

https://www.canyonroad.ai/blog/the-install-was-the-attack/

How many times will this happen before people realise that updating blind is a poor decision?

Keep the password manager as a separate desktop app and turn off auto update.

Edit: The CLI itself apparently does not, which will have limited the damage a bit, but if it's installed as a snap, it might. Incidents like this should hopefully cause a rollback of this dumb system of forcefully and frequently updating people's software without explicit consent.

Also the time range provided in https://community.bitwarden.com/t/bitwarden-statement-on-che... can help with knowing if you were at risk. I only used the CLI once in the morning yesterday (ET), so I might not have been affected?

We recently adopted it at work, and I find the thing to just produce garbage. I've never tuned out noise so quickly.

you have to appreciate the irony of a thing that's supposed to help protect you from vulnerabilities being one.

https://github.com/raycast/extensions/blob/6765a533f40ad20cc...

https://github.com/remorses/sigillo

It is mind boggling how an app that just lists a bunch of items can be so bloated.

I've also been preferring to roll things on my own in my side projects rather than pulling a package. I'll still use big, standalone libraries, but no more third-party shims over an API, I'll just vibe code the shim myself. If I'm going to be using vibe code either way, better it be mine than someone else's.

The irony! The security "solution" is so often the weak link.

on a more serious note. i told you so levels reaching new heights. dont use password managers. dont handoff this type of risk to a third party.

its like putting all your keys in a flimsy lockbox outside of your appartment. at some point someone will trip over it, find the keys and explore -_-.

it being impractical with the amount of keys/passwords you need to juggle?

not an excuse. problem should and can be solved differently.

I wrote my own password generator - it's stateless, which has the advantage that I never have to back up or sync any data between devices. It just lets you enter a very long, secure master password, service name and a username then runs an scrypt hash on this with good enough parameters to make brute-force attacks unfeasible.

For anything important, I also use 2FA.

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

Also didn't Microsoft (the owner of GitHub) got access to Claude Mythos in order to "seCuRe cRitiCal SoftWaRe InfRasTructUre FoR teh AI eRa"? Hows securing GitHub Action going for them?

> Defend against hackers and data breaches

> Fix at-risk passwords and stay safe online with Bitwarden, the best password manager for securely managing and sharing sensitive information.

yep. literally from their website this moment..and the link to their "statement"[0] is nowhere on the front page.

Oh wait, there is a top banner..."Take insights to action: Bitwarden Access Intelligence now available Learn more >" nope.

[0]: https://community.bitwarden.com/t/bitwarden-statement-on-che...

Praying to the security gods.

It seems like we've have non-stop supply chain attacks for months now?

If you see any package that has hundreds of libraries, that increases the risk of a supply chain attack.

A password manager does not need a CLI tool.

[0] https://news.ycombinator.com/item?id=47585838