Breach Teardown
What Caused the Dropbox Lenovo ID Breach?
In August 2026, attackers signed in to about 5,000 Dropbox accounts without knowing a single Dropbox password. A legacy integration let users log in with a Lenovo ID, Lenovo’s email verification could be tricked into issuing an ID for someone else’s address, and Dropbox trusted Lenovo’s word that the person owned that email. Federation turned one partner’s verification bug into account takeover.
By Vidyaa Ganesh, Founder, Identara
- Scale
- ~5,000 accounts accessed, Aug 4–21, 2026 (per INCIBE-CERT)
- Attack vector
- Federated sign-in trusted a partner’s unverified email claim
- IAM domains implicated
- CIAM, Security
- Domino controls hit
- 1 of 3
The Incident
What Happened
By early September 2026, Dropbox had notified users that an unauthorized party had accessed their accounts through a sign-in option some of them had never used: several affected users had no Lenovo account at all. Dropbox accepted Lenovo ID as an identity provider, so a user could log in with a verified Lenovo account. Per BleepingComputer’s reporting on the incident, Dropbox’s identity-linking process trusted Lenovo’s assertion that the person controlled the email address, without requiring confirmation through the existing Dropbox login method.
The verification flaw sat on Lenovo’s side. Dropbox’s notice said the issue allowed an unauthorized party to register a Lenovo ID using the user’s email address, and the attacker then used that Lenovo ID to sign in to the matching Dropbox account. Lenovo said the issue related to a legacy integration between Lenovo ID and Dropbox that could be used to improperly authenticate certain Dropbox accounts, and that its own customers were not affected.
According to Spain’s INCIBE-CERT, about 5,000 accounts were accessed between August 4 and 21, 2026. None of them had two-factor authentication enabled, and fewer than a third showed files being viewed or downloaded. Dropbox expired every session authenticated through Lenovo ID, removed the account links, began requiring the Dropbox password for Lenovo ID sign-in, and notified data protection regulators.
Attack Chain
How the Attack Compounded
Each step below marks the AXIS control that failed at that point in the chain, where one applies. Steps without a control marker were outside the victim's direct span of control.
A legacy integration lets Dropbox accept Lenovo ID as a sign-in method, linking accounts to Lenovo identities by email address.
SEC-05
A flaw in Lenovo ID’s email verification lets an attacker register an ID using someone else’s email address, even for people who never had a Lenovo account.
Dropbox accepts Lenovo’s assertion that the email is verified and signs the attacker in to the matching Dropbox account. No Dropbox password is requested.
CIAM-04
The link rests on an email match alone, with no challenge through the existing sign-in method, and none of the affected accounts has two-factor authentication.
CIAM-01
Between August 4 and 21, about 5,000 accounts are accessed; in fewer than a third, files are viewed or downloaded.
Control Mapping
The IAM Controls That Failed
Every failure point below is a capability in the AXIS IAM capability model: the same 3 controls an IAM maturity assessment would have scored before this incident.
| Control | Domain | Capability | How it failed here |
|---|---|---|---|
| CIAM-04 | CIAM | B2B Delegated Administration & Partner Identity | Dropbox delegated the question “does this person own this email?” to a partner and acted on the answer without proof that the person controlled the existing Dropbox account. Federating a partner identity provider means owning the failure modes of its verification, or requiring the existing credential before linking. |
| CIAM-01 Domino | CIAM | Registration & Onboarding | Social and partner login is a registration-and-onboarding feature, and its riskiest moment is attaching an outside identity to an existing account. Dropbox made that link on an email match alone, without a challenge through the existing sign-in method, and none of the affected accounts had a second factor that might have caught it. |
| SEC-05 | Security | Identity Posture & Attack-Surface Management (ISPM) | Lenovo itself called the integration legacy. A sign-in path that could open accounts belonging to people who had never used it, still live and still trusted, is exactly the risky identity-provider setting and attack path that posture management exists to surface and retire. |
The Maturity Lesson
What Would Have Changed the Outcome
The Domino Effect
CIAM-01 is a domino control, and the Dropbox case shows why customer authentication cannot be scored at the login box alone. Every sign-in method a platform accepts is a front door, and the weakest one sets the score. Here the password front door was bypassed through a side entrance that trusted another company’s email check, and no second factor existed to catch it.
The Maturity Level That Mattered
Level 2 on CIAM-01 is registration through email or social login, and this case exposes the requirement hiding inside it: an outside identity should attach to an existing account only after the user proves control through the existing sign-in method. Level 3 is a unified CIAM layer, the natural place to enforce one linking rule across every sign-in method rather than one per integration, and level 4 adds risk-based step-up during registration. At level 2 or 3 on CIAM-04, federated partners are onboarded with explicit trust rules: which assertions are accepted, what proof of existing-account control is required before linking, and how fast a partner can be cut off.
The assessment question for any consumer platform with social or partner login: list every external identity provider that can sign a user in, and for each, say what happens if its email verification is wrong. If the answer is “the account opens,” that provider is part of your authentication stack, whether you assess it or not.
Related Compliance Frameworks
The controls implicated in this breach carry citations in these frameworks within the AXIS bank:
Put a Number on It
What Would a Breach Like This Cost You?
The breach cost calculator turns a failure pattern like the one above into a dollar figure. Set your identity count, pick your industry, give an honest read of your IAM maturity, and see the annualized loss exposure it implies.
Run the Breach Cost CalculatorSources
About This Analysis
This teardown is based exclusively on public disclosures, regulatory findings, and reporting cited above; it makes no claim of insider knowledge about the internal environment at Dropbox. Control mappings express how the publicly documented failure points correspond to capabilities in the AXIS methodology, for educational purposes. AXIS is not affiliated with Dropbox.
More From the Breach Radar
What Caused the Brevo Breach?
SSO invites that crossed tenants, and a hardcoded Cloudflare key
What Caused the Microsoft Midnight Blizzard Breach?
Password spray on a legacy tenant, over-privileged OAuth app
What Caused the Snowflake Customer Breaches?
Years-old infostealer credentials, no MFA on SaaS accounts
Would Your Program Have Caught This?
The 3 controls that failed here are questions in the AXIS assessment. Score your organization against them, and the rest of the bank, in about 20 minutes. No signup required to start.