Dropbox Let Hackers In Without the Password — Lenovo ID Was Enough
- The Mess: Attackers abused a broken Lenovo ID email-verification flow to enter Dropbox accounts without knowing the victims’ passwords. Around 5,000 accounts were compromised between August 4 and August 21.
- The Damage: Files were viewed or downloaded from some accounts, turning a forgotten SSO integration into a direct path around Dropbox authentication.
- The Fix: Dropbox killed the Lenovo ID integration, expired affected sessions and now requires the native Dropbox password before Lenovo ID authentication can work.
The password was fine.
That was the problem.
Attackers did not need to steal it.
Dropbox disclosed that roughly 5,000 accounts were accessed during an attack that ran from August 4 through August 21, 2026. The entry point was a legacy integration connecting Dropbox authentication with Lenovo ID.
The weakness sat in the identity chain.
Lenovo’s registration process could be abused to create a Lenovo ID using another person’s email address without properly proving control of that mailbox.
The attacker could then present that fraudulent Lenovo identity to Dropbox.
Dropbox trusted it.
Game over.
The SSO Trust Was the Real Vulnerability
Dropbox allowed users to authenticate through Lenovo ID as an identity provider.
Normally, that is supposed to work like this:
You prove who you are to Lenovo.
Lenovo vouches for you.
Dropbox trusts Lenovo.
The problem was that the first step could be forged.
An attacker could register a Lenovo ID using the target’s email address. The attacker did not need the victim’s Dropbox password and, according to the incident details, did not even need to have access to the victim’s mailbox.
The fraudulent Lenovo identity was then presented to Dropbox.
Because the email address matched an existing Dropbox account, Dropbox accepted the identity and created an authenticated session.
The password never entered the equation.
Around 5,000 Accounts Were Hit
Dropbox identified approximately 5,000 compromised accounts.
The company found evidence that files were viewed or downloaded from a portion of those accounts, while other accounts were accessed without evidence of file activity.
The attack therefore was not just a theoretical authentication bypass.
Someone actually used it against real Dropbox accounts.
The affected accounts also shared another important weakness: they did not have Dropbox two-factor authentication enabled.
That second factor could have stopped the attack even after the fraudulent Lenovo identity was accepted.
This Wasn’t a Dropbox Server Break-In
There was no need to compromise Dropbox’s storage infrastructure.
There was no password cracking.
There was no ransomware.
There was no spectacular zero-day.
The attacker abused something far more mundane: trust between identity systems.
Lenovo said the issue involved a legacy integration with Dropbox that could be abused to improperly authenticate certain Dropbox accounts.
That distinction matters.
Companies increasingly connect services through SSO because it makes authentication easier for users and administrators.
But every external identity provider becomes another security boundary.
If one side says “this user owns this email” and the other side blindly accepts that assertion, the security of both systems becomes dependent on the weakest verification step.
Dropbox Cut the Wire
Dropbox responded by terminating sessions authenticated through Lenovo IDs and disabling the vulnerable authentication path.
The company also changed the login flow so that a Dropbox password is required before Lenovo ID can be used for authentication.
That effectively restores a second proof of ownership to the process.
The affected sessions were invalidated, removing the attacker’s existing access.
Users who received a breach notification should also enable two-factor authentication and review account activity.
The Ugly Lesson About Federated Identity
SSO is convenient.
It is also incredibly good at hiding where authentication actually happens.
A user sees a Dropbox login.
Behind the screen, Dropbox may trust Google, Microsoft, Okta, Apple, Lenovo or another identity provider.
That creates a chain.
If any link incorrectly validates an identity claim, the relying service can end up granting access to the wrong person.
The victim does not necessarily do anything wrong.
Their password can be unique.
Their password can be 30 characters long.
Their password can be protected by a password manager.
It does not matter if the attacker gets authenticated through another trusted path.
That is exactly why this incident deserves attention beyond the roughly 5,000 affected accounts.
Bugstoday Opinion
The worst part of this breach is how boring it looks.
Nobody needed to crack AES.
Nobody needed a kernel exploit.
Someone registered an identity with somebody else’s email address and another system trusted it.
That’s it.
The security boundary was not the password.
It was the assumption that another company had already checked who owned the email address.
That assumption survived long enough to become an attack path.
Bugstoday verdict: If your SSO provider says “this is the user,” your application still needs to know why it should believe them.
Sources:
- Dropbox
- Lenovo
- Reuters
- Dropbox Security Documentation
- OpenID Foundation
