Between August 4 and August 21, roughly 5,000 Dropbox accounts were accessed by attackers who never once tried a Dropbox password. They didn’t need one.
Dropbox disclosed the breach on September 1, tracing it to a flaw in Lenovo’s identity verification process. Dropbox lets users sign in with a “Lenovo ID” as an alternative to a native password, a federated login convenience built into a legacy integration between the two companies. The problem: Lenovo’s email verification step didn’t actually confirm that whoever was registering a new Lenovo ID controlled the email address they claimed to. An attacker could create a Lenovo ID using a victim’s email, and Dropbox would treat that new identity as sufficiently proven, because as far as Dropbox’s systems were concerned, Lenovo had already done the verifying.
No password guessing. No phishing page. No malware. Just a gap in a trust relationship that had been quietly sitting there for years.
What actually happened
The mechanics are worth understanding because they’re not exotic. Dropbox’s SSO integration with Lenovo assumes that if Lenovo says an email address belongs to a given identity, that’s good enough to grant access to the Dropbox account tied to that same address. Attackers exploited a weakness in how Lenovo verified new account registrations, letting them stand up a Lenovo ID for an email they didn’t own, then use that fabricated identity to walk straight into the matching Dropbox account.
Dropbox says fewer than a third of the affected accounts, somewhere around 1,500, had files actually viewed or downloaded during the three-week window. The rest were accessed but, as far as the company can tell, not rifled through. Every single compromised account shared one trait: none had two-factor authentication enabled. Dropbox has since ripped out the Lenovo ID integration entirely, expired every session that came through it, and now requires a native password on every login, no exceptions.
Why this wasn’t really a “Dropbox hack”
It’s tempting to file this under “Dropbox got hacked” and move on. That framing misses the more useful lesson. Dropbox’s core storage systems were never touched. Lenovo says its own customer accounts were fine too. The vulnerability lived in the seam between the two companies, in an old federated-identity handshake that nobody had gone back to stress-test since it was built.
That’s the pattern worth remembering: SSO and identity-provider integrations don’t fail like traditional breaches. There’s no single company you can point to and say “they got popped.” Instead, trust accumulates between systems over time, nobody owns the relationship long-term, and the assumptions baked into it in year one quietly stop holding by year five. Dropbox called it a “legacy integration.” That’s corporate-speak for exactly this: a connection that shipped, worked, and was then left alone.
What this means for your SSO stack
If your organization has ever bolted on a “log in with X” option, whether X is a hardware vendor, a partner platform, or an old acquisition’s identity system, this is your reminder to go find out how it actually verifies identity on the other end, not just whether it works.
A few concrete moves worth taking this week: audit every federated login option your apps expose and confirm who’s responsible for reviewing it. Require phishing-resistant MFA on any account reachable through SSO, since that single control is what would have stopped this attack cold, according to Dropbox’s own account. And treat “legacy integration” as a red flag phrase, not a shrug: if nobody can tell you the last time an SSO trust relationship was reviewed, that’s the one to look at first.
Key takeaway: This breach didn’t require a zero-day, malware, or even a phished password. It required a stale trust relationship between two identity systems that nobody was actively watching. MFA would have stopped it outright, which is a much cheaper fix than most of the security tooling most companies are already paying for.
Whether it’s a hardware vendor’s login, a partner integration, or something a previous team set up and forgot about, the SSO connections your organization treats as “just working” are worth a second look before someone else finds the gap first.
Have you audited your federated login integrations recently, or is there one sitting quietly in your stack that nobody’s touched in years? Let us know in the comments.
Get Tech Savvy Digest in your inbox
IT news, cybersecurity, and crypto — the signal, not the noise. No spam, unsubscribe anytime.