Vouched For by a Stranger: How a Lenovo ID Flaw Opened 5,000 Dropbox Accounts

Some of the people whose Dropbox accounts were opened between 4 and 21 August had never created a Lenovo ID in their lives. That detail, buried in the notification emails Dropbox started sending at the end of August, is the whole story.

Dropbox confirmed that roughly 5,000 accounts were accessed over those 17 days. The attacker didn't phish anyone, didn't stuff credentials and didn't touch Dropbox's servers. They registered a Lenovo ID using the victim's email address, Lenovo's verification process failed to confirm that the registrant actually controlled that inbox, and Dropbox, which had accepted Lenovo ID as a sign-in option for years, let the new identity in. The notice to customers put it plainly: "an issue with Lenovo's email verification process allowed an unauthorized party to register a Lenovo ID using your email address."

BleepingComputer and TechTimes both report that files were viewed or downloaded in fewer than a third of the affected accounts, and that none of the compromised accounts had two-step verification turned on. Lenovo told BleepingComputer the problem sat in "a legacy integration between Lenovo ID and Dropbox" and that its own customers weren't affected. Dropbox expired every session that came in through Lenovo ID, cut the existing links, and now asks for the native Dropbox password before a Lenovo login completes.

I work on federated identity most days, and I've read a lot of hot takes on this one already. Most of them land on "turn on MFA" and stop. That advice is correct and also beside the point. So instead of another timeline, I want to go through the assumptions this incident broke, because every one of them is sitting in your SaaS estate right now.

Assumption 1: "Our users don't use that provider, so it isn't our risk"

This is the one that should bother security teams most. A Dropbox user who had never heard of Lenovo ID was exposed purely because Dropbox accepted it. The victim didn't opt in. They didn't link anything. The trust relationship existed at the relying party level, and every account on the platform inherited it.

Think about what that means for a company with a few hundred SaaS apps. Each one has its own list of "Sign in with..." buttons, and each button is an identity provider that the vendor has decided to believe. Your users never chose them. Your identity team probably never reviewed them. Some, like Lenovo ID on Dropbox, are old enough that the people who built the integration have moved on.

When I audit a tenant I now ask a blunt question: for each business-critical SaaS app, list every party that can assert "this person is alice@yourcompany.com" and be believed. Most teams can name their own IdP. Very few can name the rest.

Assumption 2: "An email address is an identity"

Strip the incident down and it's a familiar bug class. Dropbox matched an incoming Lenovo identity to an existing Dropbox account by email address. Lenovo vouched for an email address it hadn't verified. Nobody in the chain asked whether the person holding the Lenovo ID had ever proven control of the Dropbox account.

We've been here before. In June 2023 Descope published nOAuth, showing that apps using Microsoft Entra ID sign-in could be taken over because they keyed accounts on the email claim, which a tenant admin could set to anything. Back in 2022, Microsoft researchers Avinash Sudhodanan and Andrew Paverd studied "pre-account hijacking" and found at least 35 of 75 popular online services vulnerable to some variant of it, many through the same gap between "an IdP says this email" and "this human owns this mailbox."

The fix is old and well documented: link accounts on a stable, provider-scoped subject identifier, and require the user to authenticate to the existing account before any new federated identity gets attached. Dropbox's post-incident change, asking for the Dropbox password before a Lenovo login completes, is exactly that control applied after the fact. It's the right fix. It's also a reminder that the right fix was available the whole time.

Assumption 3: "Our MFA covers this"

Dropbox says two-step verification would have provided another barrier, and none of the 5,000 had it. Fine. But I'd push back on how teams read that line.

In a lot of SaaS products, the MFA you enforce applies to the native login. Federated logins hand the authentication decision to the external IdP, and the relying party trusts whatever that IdP says it checked. Whether a second factor gets layered on top depends on the vendor, the plan tier and sometimes on settings nobody has looked at since onboarding. In the Dropbox case, it happened to help. In the next case, it might not.

Here's the edge case I see most in real environments: an organisation enforces SSO through its own IdP with strong MFA, feels covered, and leaves the personal-account social login options switched on because "nobody uses them." Then a contractor signs up with their work email through a consumer provider, and you now have two doors to the same account, one of which you don't control. The Unit 42 2026 Global Incident Response Report found identity weaknesses played a material role in almost 90% of its investigations, and initial access through identity techniques in 65%. Federated side doors are a big part of how that number stays so high.

Assumption 4: "If it were happening, we'd see failed logins"

There were no failed logins. That's what makes this pattern so quiet.

Credential stuffing produces noise: bursts of bad passwords, lockouts, impossible travel against known users. This produced successful authentications. Every sign-in was, from Dropbox's point of view, a valid federated login from a trusted provider. The attacker presented exactly what the system asked for.

The defender's telemetry for this kind of abuse is thin. You get a sign-in event with a login method field, if your plan exposes it, and a new linked identity, if the app logs account linking at all. Most SIEM content I've reviewed doesn't alert on "new federated identity linked to existing user" because most SaaS audit logs don't make it easy. So the 17-day window here isn't surprising. If anything, it's on the short side for an intrusion that never trips an authentication failure.

We wrote about a related blind spot in the Gyazo breach analysis: once an attacker holds a valid session or a trusted identity, password resets and failed-login alerts simply don't apply to them. The Lenovo ID path is the same shape. The attacker never needed the password, so nothing that watches the password ever fired.

Assumption 5: "Expiring sessions closes it"

Dropbox did the right containment work: kill the Lenovo-originated sessions, sever the links, add a password gate. That stops the door. It doesn't undo what came through it.

In fewer than a third of the accounts, files were viewed or downloaded. Think about what lives in a typical Dropbox. Scanned IDs. Tax documents. Exported spreadsheets from finance. And, in the business accounts I've looked at, an embarrassing number of .env files, VPN configs, SSH keys and "passwords.xlsx" synced from someone's desktop. Every one of those is a credential that outlives the Dropbox session. If a downloaded folder held an AWS access key, the attacker's next login is to AWS, not Dropbox, and no Dropbox-side remediation will show it.

That's the part I'd want every affected business customer to chase: inventory what was in the folders that were touched, and rotate anything that looks like a secret. Assume it's in someone else's hands already.

What I'd actually do this week

None of this needs a new product category. It needs someone to own the question.

Map the vouchers. For your top 20 SaaS apps by data sensitivity, list every sign-in method the vendor accepts: native password, your SSO, Google, Apple, Microsoft personal accounts, and any odd legacy partner like Lenovo ID. Turn off everything you don't need. Where you can, enforce SSO-only for your domain so the consumer buttons stop working for corporate addresses.

Ask vendors how they link accounts. One question in the security review: "When an external identity arrives with an email matching an existing account, what do you require before linking them?" If the answer is "nothing, we match on email," you have a nOAuth-shaped risk and should know it.

Log the link, not just the login. If an app's audit log records new connected identities or sign-in methods, route that to your SIEM and alert on it. A first-ever federated login for a user who has only ever used SSO is a strong signal on its own.

Rotate from the blast radius outward. If you were notified, treat the touched folders as a secret leak, not a privacy incident. Keys, tokens and passwords first, documents second.

Where deception fits, and where it doesn't

I want to be careful here, because "honeytokens would have caught it" is the kind of line vendors throw at every breach. Deception doesn't fix a broken email verification flow. Only Lenovo and Dropbox could do that.

What it does give you is a signal on the part that worked so silently: valid authentication against an account nobody should be touching. Two specific setups make sense against this pattern.

First, decoy identities. Create a small number of real-looking accounts in your key SaaS apps, tied to real mailboxes in your domain, with names that fit your org chart and no legitimate user behind them. Nobody has a reason to sign in to them. If the audit log ever shows a successful login, through any method, that's a true positive with no tuning required. An attacker running a Lenovo-style takeover across a list of your employees' addresses would hit the decoy at the same rate as anyone else, and the decoy is the one account where you're guaranteed to notice.

Second, decoy secrets inside the storage itself. Plant fake cloud keys, a fake vpn-config and a credentials spreadsheet in shared folders that look like the places real secrets end up. A file download in the Dropbox log is easy to miss. An attempt to use a planted AWS key, minutes or days later, from infrastructure you've never seen, isn't. This covers exactly the gap I described under Assumption 5: the session is gone, but the loot is still being spent, and the planted credential tells you so. It's the same logic behind our canary-token analysis of the BigBear phishing kit, where the attackers' own code tried to strip canaries out because they work. We cover how these pieces fit together on our solutions page.

There's one more reason I like this approach for identity-federation abuse specifically. The attacker here had a list of email addresses. Where did it come from? Probably old breach data, maybe scraping. Whatever the source, the attack scaled by walking that list. Decoys placed on the list are the cheapest early warning you'll get, because the attacker can't tell them apart from the real ones without tripping them.

The question to bring to your next vendor review

Lenovo called this a legacy integration, and I believe them. That's the uncomfortable part. Nobody designed a hole. Two companies built a convenience feature years ago, one side's verification degraded, and the other side kept trusting it because nothing told it to stop. Your SaaS estate is full of those arrangements, and the passkey rollout lures we tracked last month show attackers are paying close attention to every change in how people sign in.

So pick your most sensitive app and ask it one thing: who, besides us, can tell you who our people are? If the answer surprises you, start there. And if you'd like to see how a decoy identity flags a login that every other control believed, book a Mine2 demo and we'll show you one firing.