An issue in Lenovo's email verification process allowed an unauthorised party to register a Lenovo ID using an email address they did not control. They then used that Lenovo ID to sign in to the Dropbox account belonging to that address.

No Dropbox password was involved at any point.

Roughly 5,000 Dropbox accounts were affected between 4 and 21 August 2026 — seventeen days — and content was viewed and downloaded from some of them. Lenovo's own customers are reported as unaffected.

Neither company's bug, on its own, loses your files

Lenovo's flaw is that its verification did not verify. That is bad, and by itself it gets you a Lenovo ID with somebody else's email on it, which is worth very little.

Dropbox's flaw is subtler and more consequential. Its identity linking trusted Lenovo's assertion that the attacker controlled the email address, without requiring confirmation through the existing Dropbox login. So the question "is this the same person who owns the Dropbox account" was never asked of the Dropbox account.

Put them together and a weak signup form at a laptop manufacturer becomes read access to somebody's documents.

This is the failure mode of federated identity generally: you inherit the account-recovery quality of every provider you accept. Adding a sign-in option is usually treated as a product decision about convenience. It is an authentication decision, and it delegates part of your security to a company whose incentives around signup friction are not yours.

We have written about the three ways "Sign in with Google" fails. This is a fourth, and it is the cleanest illustration yet, because both companies are competent and the flaw lives entirely in the seam between them.

The fix names the design error

Dropbox expired every session authenticated through a Lenovo ID, and now requires the Dropbox password when authenticating with one.

Read that backwards and you have the original defect stated plainly: before, an external identity provider could hand you an existing account with no local proof of ownership at all. The remedy is not a patch — it is a change to what an assertion from a third party is allowed to buy.

Seventeen days, and how it ends

The window ran 4 to 21 August; disclosure came in early September. As with the METR incident where the credential left through the agent, the interesting number is not the count of affected accounts but the gap between access and knowledge.

Both companies say they worked together to mitigate. The investigation is described as ongoing, and the technical mechanism of the Lenovo verification failure has not been published.

What to do

  • Check your Dropbox security page for sessions or linked accounts you do not recognise, and for file activity between 4 and 21 August.
  • Unlink identity providers you do not use. Every linked provider is an additional way in, and most people have accumulated several without deciding to.
  • If you run a service that accepts third-party sign-in, require a local factor when linking to an existing account. That is precisely the control Dropbox has now added.
  • Do not assume the big name is the risky one. The weak link here was the laptop vendor's account system, not the storage provider's.

What is not established

  • The technical detail of the Lenovo flaw. Neither company has described the verification failure.
  • Who did this, or whether the accounts were chosen or opportunistic.
  • How many of the 5,000 had content accessed, as distinct from being reachable.
  • How the issue was discovered, or by whom.
  • Whether other services accepting Lenovo ID were exposed the same way. Only Dropbox is named.