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.
~/.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.
https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.
show comments
ef2k
The issue was a compromised build pipeline that shipped a poisoned package.
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.
show comments
1024kb
I had a really bad experience with the bitwarden cli. I believe it was `bw list` that I ran, assuming it would list the names of all my passwords, but too my surprise, it listed everything, including passwords and current totp codes. That's not the worst of it though. For some reason, when I ssh'ed into one of my servers and opened tmux, where I keep a weechat irc client running, I noticed that the entire content of the bw command was accessible from within the weechat text input field history. I have no idea how this happened, but it was quite terrifying. The issue persisted across tmux and weechat sessions, and only a reboot of the server would solve the problem.
I promptly removed the bw cli programme after that, and I definitely won't be installing it again.
I use ghostty if it matters.
show comments
flossly
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.
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.
darkwater
> Russian locale kill switch: Exits silently if system locale begins with "ru", checking Intl.DateTimeFormat().resolvedOptions().locale and environment variables LC_ALL, LC_MESSAGES, LANGUAGE, and LANG
So bold and so cowards at the same time...
show comments
mobeigi
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.
show comments
erans
The part that seems most important here is that npm install was enough.
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:
What's particularly impressive about this attack is that the attackers must have precisely coordinated it with Github not being down.
show comments
hrimfaxi
> The affected package version appears to be @bitwarden/cli2026.4.0, and the malicious code was published in bw1.js, a file included in the package contents. The attack appears to have leveraged a compromised GitHub Action in Bitwarden’s CI/CD pipeline, consistent with the pattern seen across other affected repositories in this campaign.
GaryBluto
To use a fitting turn of phrase, "Many such cases."
How many times will this happen before people realise that updating blind is a poor decision?
isatty
Writing a cli with JavaScript? No thank you.
show comments
wooptoo
This is precisely why I don't use BW CLI. Use pass or gopass for all your CLI tokens and sync them via a private git repo.
Keep the password manager as a separate desktop app and turn off auto update.
show comments
8cvor6j844qw_d6
Narrower blast radius than the 2022 LastPass breach, at least the vaults weren't touched.
hgoel
Does the CLI 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.
I am glad I consciously decided not to put 2FA keys when I adopted bitwarden back in 2021, and manage them with Aegis. It was a bit of a hassle to setup backups, but it's good to split your points of failure.
sega_sai
So how likely is that these compromises will start affecting the non-cli and non-open-source tools ? For example other password managers (in the form of GUI's or browser extensions).
qux_ca
FYI, Raycast users, the bitwarden-cli version used with the bundled bitwarden extension is 2026-03-01, not the compromised one (2026-04-01).
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.
show comments
Scene_Cast2
I recently had to disable their Chrome extension because it made the browser grind to a halt (spammed mojo IPC messages to the main thread according to a profiler). I wasn't the only one affected, going by the recent extension reviews. I wonder if it's related.
Somehow thats good because the rest of the Bitwarden apps will benefit from the increased tightness of their tooling and ci/cd
ozgrakkurt
Their website is also incredibly bad. I am not paying for it so it might be better for paying users.
It is mind boggling how an app that just lists a bunch of items can be so bloated.
post-it
I've dramatically decreased my reliance on third-party packages and tools in my workflow. I switched from Bitwarden to Apple Passwords a few months ago, despite its worse feature set (though the impetus was Bitwarden crashing on login on my new iPad).
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.
show comments
tracker1
I was literally thinking about installing the cli a few days ago to ease the use in a few places. Now I'm glad I didn't.
hurricanepootis
This doesn't affect the web extension, no?
0xbadcafebee
This will continue to happen more and more, until legislation is passed to require a software building code.
masfuerte
> Checkmarx is an information security company specializing in software application security testing and risk management for software supply chains.
The irony! The security "solution" is so often the weak link.
show comments
xmorse
I am working on a project you can self host on Cloudflare with one command, to store secrets and passwords there. It has a cli similar to doppler
Remember how the White House published that document on memory safe languages? I think it’s time they go one step further and ban new development in JavaScript. Horrible language horrible ecosystem and horrible vulns.
I wonder if 1Password CLI is a top priority for hackers similarly.
show comments
archargelod
That's why I don't use any third-party password managers. You have to trust them not to fuck up security, updates, backups, etc. etc.
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.
sigmonsays
If I run the compromised CLI, do they get all my passwords?
show comments
raphinou
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
nozzlegear
Another day, another supply chain attack involving GitHub Actions.
show comments
y0ssar1an
they were cooked the minute they chose to write it in typescript
saidnooneever
some coffee apps will be malicious now with 'melange' as IoC haha.. and Navigator xD... but i guess netscape is kinda malware o.O.
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.
giantfrog
How the hell are most people supposed to balance the risk of not updating software against the risk of updating software?
show comments
fnoef
I mean, what's the future now? Everyone just vibecoding their own private tools that no "foreign government" has access to? It honestly feels like everything is slowly starting to collapse.
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?
righthand
Dont write clis in Javascript.
nh43215rgb
> THE MOST TRUSTED PASSWORD MANAGER
> 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.
It seems like we've have non-stop supply chain attacks for months now?
show comments
stephenlf
Crap. I use that CLI.
rvz
Once again, it is in the NPM ecosystem. OneCLI [0] does not save you either. Happens less with languages that have better standard libraries such as Go.
If you see any package that has hundreds of libraries, that increases the risk of a supply chain attack.
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):
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
https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.
The issue was a compromised build pipeline that shipped a poisoned package.
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 had a really bad experience with the bitwarden cli. I believe it was `bw list` that I ran, assuming it would list the names of all my passwords, but too my surprise, it listed everything, including passwords and current totp codes. That's not the worst of it though. For some reason, when I ssh'ed into one of my servers and opened tmux, where I keep a weechat irc client running, I noticed that the entire content of the bw command was accessible from within the weechat text input field history. I have no idea how this happened, but it was quite terrifying. The issue persisted across tmux and weechat sessions, and only a reboot of the server would solve the problem.
I promptly removed the bw cli programme after that, and I definitely won't be installing it again.
I use ghostty if it matters.
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.
If anyone is looking for something local: https://github.com/saadnvd1/xpass
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.
> Russian locale kill switch: Exits silently if system locale begins with "ru", checking Intl.DateTimeFormat().resolvedOptions().locale and environment variables LC_ALL, LC_MESSAGES, LANGUAGE, and LANG
So bold and so cowards at the same time...
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.
The part that seems most important here is that npm install was enough.
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/
What's particularly impressive about this attack is that the attackers must have precisely coordinated it with Github not being down.
> The affected package version appears to be @bitwarden/cli2026.4.0, and the malicious code was published in bw1.js, a file included in the package contents. The attack appears to have leveraged a compromised GitHub Action in Bitwarden’s CI/CD pipeline, consistent with the pattern seen across other affected repositories in this campaign.
To use a fitting turn of phrase, "Many such cases."
How many times will this happen before people realise that updating blind is a poor decision?
Writing a cli with JavaScript? No thank you.
This is precisely why I don't use BW CLI. Use pass or gopass for all your CLI tokens and sync them via a private git repo.
Keep the password manager as a separate desktop app and turn off auto update.
Narrower blast radius than the 2022 LastPass breach, at least the vaults weren't touched.
Does the CLI 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?
I am glad I consciously decided not to put 2FA keys when I adopted bitwarden back in 2021, and manage them with Aegis. It was a bit of a hassle to setup backups, but it's good to split your points of failure.
So how likely is that these compromises will start affecting the non-cli and non-open-source tools ? For example other password managers (in the form of GUI's or browser extensions).
FYI, Raycast users, the bitwarden-cli version used with the bundled bitwarden extension is 2026-03-01, not the compromised one (2026-04-01).
https://github.com/raycast/extensions/blob/6765a533f40ad20cc...
I'm just hearing about this attack on Checkmarx.
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.
I recently had to disable their Chrome extension because it made the browser grind to a halt (spammed mojo IPC messages to the main thread according to a profiler). I wasn't the only one affected, going by the recent extension reviews. I wonder if it's related.
Bitwarden statement - https://community.bitwarden.com/t/bitwarden-statement-on-che...
Somehow thats good because the rest of the Bitwarden apps will benefit from the increased tightness of their tooling and ci/cd
Their website is also incredibly bad. I am not paying for it so it might be better for paying users.
It is mind boggling how an app that just lists a bunch of items can be so bloated.
I've dramatically decreased my reliance on third-party packages and tools in my workflow. I switched from Bitwarden to Apple Passwords a few months ago, despite its worse feature set (though the impetus was Bitwarden crashing on login on my new iPad).
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.
I was literally thinking about installing the cli a few days ago to ease the use in a few places. Now I'm glad I didn't.
This doesn't affect the web extension, no?
This will continue to happen more and more, until legislation is passed to require a software building code.
> Checkmarx is an information security company specializing in software application security testing and risk management for software supply chains.
The irony! The security "solution" is so often the weak link.
I am working on a project you can self host on Cloudflare with one command, to store secrets and passwords there. It has a cli similar to doppler
https://github.com/remorses/sigillo
Remember how the White House published that document on memory safe languages? I think it’s time they go one step further and ban new development in JavaScript. Horrible language horrible ecosystem and horrible vulns.
Looks like Bitwarden has a statement here, https://community.bitwarden.com/t/bitwarden-statement-on-che...
I wonder if 1Password CLI is a top priority for hackers similarly.
That's why I don't use any third-party password managers. You have to trust them not to fuck up security, updates, backups, etc. etc.
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.
If I run the compromised CLI, do they get all my passwords?
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
Another day, another supply chain attack involving GitHub Actions.
they were cooked the minute they chose to write it in typescript
some coffee apps will be malicious now with 'melange' as IoC haha.. and Navigator xD... but i guess netscape is kinda malware o.O.
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.
How the hell are most people supposed to balance the risk of not updating software against the risk of updating software?
I mean, what's the future now? Everyone just vibecoding their own private tools that no "foreign government" has access to? It honestly feels like everything is slowly starting to collapse.
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?
Dont write clis in Javascript.
> THE MOST TRUSTED PASSWORD MANAGER
> 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...
Can we please get a break?
Praying to the security gods.
It seems like we've have non-stop supply chain attacks for months now?
Crap. I use that CLI.
Once again, it is in the NPM ecosystem. OneCLI [0] does not save you either. Happens less with languages that have better standard libraries such as Go.
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