Dropbox Lenovo ID Breach — Kein Passwort für den Einbruch nötig

Ein Dropbox Lenovo ID breach hat rund 5.000 Konten kompromittiert, ohne dass die Angreifer jemals ein Dropbox-Passwort benötigten. Dropbox bestätigte am 1. September 2026, dass ein Fehler in Lenovos E-Mail-Verifizierungsprozess es einer unbefugten Partei ermöglichte, eine Lenovo-ID mit der E-Mail-Adresse eines Opfers zu registrieren und sich dann mit dieser gefälschten Identität direkt beim zugehörigen Dropbox-Konto anzumelden.

Was ist passiert

Dropbox integriert Lenovo Identity Provider Services, damit Nutzer sich mit einer verifizierten Lenovo-ID bei Dropbox anmelden können — eine föderierte Single-Sign-On-Komfortfunktion. Dropbox erklärte, die betroffenen Konten seien über Lenovo-ID verknüpft gewesen und hätten keine Dropbox-Zwei-Faktor-Authentifizierung aktiviert gehabt. Laut Dropboxs Benachrichtigung an betroffene Nutzer „ermöglichte ein Problem in Lenovos E-Mail-Verifizierungsprozess einer unbefugten Partei, eine Lenovo-ID mit Ihrer E-Mail-Adresse zu registrieren“ — ohne dass der Angreifer diese E-Mail-Adresse besaß oder kontrollierte. Der Angreifer nutzte anschließend die gefälschte Lenovo-ID, um sich beim unter derselben Adresse registrierten Dropbox-Konto anzumelden — zu keinem Zeitpunkt war ein Dropbox-Passwort erforderlich. Bemerkenswert: Manche betroffenen Nutzer hatten nie ein Lenovo-Konto, und Lenovo bestätigte, dass eigene Kunden nicht betroffen waren — ausgenutzt wurde allein das Vertrauen, das Dropbox in Lenovos Identitätsaussagen setzte.

Der Vorfall scheint darauf zurückzuführen zu sein, dass Dropbox die Lenovo-ID-Behauptung als ausreichend ansah, um ein bestehendes Dropbox-Konto zu verknüpfen oder darauf zuzugreifen, ohne einen unabhängigen Dropbox-Authentifizierungsschritt zu verlangen. Dies ist dasselbe Schwachstellenmuster wie bei CVE-2026-55075 (Coder) und CVE-2026-14781 (Keycloak) — Relying Parties behandeln eine E-Mail-Adresse als verlässlichen Account-Verknüpfungsschlüssel über eine föderierte Vertrauensgrenze hinweg, statt den Besitz direkt zu verifizieren. Dropbox zufolge fand der unbefugte Zugriff zwischen dem 4. und 21. August 2026 statt. Dropboxs erste Nutzerbenachrichtigung und die spätere Stellungnahme gegenüber Reuters unterschieden sich im Detaillierungsgrad zum Dateizugriff: Die Benachrichtigung gab an, die Logs zeigten keine Hinweise auf Dateizugriffe, während Dropbox Reuters später mitteilte, dass bei weniger als einem Drittel der rund 5.000 betroffenen Konten Dateien eingesehen oder heruntergeladen wurden. Dropbox hat inzwischen alle über Lenovo-ID authentifizierten Sitzungen beendet und verlangt nun auch beim Anmeldeweg über die Lenovo-ID die Eingabe des tatsächlichen Dropbox-Passworts. Für diesen konkreten Vorfall wurde keine CVE-Nummer vergeben.

Warum das wichtig ist

Dieser Dropbox Lenovo ID breach zeigt: Föderierte Authentifizierungs-Komfortfunktionen — „Anmelden mit X“-Integrationen, die an ein bestehendes Login-System angeflanscht werden — übernehmen die Vertrauensannahmen des Partner-Identity-Providers, und diese werden selten mit derselben Sicherheitssorgfalt geprüft wie der primäre Login-Ablauf selbst. Lenovo-Hardware hat eine große installierte Basis in deutschen Mittelstands-IT-Flotten, und Dropbox ist ein gängiges Cloud-Speicher-Werkzeug in denselben Umgebungen; jede Organisation, die jemals eine externe SSO- oder Identity-Linking-Option auf einem internen oder kundenseitigen System aktiviert hat, sollte dies als konkretes Beispiel dafür behandeln, was schiefgehen kann — nicht als abstraktes SSO-Risiko.

Was Sie jetzt tun sollten

1. Erstellen Sie ein Inventar aller föderierten Identitäts- oder „Anmelden mit X“-Integrationen, die auf Systemen aktiviert sind, die Ihre Organisation betreibt oder nutzt, und identifizieren Sie, welche einem externen Identity Provider erlauben, Kontobesitz ohne zusätzlichen Bestätigungsschritt zu behaupten.
2. Prüfen Sie: Verlangt die Relying-Party-Seite (wie hier Dropbox) das eigene Passwort des Nutzers als zusätzliche Bestätigung, oder vertraut sie der Behauptung des Identity Providers ungeprüft?
3. Mitigieren Sie: Wo die Vertrauensbeziehung nicht sofort neu gestaltet werden kann, ergänzen Sie einen verpflichtenden Passwort- oder MFA-Schritt zusätzlich zu jeder föderierten Anmeldung bei sensiblen Konten.
4. Überwachen Sie: Falls Ihre Organisation oder Mitarbeitende Dropbox-Konten mit verknüpften Lenovo-IDs nutzen, bestätigen Sie, dass Sitzungen zurückgesetzt wurden, und prüfen Sie die Aktivitätslogs für den Zeitraum 4.–21. August.

Wenn Sie nicht wissen, ob ein von Ihrer Organisation genutztes System eine ähnliche föderierte Vertrauensschwäche aufweist, behandeln Sie genau diese Unsicherheit als das eigentliche Ergebnis — dieselbe Schwachstellenklasse ist 2026 bereits dreimal bei unterschiedlichen Produkten aufgetaucht.

DIESEC Einschätzung

Föderierte Identität wird als Sicherheitsgewinn verkauft — weniger Passwörter, zentrale Kontrolle. Dieser Vorfall zeigt, was passieren kann, wenn die Relying Party eine Identitätsbehauptung übernimmt, ohne sie über den eigenen Kanal erneut zu verifizieren. Das Muster (Coder, Keycloak, jetzt Dropbox/Lenovo) deutet auf einen wiederkehrenden architektonischen blinden Fleck hin, nicht auf einen einmaligen Herstellerfehler.

Nicht sicher, ob Ihre SSO- und Identity-Provider-Integrationen eine solche Vertrauenslücke haben? Kontaktieren Sie DIESEC für eine schnelle Identity-Architektur-Prüfung.

Quellen: Reuters | BleepingComputer | Cyber Security News
Veröffentlicht: 2026-09-08 | Kategorie: Tägliche News | ~4 Min. Lesezeit