Introduction
On June 2, 2026, Dashlane published a terse advisory: fewer than twenty encrypted vaults had been stolen in an attack that took place two days earlier. The scope is narrow — but the advisory leaves unanswered the questions any IT leader asks first. How did a brute-force attack succeed against a service protected by two-factor authentication? What corrective measures were deployed? A vendor's opacity during a crisis is often as telling as the incident itself.
How the Attack Worked
On May 31, 2026, an external threat actor targeted the TOTP second-factor codes on a subset of Dashlane accounts. These six-digit codes offer only one million possible combinations per thirty-second window — a constraint that automated tooling can exploit by cycling through every combination before a code expires.
By registering new devices on the targeted accounts, the attackers triggered vault synchronisation and downloaded the data of fewer than twenty personal-plan users. Dashlane's systems eventually locked the affected accounts automatically, but not before the data had been copied. The vendor states it has no evidence that its own infrastructure was compromised.
What the Advisory Doesn't Say
Three questions go unanswered in Dashlane's communication.
First, why didn't rate limiting block the attack? Any serious 2FA implementation must cap authentication attempts per account per unit of time. Either that mechanism was inadequate, or it was circumvented — and Dashlane explains neither. Second, what corrective measures were applied, and when exactly? The advisory references "actions" without specifying them. Third, how were these accounts selected? Opportunistic targeting and precision targeting carry very different residual risk profiles.
For a CISO or IT manager, these gaps make it impossible to properly assess residual exposure or mount a proportionate response.
The Real Risk: The Master Password Remains the Weak Link
The stolen vaults are encrypted under a zero-knowledge architecture: Dashlane never stores master passwords. Without the master password, the data remains theoretically unreadable.
In practice, the attackers now hold offline copies they can attempt to decrypt without any time or attempt constraints. A master password that is short, reused, or built on a predictable pattern becomes the last line of defence. Dashlane acknowledges this in its own advisory: users with a weak master password face an elevated risk of deferred decryption.
What This Incident Should Change in Your Access Policy
Four takeaways apply regardless of which password management solution your organisation runs:
- Prefer hardware security keys (FIDO2/passkeys) over TOTP codes for critical accounts: they are immune to time-based code brute-forcing because each response is cryptographically bound to the request origin.
- Enforce strict master password complexity in enterprise deployments and verify compliance regularly through a documented, auditable policy.
- Audit the incident notification policy of your critical SaaS vendors before any crisis hits: a vendor unable to clearly describe an attack vector after the fact is a reliable signal of insufficient security maturity.
- Treat vendor security advisories as operational alerts — on a par with your own internal incident escalations — not as communications to file and forget.
The Dashlane incident remains limited in scope. But it reinforces an uncomfortable truth: trust in a security tool must be grounded as much in a vendor's transparency under pressure as in its feature set. And no product brochure can guarantee that.