A Login Nobody Had to Guess

Dropbox disclosed on September 2, 2026 that roughly 5,000 accounts were compromised because of a flaw in Lenovo's identity system, not in Dropbox's own password check. The access window ran from August 4 to August 21, 2026, before Dropbox caught it. One affected user described the first sign something was wrong: the Dropbox login page began offering a Continue with SSO option for their email, even though they had never created a Lenovo ID.

The mechanism was simple once found. An attacker could register a Lenovo ID using a victim's email address, and Lenovo's verification process did not require that person to prove they controlled the inbox first. Dropbox's own systems, which had integrated Lenovo Identity Provider Services for single sign-on years earlier, then treated that freshly created and unverified Lenovo ID as sufficient proof to unlock the matching Dropbox account. Lenovo said in a statement that once the issue was identified, it and Dropbox worked collaboratively to mitigate the risk.

The Bug Was Never in Dropbox's Own Password

This is the detail worth sitting with: nobody's Dropbox password was guessed, leaked, or reused. The 5,000 affected accounts were not breached because their owners picked weak credentials. They were breached because Dropbox had, at some point, decided to let a second company vouch for who owns an email address, and never revisited whether that company's vouching process was actually reliable.

Two-factor authentication would have stopped every single one of these takeovers, because none of the 5,000 accounts had it enabled. But the more precise lesson is not simply turn on two-factor authentication. It is that a federated login is not a convenience feature sitting beside your real security; the moment you turn one on, the partner's verification quality becomes your product's verification quality, whether you audited it or not.

Every Company That Accepts Sign In With X Has This Question

Dropbox is not an unusually careless company, and this is not a story about one vendor's mistake. It is a story about a category of defect that exists inside every product that has ever added a Sign in with Google, Sign in with Microsoft, or Sign in with a hardware vendor's ID button for convenience. Each of those buttons quietly extends your product's security perimeter to include a system you do not control and rarely re-examine after the integration ships.

The practical test for any owner is specific: for every third-party login your product accepts, can you name exactly how that provider confirms someone owns the email address before it hands your product a verified session? If the honest answer is we assumed they check that properly, that assumption is the entire attack surface, and this incident is what it looks like when the assumption turns out to be wrong.

What Dropbox Changed

Dropbox's fix was structural rather than cosmetic. It expired every existing Lenovo ID session, removed the link between Lenovo IDs and Dropbox accounts entirely, and now requires a user's actual Dropbox password before a Lenovo-linked sign-in can proceed, closing the exact gap that let a freshly created, unverified identity stand in for an already-owned account.

That is the right fix, and it is also the fix that should have been the default from the start: a partner's identity assertion should extend an existing, already-authenticated session, never create a new authenticated session on its own.

Servola Journal

We do this for everyone trying to keep up with what technology is doing to our lives. The people who build it, and the people it happens to. The Servola Journal exists so that what we learn belongs to all of them.

Nobody pays us for this. No ads, no paywall, free to everyone. We just believe that understanding what's happening to all of us shouldn't depend on who can afford to pay for it.

If it gave you something today, tell us to keep going. Follow us, leave a like, or write a positive comment. We read every one, and they are what keeps us going.