Une faille de vérification d’e-mail chez Lenovo ouvre 5 000 comptes Dropbox sans mot de passe
Le 2 septembre 2026, Dropbox a révélé qu’un attaquant avait accédé à environ 5 000 comptes en exploitant une faille de vérification d’e-mail dans l’identité Lenovo, sans jamais connaître le mot de passe Dropbox. Auditez chaque liaison de fédération d’identité que votre entreprise accepte et imposez une ré-authentification sur les connexions SSO.
2 septembre 2026. Dropbox prévient une partie de ses utilisateurs qu’un parti non autorisé a accédé à leurs comptes en exploitant une faille de vérification d’e-mail chez Lenovo. Environ 5 000 comptes ont été ouverts, entre le 4 et le 21 août 2026, sans que l’attaquant connaisse le moindre mot de passe Dropbox. Pourquoi c’est important : ce n’est ni du phishing, ni de la force brute, mais une faille dans la fédération d’identité — la confiance transitive entre Dropbox et l’Identity Provider (IdP) de Lenovo.
La brèche n’était pas chez Dropbox, mais chez l’IdP
Dropbox n’a pas été piraté au sens classique. Aucun mot de passe n’a fui, aucun coffre de stockage n’a été vidé par une intrusion frontale. Le point de passage se situait chez Lenovo, plus précisément dans Lenovo Identity Provider Services, un composant de l’infrastructure d’authentification que Dropbox utilise pour laisser ses utilisateurs se connecter avec un Lenovo ID vérifié.
Le mécanisme tient en une phrase : l’attaquant a pu enregistrer un Lenovo ID frauduleux en utilisant l’adresse e-mail de la victime, parce que la vérification d’e-mail de Lenovo était défaillante. Une fois ce Lenovo ID créé, il suffisait de l’utiliser pour se connecter au compte Dropbox associé à la même adresse — sans jamais saisir le mot de passe du compte.
Lenovo a confirmé que le problème venait d’une intégration héritée entre Lenovo ID et Dropbox, exploitée « pour authentifier à tort certains comptes Dropbox ».
Une assertion d’identité que personne n’a re-vérifiée
Le cœur du problème est un défaut de liaison d’identité. Lorsqu’un IdP comme Lenovo affirme « cet utilisateur contrôle bien telle adresse e-mail », le fournisseur de service — ici Dropbox — a deux choix : faire confiance à l’assertion, ou exiger une preuve indépendante.
Dropbox a fait confiance à l’assertion. Son processus de liaison reliait le Lenovo ID au compte Dropbox sur la seule base de l’adresse e-mail, sans exiger de confirmation par la méthode de connexion Dropbox existante. Résultat : le mot de passe Dropbox, la 2FA éventuellement activée, tout est devenu contournable — l’attaquant entrait par la porte SSO, pas par la porte principale.
C’est le point que la plupart des équipes sous-estiment. Quand un employé clique sur « Continuer avec Google » ou « Continuer avec Apple », il délègue la preuve de son identité à un tiers. Si ce tiers se trompe sur la vérification d’e-mail, la confiance se propage silencieusement jusqu’au compte final.
Pourquoi la vérification d’e-mail est un fondement fragile
L’adresse e-mail joue un rôle qu’elle n’a jamais été conçue pour tenir : celui de corrélateur universel d’identité. C’est elle qui relie un compte Dropbox à un Lenovo ID, elle qui sert de clé de rapprochement entre des dizaines de services. Or « vérifier un e-mail » signifie, dans la plupart des implémentations, prouver qu’on peut lire une boîte aux lettres — cliquer un lien reçu — et non prouver qui l’on est.
Cette distinction est le cœur du problème. Un IdP qui conclut « l’adresse est vérifiée » émet en réalité une assertion d’identité sur la base d’une preuve de contrôle temporaire de l’inbox. Si le mécanisme de vérification présente une faille — un lien réutilisable, un jeton prévisible, une absence de contrôle côté inscription —, le statut « vérifié » devient un faux justificatif qui se propage à tous les services liés.
C’est exactement ce qui s’est produit ici : la vérification d’e-mail de Lenovo n’a pas correctement attesté la propriété de l’adresse, mais l’assertion « cet e-mail est contrôlé par l’attaquant » est quand même partie vers Dropbox, qui l’a acceptée. La fédération ne fait qu’amplifier une erreur commise en amont.
Votre compte est aussi fort que le plus faible IdP de votre chaîne
La leçon pour un RSSI dépasse largement Dropbox. Toute entreprise qui accepte des connexions fédérées hérite d’une chaîne de confiance dont elle ne contrôle qu’un maillon.
Trois faiblesses structurelles ressortent de cet incident :
- La liaison automatique par e-mail. Relier un compte à un IdP sur la seule correspondance d’adresse, sans confirmation par le canal existant, transforme l’e-mail en clé universelle.
- L’assertion non re-vérifiée. Le service partant du principe que l’IdP a déjà validé l’adresse est précisément le point de rupture.
- L’invisibilité du lien. Plusieurs victimes ont découvert, sans l’avoir jamais demandé, une option « Continuer avec SSO » apparue sur leur page de connexion — preuve qu’un lien Lenovo ID avait été créé à leur insu.
Le signe avant-coureur est simple à retenir : une option SSO qui apparaît là où vous n’en avez jamais configuré une est un indicateur de compromission, pas un confort.
Ce que Dropbox et Lenovo ont fait — et ce qui manque
Face à l’incident, Dropbox a pris deux mesures correctives immédiates : expirer toutes les sessions authentifiées par Lenovo ID, et imposer la saisie du mot de passe Dropbox lors de toute nouvelle tentative d’authentification par Lenovo ID. Lenovo, de son côté, a déclaré que ses propres clients n’étaient pas touchés et que l’intégration défaillante avait été corrigée en coordination avec Dropbox.
Selon Reuters, environ 5 000 comptes ont été accessibles, et l’attaquant a consulté et téléchargé du contenu chez certains utilisateurs. Ce qui manque encore, c’est la granularité : la liste exacte des fichiers exposés et la durée précise de chaque accès n’ont pas été publiées. Pour les victimes, la question n’est pas seulement « mon compte a-t-il été ouvert », mais « quels documents ont été lus ».
Il y a aussi une leçon de communication d’incident. Dropbox a notifié après coup, et certains utilisateurs ont découvert l’intrusion par eux-mêmes, en voyant apparaître une option SSO qu’ils n’avaient jamais configurée. Une notification proactive, doublée d’un journal des connexions fédérées exposé à l’utilisateur, aurait permis d’agir bien plus tôt — réinitialiser un mot de passe, activer la 2FA, ou au minimum surveiller les téléchargements.
Comment auditer votre propre exposition
L’incident fournit une liste de contrôle directement actionnable :
- Inventoriez chaque IdP fédéré. Listez les intégrations SAML/OIDC et les boutons « Continuer avec… » acceptés par vos SaaS et vos applications internes.
- Vérifiez la politique de liaison. Repérez toute règle de liaison automatique par e-mail et exigez une confirmation par le canal existant (mot de passe, 2FA) avant de créer le lien.
- Imposez le step-up. Sur les ressources sensibles, demandez une ré-authentification ou un facteur supplémentaire même lorsque la session vient d’un IdP de confiance.
- Surveillez les connexions SSO inattendues. Alertez sur toute option « Continuer avec SSO » nouvelle ou inconnue pour un compte donné.
- Activez la 2FA et revoyez les sessions actives. Si vous utilisez Dropbox avec Lenovo ID, vérifiez les connexions récentes et révoquez les sessions orphelines.
Verdict
Si votre entreprise exploite une fédération d’identité — SAML, OIDC ou simples boutons « Continuer avec… » —, l’incident Dropbox/Lenovo est votre cas d’école : la sécurité du compte ne tient plus à la robustesse du mot de passe, mais à la rigueur de la liaison d’identité. Exigez une confirmation indépendante à chaque liaison, imposez le step-up sur l’accès sensible, et traitez toute option SSO inattendue comme un signal d’alerte. Si vous n’utilisez pas de fédération, le risque direct est nul — mais la leçon reste valable pour chaque SaaS que vos équipes autorisent en self-service.