The Password Manager Situation Is Crazy

People are using password managers now more than ever. And overall, that's a good thing because humans suck at creating strong, unique passwords. But the Bit Warden CLI incident is a reminder that password managers are software and software has a supply chain. In this case, attackers did not crack Bit Warden's vault encryption or dump everyone's save passwords, but they were able to compromise the npm distribution path for the Bit Warden command line tool. Which means the real victims in this case were mostly developers and automation systems that installed one poison CLI package to steal developer credentials that could be used later on to compromise other services, especially if those services are maintained by developers that don't hear about this issue and take the proper remediation steps to refresh all of their keys. To understand the Bit Warden compromise, we have to start with Checkex MarkX, which is an application security company. Its platform is used to scan code, dependencies, containers, and help reduce security risk inside of developer workflows, and CI/CD pipelines, which means checks tools often run in exactly the places that attackers want access to the most, like source repos, IDE extensions, build systems, and GitHub actions, which is the specific vector that led to the Bit Warden compromise. The incident started on March 23rd, 2026, where Checkex Marks suffered a compromise connected to the Trivy supply chain attack, which Cexmarks believed may have allowed attackers to harvest credentials and gain unauthorized access to its GitHub repositories. Then a second attack occurred on April 22nd where checks marks, VS Code extension, developer assist extension, and public a GitHub action were compromised. Those compromised GitHub actions allowed the hackers to pull data like GitHub tokens out of the workflows of the developer teams that were using the compromised actions. So a GitHub action is not just some passive dependency. It is code that runs inside your build pipeline. And if a trusted action is compromised, the attacker may be able to execute code inside workflows that build, test, publish, or deploy software. And depending on how the workflow is configured, that runner may have access to GitHub tokens, npm publishing permissions, cloud credentials, environment variables, and other secrets. According to Step Security's analysis, the attackers compromised a Bit Warden engineer's GitHub account, modified the CLI publishing workflow, and abused the trusted npm publishing path to push the malicious Bit Warden CLI package, which was distributed through npm between 5:57 p. m. and 7:30 p. m. Eastern time on April 22nd, 2026. So if you were unlucky enough to install Bit Warden CLI through npm during that 90minute time frame, you would have received a malicious package that conducts a multi-stage attack where first it triggers a script called BW setup. js. That script would install bun and then inside of bun run an offuscated stealer script called BW1. js JS which would do some fingerprinting to see what OS you're running and what API keys you have SSH keys and tokens that you have for stealing and then send those off to the hackers. Now the scope of users affected is fairly narrow. On Bit Warden's community forum, one of the moderators estimated that in the 90minute window of compromise only about 334 downloads of the malicious Bit Warden CLI 2026. 4. 0 zero package occurred. Now, obviously, 334 downloads doesn't necessarily translate to 334 compromised users, but any users that were affected could be considered highv value targets because presumably these users are developers, CIS admins, DevOps, CI/CD runners that are working in some kind of organization that's distributing some kind of software to clients or maintaining a service that customers are paying for. So, if these users unintentionally introduce a stealer malware into their production systems, then the supply chain attack could continue to affect the software that they're all working on. And then if that software is a dependency for another piece of software, the supply chain attack just continues going on and on until eventually a service that a lot of people depend on is compromised in a severe way. And this is why with supply chain attacks, we basically get the same kind of story over and over again where a dependency of another dependency is compromised. And when the infiltration isn't found quickly like it was here, the downstream effects are devastating. So, in order to protect yourself from these kinds of attacks, the first thing that you should do is stop treating package managers like their magic truth machines, especially if you're using npm, which itself has a massive dependency chain and a lower barrier to

entry for these kinds of attacks. Especially in situations where you're installing something that has high security sensitivity, like a password manager, compare the version of that password manager that you're downloading from npm against the vendor's official release channels before installing it. Bit warden CLI can be installed through multiple different ways. Native executables, npm, chocolaty, snap, and flatpack. And Bit Warden's documentation also says that its GitHub build pipeline creates a Shaw 256 checksum file for the CLI downloads. So if npm suddenly has a new version, a much newer version, but the GitHub release, the checksums, the change logs, snap, homebrew, and etc. but do not line up yet. That mismatch should make you stop and investigate before installing it on a machine that contains your developer secrets. Another security process that kind of seems unintuitive, but actually is somewhat effective at mitigating these supply chain attacks is to just delay updates to software, especially when the update doesn't actually contain any critical security fixes for anything. Because these supply chain attacks have become so common, a lot of organizations have started to stagger updates to their software, um especially in cases where again there's no major security fixes. It's just like a feature update. So they'll stay on a previous version of software for a couple of weeks or more just to sort of wait for the dust to settle and see like, okay, is there going to be some major compromise of this new version of software? And then if it doesn't, then they'll go ahead and update. And since this particular hack affected a password manager, it's also worth mentioning the offline password managers like KeyPass XC. Now, this isn't necessarily a magic shield. I mean, you guys know that I'm more in favor of offline self-hosted password managers versus the online centralized one. Um, but still at the end of the day, KeyPass XCE is a piece of software and literally any piece of software could fall victim to a supply chain attack. But because it is self-hosted and offline, your individual KeyPass XC vault is not part of a giant hosted, you know, centralized password manager target that many different organizations depend on. and it's not normally being pulled into build systems through npm. So, because it's decentralized, because each keypass XC vault is kind of, you know, its own thing in every different organization, um, and because it's less mainstream, it's not as high value a target as something like Bit Warden. But again, investigating and verifying the critical software that you're using in your organization is the best thing that you can do to not fall victim to these kinds of attacks. If you enjoyed this video, please like and share it to hack the algorithm. And check out my online store, bass. win, where you can buy my awesome merch and accessories for your phone or laptop. 10% storewide discount when you pay with Monero XMR at checkout. Have a great rest of your day.