A Lenovo email-verification flaw opened 5,000 Dropbox accounts without a password
On September 2, 2026, Dropbox disclosed that an attacker accessed roughly 5,000 accounts by abusing a flaw in Lenovo’s email-verification process to register fraudulent Lenovo IDs — never needing the victim’s Dropbox password. Audit every identity-federation link you accept and require re-authentication on SSO sign-ins.
September 2, 2026. Dropbox began notifying a subset of users that an unauthorized party had accessed their accounts by exploiting a flaw in Lenovo’s email-verification process. Roughly 5,000 accounts were reached between August 4 and 21, 2026 — and the attacker never needed a single Dropbox password. Why it matters: this was not credential theft. It was a federated-identity failure, a break in the transitive trust between Dropbox and Lenovo’s identity provider.
The weak link was the IdP, not the storage provider
Nothing about Dropbox’s own login was cracked. No password database leaked, no storage backend was breached through a frontal attack. The entry point sat upstream, inside Lenovo Identity Provider Services, a component of the authentication infrastructure Dropbox uses so users can sign in with a verified Lenovo ID.
The mechanism fits in one sentence: the attacker registered a fraudulent Lenovo ID using the victim’s email address, because Lenovo’s email verification did not actually confirm ownership of that address. Once the Lenovo ID existed, it could be used to log into the Dropbox account bound to the same address — no Dropbox password required.
Lenovo later confirmed the issue traced back to a legacy integration between Lenovo ID and Dropbox, one that could be leveraged to improperly authenticate certain Dropbox accounts.
The identity link that no one double-checked
At the center of the incident is a broken account-linking decision. When an IdP such as Lenovo asserts “this user controls this email address,” the relying party — Dropbox, here — faces a choice: trust the assertion, or demand independent proof.
Dropbox trusted it. Its identity-linking flow attached a Lenovo ID to a Dropbox account on the strength of the email address alone, without confirming through the pre-existing Dropbox login method. As a result, the Dropbox password — and any 2FA already enabled — became irrelevant. The attacker walked in through the SSO door, not the front door.
That is the part most teams underestimate. Every time an employee clicks “Continue with Google” or “Continue with Apple,” they are delegating proof of identity to a third party. If that party gets email verification wrong, the trust propagates silently down to the final account.
Why email verification is a fragile foundation
The email address plays a role it was never designed for: the universal identity correlator. It is what binds a Dropbox account to a Lenovo ID, and what links dozens of services to one person. Yet “verifying an email” usually means proving you can read an inbox — clicking a received link — not proving who you are.
That distinction is the whole problem. An IdP that concludes “this address is verified” is really issuing an identity assertion on the strength of temporary inbox control. If the verification mechanism has a gap — a reusable link, a predictable token, a missing registration check — the “verified” flag becomes a false credential that propagates to every linked service.
That is exactly what happened here: Lenovo’s email verification failed to attest ownership of the address, yet the assertion still traveled to Dropbox, which accepted it. Federation does not fix an upstream mistake — it amplifies it.
The practical consequence is uncomfortable but clear: when you accept a third-party login, you inherit that third party’s verification bugs as your own — and your incident response has to reach across a vendor boundary to understand what actually went wrong.
Your account is only as strong as the weakest IdP in the chain
The lesson for a security team reaches far beyond Dropbox. Any organization that accepts federated sign-ins inherits a chain of trust in which it controls only one link.
Three structural weaknesses stand out:
- Automatic linking by email. Binding an account to an IdP purely on address match, with no confirmation over the existing channel, turns email into a master key.
- The un-re-verified assertion. The relying service assuming the IdP already validated the address is exactly where the chain snapped.
- The invisible link. Several victims discovered a “Continue with SSO” option they had never configured, on their own login page — evidence a Lenovo ID link had been created behind their back.
A broader pattern is at work. The same class of failure — an upstream IdP trusting an unverified attribute — keeps recurring, because the point of trust drifts further from the account holder while the relying service keeps assuming the upstream did the checking. The fix is architectural, not procedural: bind identity, not an email address.
The warning sign is easy to remember: an SSO option appearing where you never enabled one is a compromise indicator, not a convenience.
What Dropbox and Lenovo did — and what is still missing
Dropbox responded with two immediate fixes: it expired every session authenticated through Lenovo IDs, and it added a requirement that users enter their Dropbox password when authenticating via Lenovo ID. Lenovo said its own customers were unaffected and that the faulty integration was corrected in coordination with Dropbox.
Per Reuters, about 5,000 accounts were accessed, and the attacker viewed and downloaded content from some users. What remains unpublished is the granularity: the exact list of exposed files and the precise duration of each access. For victims, the question is not just “was my account opened,” but “which documents were read.”
There is also an incident-communication lesson. Dropbox notified after the fact, and some users discovered the intrusion on their own by spotting an SSO option they never configured. A proactive notification, paired with a user-visible log of federated sign-ins, would have let victims act far sooner — reset a password, enable 2FA, or at least watch for downloads.
How to audit your own exposure
The incident yields a directly actionable checklist:
- Inventory every federated IdP. List the SAML/OIDC integrations and “Continue with…” buttons accepted by your SaaS apps and internal services.
- Review your linking policy. Find any auto-link-by-email rule and require confirmation over the existing channel (password, 2FA) before creating the link.
- Enforce step-up. On sensitive resources, demand re-authentication or an extra factor even when the session originates from a trusted IdP.
- Watch for unexpected SSO sign-ins. Alert on any new or unknown “Continue with SSO” option for a given account.
- Enable 2FA and review active sessions. If you use Dropbox with a Lenovo ID, check recent sign-ins and revoke orphaned sessions.
Verdict
If your organization runs federated identity — SAML, OIDC, or plain “Continue with…” buttons — the Dropbox/Lenovo incident is your worked example: account security no longer hinges on password strength, but on rigor at the identity-linking layer. Require independent confirmation at every link, enforce step-up for sensitive access, and treat any unexpected SSO option as a red flag. If you don’t use federation, your direct exposure is nil — but the lesson still applies to every SaaS your teams self-provision. Measuring account security by password strength alone is the habit this incident should break: the next breach will walk through the federated door, not the front one.