How a Lenovo ID Flaw Gave Hackers Access to About 5,000 Dropbox Accounts

Dropbox said hackers accessed about 5,000 accounts through a flaw involving Lenovo ID, its third-party single sign-on (SSO) integration. The unauthorized access took place from August 4 through August 21, 2026. Files were viewed or downloaded in fewer than one-third of the compromised accounts, according to reporting citing Dropbox. 146

The incident mattered because attackers apparently did not need victims’ Dropbox passwords—or access to their email inboxes. Instead, they abused the way the two companies’ identity systems treated an email address as proof of account ownership.

How the Dropbox account takeover worked

The attack chain appears to have involved three steps:

1. An attacker registered a Lenovo ID using another person’s email address.
2. A defect in Lenovo’s email-verification process allowed that identity to appear valid even though the attacker did not control the inbox.
3. Dropbox’s legacy SSO integration matched the email address in the Lenovo identity assertion to an existing Dropbox account and granted access without requiring the account’s existing Dropbox password. 3511

That means the attackers did not have to break Dropbox’s password system or defeat email security. They exploited the trust relationship between the identity provider—Lenovo ID—and Dropbox, the service relying on that identity claim.

Why multi-factor authentication mattered

The affected accounts were linked to Lenovo IDs but did not have Dropbox multi-factor authentication enabled. 11012

In a federated-login flow, a successful third-party sign-in can establish a session at the relying service. Dropbox MFA would have added another Dropbox-controlled verification step after the Lenovo assertion, making a fraudulent Lenovo identity insufficient on its own. This is why the incident disproportionately affected accounts without two-step verification rather than demonstrating that MFA itself was bypassed. 1015

What hackers accessed

Dropbox said attackers viewed and downloaded content stored in affected accounts. Public reporting indicates that files were accessed in fewer than one-third of the roughly 5,000 compromised accounts. 145

The available reports do not establish a single file type, total download volume, or common level of sensitivity across victims. Some users were told that Dropbox’s logs showed unauthorized account access but no evidence that their files had been viewed or downloaded. 2

What affected users and researchers noticed

Some affected users reported unfamiliar Lenovo IDs connected to their email addresses. Security researcher Yoni Levy shared a copy of a Dropbox notification describing unauthorized access during the August 4–21 window and identifying the Lenovo SSO issue. 23

Reports also described login activity associated with Dublin. Those observations are consistent with fraudulent identity-provider accounts being used as the entry point, although they do not by themselves prove where every attacker was located or that every affected account followed an identical sequence.

When Dropbox notified users and regulators

Dropbox began notifying affected users around August 31 and September 1, after identifying unauthorized access. The company also said it notified data-protection regulators. 346

Dropbox’s reported response included ending affected sessions, removing or decoupling Lenovo account links, advising users to change passwords and enable two-step verification, and restricting or adding safeguards to the affected login path. 101230

How responsibility was divided between Dropbox and Lenovo

The breach was a shared-system failure rather than a straightforward compromise of only one company.

• Lenovo’s apparent failure: Its legacy identity flow reportedly allowed an attacker to create a Lenovo ID using an email address they did not control. The problem was insufficient proof of email ownership. 3512
• Dropbox’s apparent failure: Dropbox treated the external Lenovo assertion as sufficient to connect to an existing Dropbox account, without demanding proof through an existing Dropbox credential, reauthentication step, or stronger account-linking process. 3911
• Both companies’ response: Lenovo characterized the issue as involving a legacy integration and said it had addressed the relevant verification problem. Dropbox said it detected and remediated the issue, ended sessions, changed the affected integration, and notified users and regulators. 101214

The distinction is important. Lenovo’s verification weakness created a false identity claim, but Dropbox’s account-linking logic determined whether that claim could unlock an established cloud account.

What happened to Dropbox shares?

The breach disclosure was followed by an after-hours decline in Dropbox shares, but the exact size of the move is unclear from the supplied reporting.

A Reuters report cited by several outlets described a decline of roughly 2.4% in extended trading, while Investing.com reported a 1.8% after-hours fall. 69 Another report said the stock dropped by more than 6%. 8 The available evidence does not verify the specific 6.6% figure, which may reflect a different market reference point or session.

The broader lesson for federated identity

An email address is an identifier; it is not automatically proof that the person presenting it controls the mailbox or owns the account associated with it.

Federated login reduces friction by allowing one service to authenticate through another. But that convenience creates risk when a relying party:

• accepts an identity provider’s email claim without independent verification;
• automatically links a new third-party identity to an old account;
• bypasses an existing password, MFA challenge, or verified recovery channel; or
• treats an account-linking change as an ordinary sign-in rather than a high-risk security event.

A stronger design would require explicit proof from the existing account holder before attaching a new identity provider. That could include reauthentication, a verified recovery channel, or phishing-resistant authentication. The Dropbox incident shows why identity-provider trust and account linking deserve the same scrutiny as passwords: a weakness in one system can become an access path into another.