I understand that this compromise is specific to an update via NPM and further specific to CLI. I have a broader question, even if this was a bit wider of an incident (with broader implications), am I correct in assuming that the passkeys in the vault (or if the compromise involved info stealers on the local machine) would not be impacted (or compromised)? If this scenario above were to happen then the threat is more to the stored passwords? Thanks!
Hello,
Passkeys are protected by their authenticators, which are roughly either a hardware device or a password manager. For hardware devices, the safety comes from the fact that there’s no interface to extract the private keys; all cryptographic operations to authenticate the user happen inside the hardware.
For password managers, the safety depends on how the manager protects its vault and how the user protects the device the manager runs on. The password manager must be able to access the plaintext private key (stored encrypted in the vault) to use it for authentication. If the password manager can access the plaintext private key, capable malware on the device potentially can too. If malware can extract passwords from the manager, we should expect it could extract passkeys as well.
ps: I moved your thread into its own topic to avoid cluttering the other one and to help focus the answers.
Thank you @Neuron5569 - this is as clear an explanation as I have seen. So potentially if there is a malware of some sort is on the user side with the password manager (Bitwarden) open, then the private key is at risk?
I am trying to relate this to the brief period when the CLI was compromised, if let’s say I had downloaded and used this interface (which I didn’t) then my passkeys could have been compromised (assuming I had the password manager open)? So in this case, it wouldn’t matter if the password manager was self hosted or in the cloud?
I am trying to think the steps I would need to take to potentially protect my client side.
And if my Passkeys were in a different password manager wherein I don’t have a native extension interface to the vault but instead use the camera on my phone to scan (and authenticate) the QR code, the malware on my client would be less of an issue?
Thank you again!
No, in the Checkmarx incident, the data stored in user vaults were never at risk, even if the malicious CLI package was downloaded by the user. My understanding is that this infostealer mostly stole things like data stored in environment variables in the command-line environment.
That is correct — your vulnerability to theft of local client data by malware infecting your devices is the same, whether your account is self-hosted or not.
Only if the device that is running your second password manager (for storing passkeys) is immune to malware infection.
Yes, that’s technically true — you have to account for it, and Bitwarden did add protections to reduce memory-dump exposure for locked vaults. Practically, I’m less convinced this is the usual attack path for third‑party password managers. Malware reports typically say the encrypted vault and any persistent state are exfiltrated. If that’s all that happens, then only Bitwarden setups that don’t require the master password on restart are most at risk. If a keylogger is present, it depends on whether it captures your master password (Bitwarden does offer ways to sign in without entering the master password). If memory is dumped or there’s DLL injection (almost never mentioned in reports), then an unlocked Bitwarden client would be vulnerable.
As mentioned by @grb, as far as we know the Checkmarx attacks haven’t involved any password managers at all, including browser password managers, which are usually the first to be targeted by password‑stealing infostealers.
For end consumers, the typical recommendations are keeping devices and software updated, and avoiding malware (pirated software, free mods, cracked paid apps, phishing, scams, etc.). For supply‑chain attacks, one defense is delaying updates (as discussed in the other thread), but that’s not a sustainable recommendation for consumers or non‑automated systems because you risk falling behind on security fixes. Another less certain defense is configuring your AV for protections based on cloud reputation and software age. For npm, there’s a setting to delay updates — a delay of hours would have helped in the Bitwarden Checkmarx incident.
Let’s say you have passkeys stored in a passkey-capable, cross-device auth password manager, in an account you only use for passkeys and only sync to your Android phone. If you use the malware-free phone to authenticate a passkey via a QR code shown on the infected PC, the cryptographic operation to authenticate the credential happens only on the phone, so the private key won’t leak. If the malware on your PC doesn’t affect the components used for passkey authentication, you can’t be phished, but the malware can still steal your session tokens. If the malware can affect the components used for passkey authentication, then you can potentially be phished. So all in all, when malware is involved, your credential (passkey) can’t be stolen, but your authentication may still be stolen.
Thank you @Neuron5569 @grb - very informative
It’s unlikely someone would be able to break into your vault to obtain passwords or passkeys. The more likely possibility is if you accidentally give your vault password/master password to someone, leave it lying around, etc. and someone uses that to access your vault.
This is why MFA is important. If someone were to obtain your master password, they would need a hardware token, authenticator app MFA code, etc. to get into your vault.
Does it 100% eliminate the threat? No, nothing can do that. It makes it very highly unlikely though. Someone would have a better chance of winning a lottery jackpot than accessing the passwords in your vault.