Cloud password managers have become the quiet backbone of modern identity operations. They sit behind admin consoles, DevOps pipelines, procurement portals, finance tooling, and—too often—behind the keys to the kingdom. They are purchased with the promise of simplicity and defended with one sentence that sounds like a guarantee: zero-knowledge encryption.

The ETH Zurich research described in the PDF disrupts that comfort. In a study focused on Bitwarden, LastPass, and Dashlane, researchers uncovered 25 serious vulnerabilities that do not merely “leak” information under rare conditions. Under a fully malicious server threat model, the flaws allow a compromised or hostile backend to bypass confidentiality and integrity expectations, enabling unauthorized access to vault content, silent modifications, and recovery-path takeovers- sometimes after nothing more than a single login, join, or sync action.

In other words: the vault may be encrypted, yet the conversation between client and server can be coerced until the encryption no longer protects what decision-makers believe it protects.

Why CISOs Should Care

Bitwarden, LastPass, and Dashlane collectively represent a massive portion of the password manager market and are embedded deeply in enterprise workflows. The paper’s core insight is not “encryption is broken.” It is far more uncomfortable: protocol design and trust assumptions can nullify strong cryptography.

Most vendors position zero-knowledge as “even we can’t read your data.” ETH’s work challenges the practical version of that claim: If the server is compromised and actively malicious, can it still trick clients into states where the server effectively gains control over vault secrecy or correctness? In many tested scenarios, the answer was yes.

This matters because the malicious server model is no longer hypothetical. We now plan for supply chain compromise, insider threats, coercion, and cloud control-plane incidents as normal risk categories. A password manager provider doesn’t need to be “evil” for the scenario to become real—only breached.

The 25 Attacks: Four Categories That Break Trust

The researchers group the vulnerabilities into four clusters. Reading them as a CISO, what stands out is how often the same architectural sins repeat: unauthenticated public keys, missing authenticated encryption, weak key separation, and backward compatibility pathways that enable downgrades.

1) Key Escrow & Recovery Attacks: “The Back Door That Becomes the Front Door”

Account recovery exists to help legitimate users regain access: yet it also creates the most attractive leverage point for a malicious server. These attacks target flows such as password resets, SSO logins, organization enrollment, and key rotation.

In practical terms, the research shows how a hostile server can use key substitution and unauthenticated key material to position itself as the trusted entity in the recovery or onboarding moment. Once the client accepts the wrong key at the wrong time, “zero-knowledge” becomes irrelevant: the attacker can end up with the means to decrypt the vault, or to control how new keys are generated and applied.

What makes these issues so operationally dangerous is the low interaction requirement. Some scenarios require only a single login, a single join action, or a single dialog confirmation: exactly the kind of routine user behavior that never triggers suspicion.

2) Item-Level Vault Encryption Flaws: When the Vault Can Be Quietly Rewritten

Password managers don’t protect one single blob of data; they protect hundreds or thousands of items, each with metadata, fields, attachments, and sync state. The ETH findings show that when item-level encryption is implemented without strong integrity guarantees, the vault becomes malleable.

That malleability is not theoretical. It can manifest as field swapping, metadata leakage, downgrade of password-hardening parameters, replay of older versions, or subtle manipulations that cause the client to display and use altered content while everything still “looks encrypted.”

This is where the story becomes more than confidentiality. Integrity is the strategic concern. A password manager that can be influenced to modify stored credentials is not just a vault—it can become a distribution mechanism for privilege escalation. If an attacker can steer the client into saving or using manipulated values, the password manager becomes part of the attack chain rather than the barrier against it.

The paper also highlights how weakening KDF settings (the work factor that slows brute forcing) can turn strong master-password protection into something dramatically easier to crack. Even if a company trains users to choose better master passwords, a forced KDF downgrade undermines that investment.

3) Sharing & Organization Exploits: The Blast Radius Becomes Enterprise-Wide

Sharing features are what made password managers “enterprise-ready.” They are also what makes compromise scale.

The ETH research describes how weaknesses in public key authentication and join flows can allow attackers to tamper with organization keys, overwrite shared vault secrets, or inject unauthorized access in ways that appear legitimate to the client.

For a CISO, this is the category that changes the incident math. A single compromised user is bad. A compromised shared vault is catastrophic: because shared vaults often contain the credentials that unlock systems, not just accounts. In many environments, shared vaults hold cloud root keys, automation secrets, privileged service credentials, emergency break-glass accounts, and integration tokens that live far longer than any single user password.

In that context, a sharing compromise is not “password manager risk.” It is enterprise identity risk, directly linked to lateral movement and cloud takeover scenarios.

4) Backwards Compatibility Issues: Downgrades Are Still the Oldest Attack in the Book

Backward compatibility is where security compromises are institutionalized. Systems keep legacy modes to support older clients or older vault formats. Attackers use those modes to force weaker security states.

ETH’s work shows that legacy support can be abused to enable downgrade attacks—pushing clients into insecure encryption modes or disabling protective mechanisms that modern designs rely on. It’s the same structural failure we’ve seen for years in other protocols: if the system must support “old” and “new,” then “old” becomes the attacker’s chosen path unless the downgrade is cryptographically prevented.

For organizations, this category is especially relevant because enterprise environments often contain a long tail of clients: older extensions, older mobile versions, unmanaged devices, contractors, and forgotten endpoints. Backward compatibility risks grow with heterogeneity.

What This Means for “Zero-Knowledge” in the Real World

The study does not argue that password managers are useless. It argues something more precise and more actionable:

Zero-knowledge is not a marketing label you can inherit from encryption alone.
It must be enforced end-to-end by authenticated keys, integrity-protected ciphertext, strict key separation, downgrade-resistant protocol design, and hardened recovery flows.

If any of those are missing, a malicious server can shape reality for the client.

That is the uncomfortable insight: for cloud password managers, the server doesn’t need to “decrypt” ciphertext directly if it can influence key material, change KDF parameters, manipulate sharing keys, or replay crafted vault states until the client itself performs the wrong cryptographic operations.

Disclosure & Vendor Patch Landscape

The ETH Zurich team reports responsible disclosure with staged timelines across vendors and remediation windows. Some mitigations include improved KDF minimums, partial removal of weak legacy modes, and targeted fixes in specific flows. Yet the broader lesson remains: true resilience against malicious servers typically requires architectural hardening, not only patching isolated bugs.

CISO Guidance: What You Should Do Next

Enterprises should not panic but they should recalibrate. Password managers remain useful, but they should be treated as high-value identity infrastructure, not as a simple productivity tool.

A practical path forward is to reduce reliance on any single trust assumption and to design for compromise:

Keep password manager clients aggressively updated. Treat outdated extensions as a risk item, not an inconvenience. Audit organizational sharing: shared vaults should be minimal, segmented, and tied to least privilege. Move Tier-0 and break-glass secrets into stronger enterprise vaulting solutions where integrity and key provenance are tightly controlled. Use hardware-backed MFA and protect recovery paths like production systems because they are.

Most importantly, evaluate vendors not only on encryption claims but on protocol properties: authenticated key distribution, downgrade resistance, item-level integrity, and the security of enrollment and recovery under hostile assumptions.

Closing Thought

Password managers were sold as safes. The ETH Zurich research reminds us they are also protocols. And protocols fail in ways that do not look like broken locks. They fail as quiet, plausible conversations—where the other side lies, and the client believes it.

For CISOs, this is the real takeaway: trust must be cryptographically proven, not assumed—especially when the system in question sits between your organization and its most powerful secrets.