Dropbox accounts hijacked after attacker abused a Lenovo signup flaw
A weakness in how Lenovo verified email addresses let an attacker create fake Lenovo IDs and walk straight into around 5,000 Dropbox accounts, no password needed.
Key points
- Dropbox is telling users an attacker got into their accounts between August 4 and August 21, 2025 by exploiting Lenovo's email verification process.
- Around 5,000 Dropbox accounts were accessed, and the attacker viewed and downloaded files from some of them, according to Reuters.
- The trick worked because Dropbox trusted Lenovo's word that whoever held a Lenovo ID also owned the matching email address.
- Many victims never had a Lenovo account at all; the attacker registered one in their name using their email.
- Dropbox has killed all sessions logged in via Lenovo ID and now demands a Dropbox password before that login method works.
Someone found a soft edge in Dropbox's login plumbing, and it was not in Dropbox.
The cloud storage company is emailing users to say an unauthorised party got into their accounts by exploiting a flaw in Lenovo's email verification process, first reported by BleepingComputer. The attacker registered a Lenovo ID, which is Lenovo's single sign-on account, using a victim's email address, then used that fresh ID to log in to the Dropbox account tied to the same address. No Dropbox password required.
How did the attacker get in without a password?
Dropbox lets you log in with a Lenovo ID instead of a Dropbox password, through something called federated identity, where one company vouches to another that you are who you say you are. Dropbox trusted Lenovo's assertion. Lenovo's signup flow did not properly confirm the person registering actually owned the email address.
So the attacker signed up as you. Lenovo said "yes, this is them." Dropbox opened the door.
In practice this is a classic federation trust failure. The identity provider (Lenovo) verifies weakly, the relying party (Dropbox) verifies not at all beyond the provider's say-so, and account takeover falls out the other end. The failure mode here is that Dropbox did not require the existing Dropbox password when a new Lenovo ID was linked to an existing account's email. One thing the post-mortem will say: never let a newly asserted external identity silently bind to an existing local account.
Who is affected and what did the attacker do?
Roughly 5,000 Dropbox accounts were accessed, per Reuters, and the intruder viewed and downloaded content from some of them. Access happened between August 4 and August 21, 2025. Plenty of affected users say they never created a Lenovo ID in their lives, which lines up with the attacker registering one in their name.
One user, posting as xaphod, noticed the Dropbox login page had started offering "Continue with SSO" for their email, despite never signing up with Lenovo. That was the tell.
Lenovo told reporters the problem was a legacy integration between Lenovo ID and Dropbox, and said its own Lenovo customers were not affected. The vendor line is doing some work there. The bug was in Lenovo's verification, even if the damage landed in Dropbox.
| Detail | Figure |
|---|---|
| Accounts accessed | ~5,000 |
| Access window | Aug 4 to Aug 21, 2025 |
| Root cause | Lenovo email verification flaw |
| Login method abused | Lenovo ID single sign-on |
What has Dropbox done about it?
Dropbox expired every session that had been authenticated through a Lenovo ID, and added a new rule: if you want to log in with Lenovo ID, you now also have to enter your Dropbox password. That closes the specific gap. The two companies say they worked together to mitigate the risk once it was found.
What should Dropbox users do right now?
If you got a notice from Dropbox, change your Dropbox password, turn on two-factor authentication (a second code from your phone when you log in), and check your account's recent activity and connected apps. Look at what files were in the account during those August dates and assume the attacker saw them. If any of those files held tax records, ID scans or work documents, treat that information as exposed.
Operational takeaway: if your product accepts an external identity provider, require a local credential before you link that identity to an existing account. Trust, but re-authenticate.
