The 2026 Lenovo ID sign-in flaw: ~5,000 Dropbox accounts entered without a Dropbox password
4–21 August 2026 (disclosed 2 September 2026)
A flaw in how Lenovo verified account-holder email addresses let an attacker register a Lenovo ID on a victim's email, and Dropbox's Lenovo ID sign-in link then trusted that identity without ever asking for a Dropbox password — reaching roughly 5,000 accounts.
What happened
Between 4 and 21 August 2026, an attacker gained entry to approximately 5,000 Dropbox accounts through a flaw in Lenovo's account system rather than Dropbox's own login page. Reporting on the incident converged on the same root cause: an "issue with Lenovo's email verification process" allowed an unauthorized party to register a Lenovo ID using someone else's email address, and because Dropbox's Lenovo ID sign-in option (shown to users as "Continue with Lenovo," per 9to5Mac) linked accounts through that identity, BleepingComputer reported that Dropbox's identity-linking process "trusted Lenovo's assertion that the attacker controlled the email address without requiring confirmation through the existing Dropbox login method" — so the attacker could enter a linked Dropbox account without ever supplying, or needing, a Dropbox password. The incident was first reported publicly by Yoni Levy on X on 31 August 2026, with wider news coverage from BleepingComputer, The Register, 9to5Mac, CyberInsider and Ubergizmo following on 2–3 September 2026.
How many of those roughly 5,000 accounts had files actually touched is where the reporting splits. CyberInsider reported that Dropbox "found no evidence that the user's files were viewed or downloaded" for most of the affected accounts, while The Register reported that "attackers accessed files belonging to fewer than a third" of them. 9to5Mac put a number on that fraction, reporting "files downloaded from around 1,500 of them." Ubergizmo reported that Dropbox's "internal access logs showed no conclusive evidence that stored user files were downloaded or viewed during the intrusions," and described the affected accounts as ones "none of which had enabled multi-factor authentication (MFA)." The Register additionally reported that, according to Dropbox, none of the affected accounts had two-factor authentication enabled, a detail Ubergizmo's coverage corroborates. The file-access figures were not reconciled across the reporting reviewed here: CyberInsider, publishing at 13:35 UTC on 2 September after 9to5Mac and BleepingComputer had already reported "approximately 5,000" accounts, still described the "number of affected users" as "remains unknown" — so the spread reads as outlets working from different Dropbox statements rather than a real disagreement about the underlying count.
Dropbox's reported remediation was to expire "all sessions logged in through Lenovo IDs," to have "severed any link" between the affected accounts and Lenovo, and, in BleepingComputer's paraphrase rather than a Dropbox quote, to add a new login requirement mandating that users enter their Dropbox account password when attempting to use Lenovo ID authentication going forward. As of 5 September 2026, no CVE has been assigned to the underlying flaw, and this archive could not find a public Dropbox security advisory: help.dropbox.com/security/lenovo-id returns a 404, and dropbox.tech/security carries no post about the incident. Reuters reported that "Dropbox said it had reported the incident to data protection regulators," and Investing.com, reporting on Bloomberg's 1 September story, wrote that "Dropbox has since notified regulators and affected users" and that "Dropbox does not expect the breaches to have a material impact on its business, according to Rathschmidt," naming Dropbox spokesperson Tim Rathschmidt. The market reaction was modest: Reuters reported that "Shares of Dropbox fell around 2.4% in extended trading on Tuesday" (1 September 2026), while Investing.com put the after-hours move at 1.8%. Lenovo's own position is known only second-hand, relayed by BleepingComputer, which reported a Lenovo statement that the two companies "worked collaboratively to promptly mitigate the risk" — no direct Lenovo statement was found in the reporting reviewed here.
Impact
The design failure here sits partly on Dropbox's own side of the integration: it was Dropbox's identity-linking code, not just Lenovo's email verification, that accepted a Lenovo-asserted identity in place of a Dropbox password, so a partner's authentication bug became a direct bypass of Dropbox's own login. Because the underlying flaw was in how Lenovo verified an email address rather than in anything the Dropbox account holder did, someone who had never created a Lenovo ID at all could still have had their Dropbox account entered once an attacker registered one against their email. Two-factor authentication is reported, in Ubergizmo's coverage, as a control that stopped the takeover outright for users who had it enabled — meaning any of the roughly 5,000 affected accounts without 2FA had no further backstop once a Lenovo-linked session was granted. And beyond the accounts already contacted, there is no public advisory for anyone else to consult: with no security-advisory page found at Dropbox's usual URLs, the only account of what happened is what individual news outlets pieced together from statements made to them.
Sources
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09