Dropbox via Lenovo ID: How a Third Party's Email Check Became a Password Bypass for 5,000 Accounts

Executive Summary

Between 4 and 21 August 2026 an unauthorised party signed into approximately 5,000 Dropbox accounts without knowing a single password. Dropbox's notification to affected users, sent on or about 1 September, describes the mechanism in one sentence: "an issue with Lenovo's email verification process allowed an unauthorized party to register a Lenovo ID using your email address and then use that Lenovo ID to log into the Dropbox account associated with that email address." Dropbox uses Lenovo Identity Provider Services as one of its sign-in options, a legacy of the two companies' hardware-bundling partnership. The attacker registered Lenovo IDs on victims' addresses, which Lenovo permitted without confirming control of the inbox, then clicked "Continue with Lenovo" on Dropbox, which accepted the assertion and opened the account. Many of the victims had never created a Lenovo ID.

Two failures combined, and the coverage has mostly credited only the first. Lenovo's was the email check. Dropbox's was treating a third party's claim that a person owns an email address as equivalent to that person's Dropbox login, with no password, no second factor and no consent step, for accounts that had never opted into Lenovo sign-in. Dropbox's remediation is the clearest statement of which failure was its own: it expired every session authenticated through a Lenovo ID, severed the affected accounts' links to Lenovo, and now requires the Dropbox password in addition to a Lenovo ID at sign-in. Lenovo says its own customers were not affected and calls the mechanism "a legacy integration between Lenovo ID and Dropbox" that could be used "to improperly authenticate certain Dropbox accounts."

The numbers are Dropbox's, as relayed by Bloomberg and Reuters: about 5,000 accounts accessed; files viewed or downloaded from fewer than a third, roughly 1,500; and none of the 5,000 had two-factor authentication enabled. That last figure is the one that describes the exposure correctly. Dropbox 2FA applies at login regardless of the identity provider, so the attack worked only against accounts that had not turned it on; the population was selected by that absence.

Who the attacker was and what they wanted is not stated by either company, but one victim has described the visit. Jameson Lopp, co-founder of the Bitcoin custody firm Casa, reports that the intruder opened exactly one file in his Dropbox, IMPORTANT.rtf, found it locally encrypted, and left. Several other victims reported suspicious-login alerts around mid-August and noticed that the Dropbox login page had begun offering "Continue with SSO" for their address although they had never linked anything. Reading one file and leaving is not the behaviour of someone harvesting accounts; it is the behaviour of someone looking for a specific kind of document in the cloud storage of people likely to have it. Neither company has said how the 5,000 addresses were chosen.

Verification of Claims

1. Claim: Approximately 5,000 Dropbox accounts were accessed between 4 and 21 August 2026. → Verified as Dropbox's figure → Dropbox notification (dates); Reuters and Bloomberg (5,000), attributed to Dropbox. Dropbox has not published a standalone notice; the figure has not been given directly to other outlets.

2. Claim: The attacker registered Lenovo IDs on victims' email addresses without verifying them. → Verified → Dropbox notification: "an issue with Lenovo's email verification process allowed an unauthorized party to register a Lenovo ID using your email address." Lenovo statement to BleepingComputer confirms an issue in "a legacy integration between Lenovo ID and Dropbox."

3. Claim: Dropbox accepted the Lenovo ID as a login without a password, including for users who had never linked one. → Verified → Notification: "While you may not have an existing Lenovo ID, our investigation determined that…" User reports of "Continue with SSO" appearing for never-linked addresses. Dropbox's fix now requires the Dropbox password with Lenovo ID sign-in, which it did not before.

4. Claim: None of the affected accounts had two-factor authentication enabled. → Verified as reported → The Register, citing Dropbox. Consistent with Dropbox 2FA being enforced at login independent of the identity provider.

5. Claim: Files were downloaded from about 1,500 accounts. → Partially verified → Reuters: the attacker "viewed and downloaded content from some users." The Register: "fewer than one-third." 9to5Mac's update: "roughly 1,500." Dropbox told at least some individual users it found no evidence of file access in their case.

6. Claim: Lenovo customers were not affected. → Verified as Lenovo's statement → Lenovo to BleepingComputer and Reuters. The affected population is Dropbox users whose addresses were not yet registered as Lenovo IDs; someone who already held a Lenovo ID on that address could not have had a second one registered.

7. Claim: The attacker targeted cryptocurrency holders. → Weak evidence → One victim account: Lopp reports the intruder opened only IMPORTANT.rtf and stopped. Crypto-industry outlets led coverage. Neither company has characterised the targeting, and no second victim has described comparable selectivity on the record.

8. Claim: Dropbox's own infrastructure was not breached. → Verified as both companies' position → No Dropbox system was compromised; the authentication path worked as configured. That is the finding, not a mitigation.

9. Claim: The incident lasted 17 days. → Verified → 4 to 21 August inclusive.

Timeline

Attack Anatomy

Federated sign-in, and what it should require

A "Continue with X" button hands authentication to another company. The relying party, here Dropbox, receives an assertion from the identity provider, here Lenovo, that the person in front of it is the owner of a given email address. Two things have to be true for that to be safe: the identity provider must actually have verified the address, and the relying party must decide what an assertion is worth when the user has never previously connected that provider to their account. The first is Lenovo's failure. The second is Dropbox's design.

Stage 1: the Lenovo registration

Lenovo ID is Lenovo's consumer account system, used for its store, support and device services. Its registration flow, in the words of Dropbox's notification, had "an issue with … email verification" that let anyone register an ID on an address they did not control. Lenovo has not described the issue further. Whether the verification step could be skipped, bypassed, or was absent on a legacy endpoint is not public; the statement's reference to "a legacy integration" suggests an older path retained for Dropbox.

Stage 2: the Dropbox login

With a Lenovo ID on the victim's address, the attacker used Dropbox's Lenovo sign-in. Dropbox looked up the account by email and opened it. For accounts that had already linked a Lenovo ID this is the intended flow. For accounts that had not, and the notification says explicitly that many had not, Dropbox performed a first-time link on the strength of the email match alone. The standard safeguard, asking for the existing account's password before binding a new identity provider, was not in place; it is now.

Two-factor authentication would have stopped the login at that point, and did: every one of the 5,000 accounts lacked it.

Stage 3: what was taken

Dropbox says content was viewed or downloaded from fewer than a third of the accounts, around 1,500. Lopp's account is the only detailed description: one file opened, encrypted, abandoned. Several victims were told Dropbox found no evidence of file access in their case. The disparity between 5,000 logins and 1,500 downloads, and the single-file visit, both point to an operator triaging accounts against a target rather than bulk exfiltration.

Stage 4: detection

Dropbox's ordinary new-device sign-in alert fired for at least some victims around mid-August, and some responded by changing passwords and enabling 2FA, which would have ended access for them. Dropbox has not said how it detected the campaign as a whole or on what date; the 21 August end date and the 1 September notification leave an eleven-day gap that neither company has explained.

Threat Actor Profile

• Name / Alias: None. No claim, no leak, no extortion reported.
• Attribution: None by either company.
• Motivation: Not stated. The single documented visit, one file named IMPORTANT.rtf in a Bitcoin custody executive's account, is consistent with a search for stored seed phrases or keys. A 5,000-address list drawn from public sources would fit that reading; so would a purchased breach list.
• Sophistication: Low technical, high leverage. No exploit code, no malware, no phishing: one registration flaw and one trust decision, applied at scale. The selectivity in what was opened suggests an operator with a purpose.
• MITRE ATT&CK techniques (verified on attack.mitre.org, 12 September 2026):
  • T1589.002 Gather Victim Identity Information: Email Addresses
  • T1585 Establish Accounts (fraudulent Lenovo IDs)
  • T1550 Use Alternate Authentication Material (federated assertion in place of credentials)
  • T1078.004 Valid Accounts: Cloud Accounts
  • T1530 Data from Cloud Storage

Technical Indicators

# No indicators have been published by Dropbox or Lenovo.
signals_reported_by_victims:
  - Dropbox "new sign-in" alert from an unrecognised device, 4–21 Aug 2026
  - Dropbox login page offering "Continue with SSO" for an address never linked to Lenovo
  - Lenovo ID registration confirmation for an account the user did not create
affected_population:
  - Dropbox accounts without 2FA
  - email address not already registered as a Lenovo ID
remediation_applied_by_dropbox:
  - all Lenovo-ID-authenticated sessions expired
  - affected accounts unlinked from Lenovo ID
  - Dropbox password now required with Lenovo ID sign-in
ip_addresses: []
domains: []
file_hashes: []

Legal and Regulatory Response

Disclosure. Dropbox notified affected users directly on or about 1 September; it has published no blog post or help-centre notice and gave its figures to Bloomberg and Reuters rather than to the public. Lenovo issued a statement to press. Neither has filed anything ThreatPaper could locate with a regulator.

SEC. Dropbox, Inc. is an SEC registrant. No Form 8-K referencing the incident had been filed as of 12 September 2026. Five thousand accounts out of a user base in the hundreds of millions is unlikely to meet the Item 1.05 materiality threshold.

Data protection. Downloads of user files from ~1,500 accounts across an unknown set of jurisdictions would engage GDPR and UK GDPR notification duties if EU or UK residents are among them. No supervisory authority has commented.

Litigation. No class action identified as of 12 September.

Contractual. The Lenovo integration is described by Lenovo as "legacy." Whether it remains offered on Dropbox's login page, or has been withdrawn, is not stated; Dropbox's remediation added a password requirement rather than removing the option.

Impact Assessment

• Accounts accessed — Reported. ~5,000 (Dropbox via Reuters/Bloomberg).
• Accounts with file access — Reported. Fewer than a third; ~1,500.
• Data taken — Unknown. "Content" viewed and downloaded; no categories given.
• 2FA status of victims — Reported. None enabled.
• Duration — Confirmed. 4–21 August 2026.
• Detection lag — Unknown. Notification eleven days after access ended.
• Root cause, Lenovo — Confirmed. Email verification issue in registration.
• Root cause, Dropbox — Confirmed by remediation. First-time provider link accepted on email match without password.
• Targeting — Reported, one account. Selective file access consistent with seed-phrase hunting.
• Lenovo customers — Not affected, per Lenovo.

Lessons and Defensive Recommendations

For anyone with a Dropbox account, or any account with a "Continue with" button

• Turn on two-factor authentication. It is the single control that separated the 5,000 from everyone else.
• Look at your account's connected sign-in methods and remove any provider you do not use. A linked provider is a second front door with someone else's lock on it.
• Do not keep seed phrases, private keys or recovery codes in cloud storage as readable files. The one documented visit in this incident went straight for a file called IMPORTANT.rtf. If it must be in the cloud, encrypt it locally first; that is what saved Lopp.

For relying parties implementing federated login

• An identity provider's assertion proves what the provider verified, and nothing more. Before binding a new provider to an existing account, require the existing account's credential. Dropbox now does; it should have from the start.
• Treat "legacy" integrations as the highest-risk ones. They were built to a different standard, are rarely re-reviewed, and are still on the login page.
• Alert on first-time provider links, not just new devices. The user who sees "a Lenovo ID was connected to your account" can act; the one who sees "new sign-in from Chrome on Windows" often cannot tell what happened.

For identity providers

• Email verification is the root of everything downstream. A registration that does not prove inbox control should not produce an identity any relying party will honour.

Sources

1. Bill Toulas, BleepingComputer. "Dropbox accounts breached through Lenovo email verification flaw". 2 September 2026. Includes Dropbox's notification text and Lenovo's statement.
2. The Register. "Legacy Lenovo login opens 5,000 Dropbox accounts to attackers". 2 September 2026.
3. 9to5Mac. "Dropbox breach seemingly caused by egregious authentication failure [U]". 2 September 2026.
4. Decrypt. "Dropbox Security Breach: Hackers Access Accounts Through Authentication Flaw". 1 September 2026. Lopp account.
5. Computing. "Thousands of Dropbox accounts breached via Lenovo flaw". September 2026.
6. Dropbox. "Lenovo and Dropbox: A Powerful Partnership"; Dropbox Help, "Lenovo | Dropbox Cloud Storage". Partnership background.
7. MITRE ATT&CK. T1550; T1078.004; T1585. Accessed 12 September 2026.