Your Cloud Vendor Trusted the Wrong Identity. 5,000 Dropbox Accounts Paid the Price.

Nobody guessed a password. Nobody cracked encryption. Nobody ran a sophisticated zero-day exploit.

Attackers accessed 5,000 Dropbox accounts for 17 straight days simply by exploiting a broken handshake between two vendors that were supposed to trust each other.

That is the Dropbox-Lenovo SSO breach, disclosed September 1, 2026. And if your organization uses any kind of single sign-on, third-party identity provider, or cloud-to-cloud integration — this story is about your business too.

What Happened

Dropbox partnered with Lenovo as an identity provider, allowing users to log in to Dropbox using their Lenovo ID credentials through a standard SSO (Single Sign-On) process. On the surface, this is a convenience feature. In practice, it became an unlocked side door.

Here is how the attack worked, step by step:

An attacker compiled a list of email addresses — the kind that flow freely from data breach repositories, LinkedIn, and public customer lists. They then registered a Lenovo ID account using a victim's email address. The critical failure: Lenovo's email verification process had a flaw that allowed registration without actually confirming control of that email inbox. No phishing required. No inbox access needed.

With a fraudulent Lenovo ID registered under the victim's email, the attacker clicked "Continue with Lenovo" on Dropbox. Lenovo's authorization server issued a valid-looking token. Dropbox accepted it — because Dropbox trusted Lenovo — and opened the account. No password prompt. No step-up verification. No "link this new identity?" consent screen.

The attacker was inside. And they stayed inside for 17 days, from August 4 to August 21, before Dropbox identified the unauthorized access.

Files were viewed or downloaded in roughly 1,500 of the 5,000 affected accounts. The 10-day gap between when Dropbox discovered the breach (August 21) and when they began notifying affected users (August 31) is its own concern.

The Core Problem: Trust Without Verification

This attack exploited something fundamental — and something most business leaders have never had reason to question.

When you enable SSO between two platforms, you are establishing a chain of trust. Platform A trusts Platform B to verify who someone is. Platform B vouches for the user. Platform A opens the door. That chain is only as strong as its weakest link.

In this case, the weak link was Lenovo's email verification. But here is what matters: Dropbox also failed. They accepted a new identity credential without requiring the account's actual owner to confirm the linkage. That step-up verification — "we see a new identity provider connecting to your account; please confirm with your existing password" — was simply absent.

Two vendors. Two failures. 5,000 victims.

This is the hidden risk inside every SSO integration your business uses. Every vendor you've granted the ability to authenticate your users is a link in that chain. If you have not audited those links recently, you don't know how many unlocked side doors you have.

Why No MFA Made It Worse

Every single one of the 5,000 compromised accounts had one thing in common: multi-factor authentication was not enabled.

That single missing layer would have blocked this attack entirely, even with the Lenovo verification flaw still in place. An attacker who creates a fraudulent identity and logs in through a broken SSO flow still cannot pass an MFA challenge that requires the victim's actual phone or authenticator app.

This is not a new lesson. It is the same lesson from 2024, 2023, 2022, and every year before it. MFA is not optional. It is not a nice-to-have feature for enterprise customers. It is the minimum baseline for any account that holds business data.

If you have employees using Dropbox, Google Workspace, Microsoft 365, Salesforce, or any other cloud platform without MFA enabled, they are operating with a gap that attackers actively look for.

The Third-Party Integration Audit Your Business Needs

Most organizations have accumulated cloud integrations the same way they accumulate conference lanyards — one at a time, without a master inventory, until you can't remember where half of them came from.

Every SSO linkage, every OAuth connection, every "Continue with [Vendor]" integration in your environment is a potential side door. Some of those integrations were set up by IT years ago. Some were set up by individual employees without IT involvement. Some connect to vendors whose security practices you've never reviewed.

Here is what a basic integration audit looks like:

First, build the inventory. For each major platform your organization uses, identify every external identity provider and OAuth application authorized to access it. Dropbox, Salesforce, GitHub, Google Workspace, and Microsoft 365 all provide this view in their security or admin consoles.

Second, apply the "do we still need this?" test. Integrations accumulate over time. Vendors change. Employees leave. Projects end. Every integration you no longer actively need is a risk you're carrying for no benefit.

Third, verify MFA coverage. This should be policy, not preference. Enforce it at the platform level so individual employees cannot opt out.

Fourth, check your breach notification contracts. When a third-party identity provider or integration partner discovers a vulnerability affecting your accounts, how fast are they required to notify you? The Dropbox-Lenovo situation exposed a 10-day gap between breach discovery and user notification. Your vendor contracts should define these timelines explicitly.

The Broader Pattern

The Dropbox-Lenovo breach did not happen because attackers were unusually sophisticated. It happened because two organizations built a trust relationship without adequately securing the verification layer that relationship depended on.

This pattern shows up repeatedly across the breach landscape. The Thomson Reuters C-Track breach this month exposed sealed court records through a vendor's cloud environment — courts that did nothing wrong paid the price. The EY breach in July came through a third-party IT service management platform. The Accenture breach in July exposed client credentials through the consulting firm itself.

In every case, the organization that suffered was not the one that failed. They trusted a partner, and the partner's security gap became their problem.

You cannot audit your vendors' internal security practices in real time. But you can control what they are authorized to access, how that access is verified, and how fast you will know when something goes wrong.

Three Questions for Your Leadership Team

First: Which identity providers are authorized to authenticate your employees into cloud platforms — and have you reviewed each of those integrations in the past 12 months?

Second: What percentage of your employees have MFA enforced across every business-critical cloud platform? If the honest answer is "I'm not sure," that is your starting point.

Third: Do your vendor contracts specify breach notification timelines? The gap between "we discovered the breach" and "we told you" is time attackers spend inside your data.

These are not technical questions. They are leadership questions. The answers determine how many unlocked side doors your business is carrying right now.

TrustPoint Cyber helps organizations build identity security programs that account for the full chain of trust — not just your own systems, but every vendor you've granted the ability to vouch for your users. If you're not sure where your integration inventory stands, that's exactly where we start.