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 ...
It’s not, it’s a problem of every package manager that do not use sources and checksums, like rust and python.
Take a look at this article that does a better job then me at explaining the situation.
17% of the most popular Rust packages contain code that virtually nobody knows what it does
That’s not true at all, the article where he got that information from says:
Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.
So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.
He then lists some ways packages can be maliciously compromised:
Steal credentials and impersonate a dev
Misleading package names
Malicious macros (this one is interesting, had never considered it before)
Malicious build script
And his solutions are:
Bigger std library (solves none of the above)
Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn’t match the source and is detectable)
Decentralized packages (which worsens every security concern)
Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)
Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.
In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.
17%!
Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can’t imagine about the long tail which receives less attention).
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.
There are some good points in it, though I wouldn’t really consider go dependencies all that decentralized in practice and I don’t understand how checksum db will protect against supply chain attacks with stolen credentials, but I admit I haven’t looked into the details.
Yep you’re right, tampering before transmission is still possible. I think I agree with having a strong standard lib helping that considerably.
While the language of the blog is not objective, the “content” was better than expected 😊
Thanks for the link. There have been a few people in this thread making this point, and I was considering asking them to elaborate so that I can gauge what my risk is from using pip for python. I appreciate you providing a resource so I can go learn more about this
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.
It’s not, it’s a problem of every package manager that do not use sources and checksums, like rust and python. Take a look at this article that does a better job then me at explaining the situation.
That article has lots of issues:
That’s not true at all, the article where he got that information from says:
So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.
He then lists some ways packages can be maliciously compromised:
And his solutions are:
Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.
Lmfao
Competent standard lib + decentralized libs + checksum db.
While the article is a bit theatralic, it offers important arguments.
There are some good points in it, though I wouldn’t really consider go dependencies all that decentralized in practice and I don’t understand how checksum db will protect against supply chain attacks with stolen credentials, but I admit I haven’t looked into the details.
Yep you’re right, tampering before transmission is still possible. I think I agree with having a strong standard lib helping that considerably. While the language of the blog is not objective, the “content” was better than expected 😊
Thanks for the link. There have been a few people in this thread making this point, and I was considering asking them to elaborate so that I can gauge what my risk is from using pip for python. I appreciate you providing a resource so I can go learn more about this