Dropbox had 5,000 accounts breached via legacy integration with Lenovo ID

Dropbox confirmed that about 5,000 accounts were compromised in August, with attackers viewing and downloading content stored on the cloud storage platform. The announcement came on Tuesday (September 2, 2026), after Bloomberg reported the attack earlier that same day, according to a Reuters report published by ET Tech.

According to the company, unauthorized access took place between August 4 and 21. Some users received a notification email on Monday informing them that their accounts had been accessed during that period. In fewer than a third of the compromised accounts did attackers actually access files, Dropbox said. The company's shares fell about 2.4% in Tuesday's after-hours trading.

The vector: a legacy integration with Lenovo ID

The point that matters most to those who build software is how this happened. Dropbox told Reuters it identified unauthorized access affecting accounts linked to a Lenovo ID that did not have two-factor authentication (2FA) enabled. Lenovo, for its part, identified a "legacy integration" between Lenovo ID and Dropbox that "could be used to improperly authenticate certain Dropbox accounts."

In other words: an old federated login mechanism (signing into Dropbox using Lenovo ID credentials) allowed accounts to be authenticated without going through the extra security layer that the second factor requires. Where there was no 2FA on the Lenovo link, the gate was left open.

Lenovo stated that its own customers were not affected and that the investigation is ongoing.

Dropbox's response, point by point

The actions taken by the company offer clues as to where the problem was:

• Ended all sessions authenticated via Lenovo ID.
• Removed any link between Lenovo IDs and Dropbox accounts.
• Changed the system to require users to enter their Dropbox password before accessing their account through the Lenovo path, breaking the automatic single sign-on that enabled the abuse.
• Reported the incident to data protection regulators.

The sequence shows that the mitigation was surgical, targeting the federated authentication flow, not a generic password failure across all users. But that doesn't change the message for the rest of the user base.

What this means for developers who use Dropbox

It's worth separating what is fact from the source and what is applied security interpretation. The fact: accounts without 2FA on the Lenovo link were exploited. The obvious takeaway for developers: the second factor is not optional, especially when the account stores things that shouldn't leak.

And that's where the real risk lies for our audience. In practice, Dropbox is often used as an informal repository for artifacts that shouldn't be there:

• .env files and configs with credentials;
• SSH/GPG private keys, .pem, id_rsa;
• database dumps and production backups;
• source code for private projects that never made it into Git;
• API tokens in spreadsheets, PDFs and screenshots.

If any of these were in a compromised account (and remember: attackers downloaded content from some of the accounts), the file leak is only the start, the problem becomes a valid credential circulating out there.

Practical response checklist

Regardless of whether you received Dropbox's email, here's the path that makes sense to follow now:

1. Check whether you received the official notification from Dropbox (also check your spam folder) and review the session history and connected devices on your account.
2. Enable 2FA if it's not already on, preferably with an authenticator app (TOTP) or a physical key, not SMS.
3. Change your Dropbox password and don't reuse it on another service.
4. Rotate every credential that may have passed through the account: API keys, tokens, .env secrets, SSH keys. If you're not sure what was in there, treat it as compromised.
5. Get secrets out of file storage. Secrets belong in a vault (Vault, AWS Secrets Manager, GCP Secret Manager, 1Password, Doppler), not in a synced folder.
6. Review legacy integrations and SSO on other accounts: the vector here was exactly a forgotten old federation. It's worth auditing third-party apps connected to your critical accounts.

What remains unclear

The source does not detail who was responsible, whether the downloaded files are already circulating, or the exact volume of exfiltrated data, beyond the information that files were accessed in fewer than a third of the 5,000 accounts. Lenovo's investigation continues, and as of publication there is no specific mention of impact in Brazil.

The episode reinforces a pattern we've already seen in other leaks: the attack surface is rarely the main system, but rather an old integration, a federated SSO no one reviewed, a link that survived migrations. For anyone maintaining federated identity across services, Lenovo ID here is a reminder that every authentication bridge is also a door, and legacy doors age badly.