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, 2026 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 wasn't in Dropbox.
The cloud storage company is emailing users to say an unauthorised party got into 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 into the Dropbox account tied to the same address. No Dropbox password required.
How did the attacker get in without a password?
Dropbox lets you authenticate with a Lenovo ID instead of a Dropbox password, through federated identity: one company vouches to another that you are who you say you are. Lenovo's signup flow didn't properly confirm the person registering actually owned the email address. So the attacker signed up as you, Lenovo said "yes, this is them," and Dropbox opened the door.
This is a classic federation trust failure. The identity provider (Lenovo) verifies weakly; the relying party (Dropbox) verifies nothing beyond the provider's say-so; account takeover falls out the other end. What the post-mortem will say: never let a newly asserted external identity silently bind to an existing local account without re-authenticating through the local credential. Our 24 August story on a critical Keycloak flaw that hands over full account access with no credentials is the same failure pattern wearing different clothes.
Who is affected and what did the attacker do?
Roughly 5,000 accounts were accessed between August 4 and August 21, 2026, per Reuters, and the intruder viewed and downloaded content from some of them. Plenty of affected users never created a Lenovo ID, which lines up with the attacker registering one in their name.
User xaphod posted that they'd noticed Dropbox's login page had started offering "Continue with SSO" for their email despite never signing up with Lenovo. That was the tell.
Lenovo told BleepingComputer the problem was a legacy integration between Lenovo ID and Dropbox, and said its own customers weren't affected. Vendor framing doing what vendor framing does. The verification flaw was Lenovo's; the accounts that paid the price were Dropbox users'.
| Detail | Figure |
|---|---|
| Accounts accessed | ~5,000 |
| Access window | Aug 4 to Aug 21, 2026 |
| Root cause | Lenovo email verification flaw |
| Login method abused | Lenovo ID single sign-on |
What has Dropbox done about it?
Dropbox expired every session authenticated through a Lenovo ID and added a new rule: logging in with Lenovo ID now also requires your Dropbox password. That closes the specific gap. Both companies say they worked together to mitigate the risk once it was found.
Should you be doing anything right now?
If you got a notice from Dropbox, change your password, enable two-factor authentication (a second code from your phone at login), and review your account's recent activity and connected apps. Look at what files were in the account during those August dates and treat them as exposed. If any held payslips, ID scans or contracts, act on that assumption now.
For engineers running products that accept external identity providers: require a local credential before you link any new external identity to an existing account. The Dropbox gap is not exotic; it's the default behaviour of many OAuth and SAML integrations if nobody explicitly adds that check.
