The Bitwarden security team identified and contained a malicious package that was briefly distributed through the npm delivery path for @bitwarden/cli@2026.4.0 between 5:57 PM and 7:30 PM (ET) on April 22, 2026, in connection with a broader Checkmarx supply chain incident. The investigation found no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised. Once the issue was detected, compromised access was revoked, the malicious ...
This problem has nothing to do with NPM. Checkmarx was compromised last month, and during that compromise there were malicious VS Code extensions published to Visual Studio Code Marketplace. A Bitwarden developer says that somebody ran one of those malicious extensions, and GitHub API keys were stolen which were used in publishing the malicious CLI package.
It’s probably better that it happened on NPM. If the CLI were only downloadable from the Bitwarden website, it would have likely taken longer for somebody to notice something was wrong.
Genuine question. How is NPM more vulnerable than other repos? Haven’t similar supply chain attacks succeeded at least as well as this one through GitHub itself and even Linux package repos?
Larger standard libraries do a lot. It’s a lot harder to sneak vulnerabilities into the basic C# or Java or C++ libraries than it is to add a vulnerability to something one dude maintains in the javascript ecosystem.
And since javascript libraries tend to be so small and focused, it’s become standard practice for even other libraries to pull in as many of those as they want.
And it stacks. Your libraries pull in other libraries which can pull in their own libraries. I had a project recently where I had maybe a dozen direct dependencies and they ended up pulling in 1,311 total libraries, largely all maintained by different people.
In a more sane ecosystem like C#, all the basics like string manipulation, email, or logging have libraries provided by Microsoft that have oversight when they’re changed. There can be better, third-party libraries for these things (log4net is pretty great), but they have to compete with their reputation and value over the standard library, which tends to be a high bar. And libraries made on top of that system are generally pulling all those same, certified standard libraries. So you pull in 3 libraries and only one of those pulls in another third party single library. And you end up with 4 total third party libraries.
Javascript just doesn’t really have a certified standard library.
(This certified standard library doesn’t have to be proprietary. Microsoft has made C# open source, and Linus Torvalds with the Linux Kernel Organization holds ultimate responsibility for the Linux kernel.)
I will almost always choose .NET as my development platform when greenfielding a project for exactly this reason. It’s an incredibly robust standard library that virtually guarantees I won’t need to pull in a litany of additional utility libraries, and I can also expect that what libraries I do choose to bring in are highly unlikely to drag along a ridiculous parade of dependencies.
Probably more worth than it was 15 years ago since you’re no longer restricted to Windows and it’s now open source. I’ve heard a lot of people say it’s nicer than Spring for enterprise stuff. Haven’t tried it much myself though. Was fairly easy to set up a simple API, but I then got distracted by other projects.
Yes, it’s incredibly nice, versatile, powerful and efficient. Me being a .net dev since first beta. That said it’s still a GC based runtime if that matters to you. I’m also looking more and more at kotlin as an alternative. If I was to look for a non GC language, I’d go with rust.
There’s a lot of features that make it a better package manager but nobody cares. Every project has hundreds of dependencies and packages use a minimum, not exact, version.
That sounds more like bad practices from the community. It definitely has ways to use exact versions. Not the least of which the lock file. Or the shrinkwrap file which public packages should be using.
Any security system based on expecting good behavior from people is sure to fail. If NPM has no estructural features to enforce safe behaviors, it is vulnerable by default. As no person using it will apply safe practices unless forced to. Specially if the default, easiest, less friction behavior, is inherently unsafe.
Npm probably has the biggest attack surface and many of the libraries hosted there are in extremely widespread use. They’ve taken some steps to mitigate these supply chain attacks, but as we’ve seen with more recent examples, it’s unrealistic to think they can be prevented completely. Most of these attacks use stolen developer credentials, which invalidates almost all potential security measures on the registry side and the best you can hope for is catching a malicious package quickly. To be clear: I think the JS ecosystem is uniquely positioned to be the prime target of supply chain attacks and while that doesn’t excuse the slow implementation of security measures from the npm team, the people arguing that other package managers and registries aren’t vulnerable to this have to be huffing fumes.
But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?
I’m guessing things were working out pretty alright, even with the insane amount of dependencies per project. The awareness and the increasing frequency of supply chain attacks is relatively recent for npm. But who knows, maybe the tech giants in control of the web standards are happy to keep using their own vendored registries.
If you’re asking why there isn’t one shipped with JS, the answer is because JS is built for the web, and the “don’t break the web” rule makes changing things in JS hard, as well as browser devs pushing back hard on anything that increases install size.
If you’re asking why as a community, we haven’t agreed on a single package to be a stdlib - lodash.
Can we stop using npm now?
I swear to god the number of attacks like this or spawned from other attacks like this is fucking stupid. I’ve gender seen anything like it.
This problem has nothing to do with NPM. Checkmarx was compromised last month, and during that compromise there were malicious VS Code extensions published to Visual Studio Code Marketplace. A Bitwarden developer says that somebody ran one of those malicious extensions, and GitHub API keys were stolen which were used in publishing the malicious CLI package.
It’s probably better that it happened on NPM. If the CLI were only downloadable from the Bitwarden website, it would have likely taken longer for somebody to notice something was wrong.
What a fucking asanine series of events.
Genuine question. How is NPM more vulnerable than other repos? Haven’t similar supply chain attacks succeeded at least as well as this one through GitHub itself and even Linux package repos?
Larger standard libraries do a lot. It’s a lot harder to sneak vulnerabilities into the basic C# or Java or C++ libraries than it is to add a vulnerability to something one dude maintains in the javascript ecosystem.
And since javascript libraries tend to be so small and focused, it’s become standard practice for even other libraries to pull in as many of those as they want.
And it stacks. Your libraries pull in other libraries which can pull in their own libraries. I had a project recently where I had maybe a dozen direct dependencies and they ended up pulling in 1,311 total libraries, largely all maintained by different people.
In a more sane ecosystem like C#, all the basics like string manipulation, email, or logging have libraries provided by Microsoft that have oversight when they’re changed. There can be better, third-party libraries for these things (log4net is pretty great), but they have to compete with their reputation and value over the standard library, which tends to be a high bar. And libraries made on top of that system are generally pulling all those same, certified standard libraries. So you pull in 3 libraries and only one of those pulls in another third party single library. And you end up with 4 total third party libraries.
Javascript just doesn’t really have a certified standard library.
(This certified standard library doesn’t have to be proprietary. Microsoft has made C# open source, and Linus Torvalds with the Linux Kernel Organization holds ultimate responsibility for the Linux kernel.)
I will almost always choose .NET as my development platform when greenfielding a project for exactly this reason. It’s an incredibly robust standard library that virtually guarantees I won’t need to pull in a litany of additional utility libraries, and I can also expect that what libraries I do choose to bring in are highly unlikely to drag along a ridiculous parade of dependencies.
Do you feel its still worth learning now?
Probably more worth than it was 15 years ago since you’re no longer restricted to Windows and it’s now open source. I’ve heard a lot of people say it’s nicer than Spring for enterprise stuff. Haven’t tried it much myself though. Was fairly easy to set up a simple API, but I then got distracted by other projects.
Yes, it’s incredibly nice, versatile, powerful and efficient. Me being a .net dev since first beta. That said it’s still a GC based runtime if that matters to you. I’m also looking more and more at kotlin as an alternative. If I was to look for a non GC language, I’d go with rust.
I have been wanting to get into coding for fun again and do some pet projects. Bit of a paralysis from choice.
Go with either kotlin or c#, I’d say. Both are high level and easy to start with. If you don’t have a preference, pick one of the two randomly.
Lol, LMAO even
Left-pad tho
Part of the problem is also how many packages people bring in, even for the simplest of things.
There’s a lot of features that make it a better package manager but nobody cares. Every project has hundreds of dependencies and packages use a minimum, not exact, version.
That sounds more like bad practices from the community. It definitely has ways to use exact versions. Not the least of which the lock file. Or the shrinkwrap file which public packages should be using.
Any security system based on expecting good behavior from people is sure to fail. If NPM has no estructural features to enforce safe behaviors, it is vulnerable by default. As no person using it will apply safe practices unless forced to. Specially if the default, easiest, less friction behavior, is inherently unsafe.
I wouldn’t say pulling in higher versions is unsafe unless an attack like this succeeds. Otherwise it’s only an annoyance.
Then you’re waiting forever on vulnerability patches. Especially if there are layers, and each layer waits to update.
Npm probably has the biggest attack surface and many of the libraries hosted there are in extremely widespread use. They’ve taken some steps to mitigate these supply chain attacks, but as we’ve seen with more recent examples, it’s unrealistic to think they can be prevented completely. Most of these attacks use stolen developer credentials, which invalidates almost all potential security measures on the registry side and the best you can hope for is catching a malicious package quickly. To be clear: I think the JS ecosystem is uniquely positioned to be the prime target of supply chain attacks and while that doesn’t excuse the slow implementation of security measures from the npm team, the people arguing that other package managers and registries aren’t vulnerable to this have to be huffing fumes.
That’s fair, I won’t pretend pypi/pip and running uvx is much safer than npx.
But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?
I’ve taken a near zero dependency policy on my personal projects regardless, and now I run most code in containers to sandbox it.
I’m guessing things were working out pretty alright, even with the insane amount of dependencies per project. The awareness and the increasing frequency of supply chain attacks is relatively recent for npm. But who knows, maybe the tech giants in control of the web standards are happy to keep using their own vendored registries.
If you’re asking why there isn’t one shipped with JS, the answer is because JS is built for the web, and the “don’t break the web” rule makes changing things in JS hard, as well as browser devs pushing back hard on anything that increases install size.
If you’re asking why as a community, we haven’t agreed on a single package to be a stdlib - lodash.
As someone completely unfamiliar with the JavaScript mess, are these security issues specific to npm the actual repository or npm the package manager?
If it’s the latter, does using something else like yarn or bun instead help?
I think npm allows installation scripts which do make this worse, as a package can run arbitrary command at install time.
Npm has gotten a few config options that prevent this behaviour. We can only hope that they will become the default eventually.