Dropboxは、Lenovo IDとのシングルサインオン（SSO）連携の不備を悪用され、約5,000件のアカウントに不正アクセスがあったと明らかにしました。不正アクセスが確認された期間は2026年8月4日から21日までです。Dropboxによると、影響を受けたアカウントのうち、ファイルが閲覧またはダウンロードされたのは3分の1未満でした。146

今回の特徴は、攻撃者が被害者のDropboxパスワードを知らず、メール受信箱にも侵入していなかったとみられる点です。攻撃者は、メールアドレスを本人確認の根拠として扱う2社の認証システムのつながりを悪用しました。

攻撃はどのように成立したのか

確認されている攻撃の流れは、次の3段階です。

1. 攻撃者が、別人のメールアドレスを使ってLenovo IDを登録する。
2. Lenovo側のメールアドレス確認処理の不備により、メール受信箱を支配していなくても、そのIDが有効なものとして扱われる。
3. Dropboxの旧式SSO連携が、Lenovoから伝えられたメールアドレスと既存のDropboxアカウントを照合し、Dropboxの従来のパスワードを求めずにアクセスを許可する。3511

つまり、Dropboxのパスワード認証を直接破ったわけでも、被害者のメールを乗っ取ったわけでもありません。Lenovo IDを認証する「アイデンティティプロバイダー」と、その認証結果を受け入れるDropboxとの信頼関係が侵入口になりました。

なぜ多要素認証（MFA）が被害を抑えられたのか

被害に遭ったアカウントはLenovo IDと連携していましたが、Dropboxの多要素認証（MFA）が有効になっていませんでした。11012

SSOでは、外部サービスでのログインが成功すると、連携先のDropboxでもログイン済みセッションが確立される場合があります。DropboxのMFAが有効なら、Lenovo IDからの認証情報に加えて、Dropbox側が管理する追加確認が必要になります。そのため、偽造されたLenovo IDだけではアクセスを完了できなかったと考えられます。

今回の事件は、MFAそのものが突破されたことを示すものではありません。むしろ、Dropboxの2段階認証を設定していなかったアカウントが、外部認証の不備だけで狙われやすい状態になっていたことを示しています。1015

何が見られ、ダウンロードされたのか

Dropboxは、攻撃者が影響を受けたアカウントに保存されていたコンテンツを閲覧・ダウンロードしたと説明しています。公開報道では、ファイルにアクセスされたのは約5,000件のうち3分の1未満です。145

ただし、現時点の報道からは、共通して狙われたファイルの種類、総ダウンロード量、被害データの機密性を一律に確定することはできません。Dropboxのログ上、不正アクセスは確認されたものの、ファイルの閲覧やダウンロードの痕跡はなかったと通知された利用者もいます。2

利用者と研究者が見つけた不審な兆候

一部の被害者は、自分のメールアドレスに見覚えのないLenovo IDが関連付けられていることに気づきました。セキュリティ研究者のYoni Levy氏は、Dropboxから届いた通知のコピーを共有しています。通知には、8月4日から21日にかけての不正アクセスと、LenovoのSSO連携に関する問題が記されていました。23

ログイン元としてダブリンに関連する活動が報じられたケースもあります。ただし、これは偽のアイデンティティプロバイダー用アカウントが入口として使われた可能性とは整合するものの、すべての攻撃者の所在地や、全被害アカウントで同じ手順が使われたことを証明するものではありません。

Dropboxはいつ利用者と規制当局に通知したのか

Dropboxは不正アクセスを特定した後、8月31日から9月1日ごろに影響を受けた利用者への通知を開始しました。また、データ保護当局にも報告したと説明しています。346

報道された対応には、次の措置が含まれます。101230

• 影響を受けたセッションの強制終了
• Lenovo IDとの連携解除または制限
• パスワード変更と2段階認証の有効化の呼びかけ
• 問題のあったログイン経路への制限や追加の安全対策

責任はDropboxとLenovoのどちらにあるのか

今回の事件は、どちらか一社だけの単純な侵害というより、両社にまたがる連携システムの失敗と見るのが適切です。

• Lenovo側の問題とみられる点：旧式の認証フローで、攻撃者が管理していないメールアドレスを使ってLenovo IDを作成できたこと。メールアドレスの所有者であることを確認する仕組みが不十分でした。3512
• Dropbox側の問題とみられる点：外部サービスであるLenovoからの認証情報を、既存のDropboxアカウントへの接続・アクセスに十分な根拠として扱い、既存のDropbox認証情報や再認証、より強固な連携確認を求めなかったことです。3911
• 両社の対応：Lenovoは旧式の連携に関わる問題だと説明し、該当する認証確認の問題に対処したとしています。Dropboxも問題を検知・修正し、セッションを終了させ、連携方式を変更したうえで利用者と規制当局に通知しました。101214

Lenovo側の確認不備が「偽の本人情報」を作り出した一方で、その情報を使って既存のクラウドアカウントを開ける状態にしていたのはDropbox側のアカウント連携ロジックでした。この違いが、今回の事件を単なる「Lenovoの認証情報流出」とは異なるものにしています。

Dropbox株への影響はどの程度だったのか

事件の公表後、Dropbox株は時間外取引で下落しましたが、下落率については報道が一致していません。

Reutersを引用した報道では時間外取引で約**2.4％下落したとされる一方、Investing.comは1.8％**の下落を報じました。69別の報道では6％超の下落とされています。8

一方、**6.6％**という具体的な数字は、提供された情報からは確認できません。異なる基準時点や取引時間帯を指している可能性はありますが、今回の資料だけで確定することはできません。

フェデレーテッド・アイデンティティに残る課題

メールアドレスは利用者を識別するための情報であって、そのアドレスを実際に管理していることや、そこにひも付いたアカウントの所有権を自動的に証明するものではありません。

フェデレーテッド・ログインは、別のサービスで認証することでログインの手間を減らせます。しかし、次のような設計では、1つの弱点が別サービスへの侵入口になり得ます。

• アイデンティティプロバイダーが示すメールアドレス情報を、独自確認なしで受け入れる
• 新しい外部IDを既存アカウントに自動的にひも付ける
• 既存パスワード、MFA、確認済みの復旧手段を経ずにアクセスさせる
• ID連携の変更を、高リスクなアカウント復旧操作ではなく通常のログインとして扱う

より安全な設計では、外部IDを既存アカウントに追加する前に、現在のアカウント所有者による明示的な確認が必要です。再認証、確認済みの復旧経路、フィッシング耐性のある認証などが考えられます。

Dropboxの事件が示すのは、パスワードだけでなく、アイデンティティプロバイダーとの信頼関係やアカウント連携そのものも厳密に検証しなければならないということです。メールアドレスを「本人である証拠」と取り違えた瞬間、別のシステムの不備が既存アカウントを開く鍵になり得ます。

Dropboxは、Lenovo IDとのシングルサインオン（SSO）連携の不備を悪用され、約5,000件のアカウントに不正アクセスがあったと明らかにしました。不正アクセスが確認された期間は2026年8月4日から21日までです。Dropboxによると、影響を受けたアカウントのうち、ファイルが閲覧またはダウンロードされたのは3分の1未満でした。146

今回の特徴は、攻撃者が被害者のDropboxパスワードを知らず、メール受信箱にも侵入していなかったとみられる点です。攻撃者は、メールアドレスを本人確認の根拠として扱う2社の認証システムのつながりを悪用しました。

攻撃はどのように成立したのか

確認されている攻撃の流れは、次の3段階です。

1. 攻撃者が、別人のメールアドレスを使ってLenovo IDを登録する。
2. Lenovo側のメールアドレス確認処理の不備により、メール受信箱を支配していなくても、そのIDが有効なものとして扱われる。
3. Dropboxの旧式SSO連携が、Lenovoから伝えられたメールアドレスと既存のDropboxアカウントを照合し、Dropboxの従来のパスワードを求めずにアクセスを許可する。3511

つまり、Dropboxのパスワード認証を直接破ったわけでも、被害者のメールを乗っ取ったわけでもありません。Lenovo IDを認証する「アイデンティティプロバイダー」と、その認証結果を受け入れるDropboxとの信頼関係が侵入口になりました。

なぜ多要素認証（MFA）が被害を抑えられたのか

被害に遭ったアカウントはLenovo IDと連携していましたが、Dropboxの多要素認証（MFA）が有効になっていませんでした。11012

SSOでは、外部サービスでのログインが成功すると、連携先のDropboxでもログイン済みセッションが確立される場合があります。DropboxのMFAが有効なら、Lenovo IDからの認証情報に加えて、Dropbox側が管理する追加確認が必要になります。そのため、偽造されたLenovo IDだけではアクセスを完了できなかったと考えられます。

今回の事件は、MFAそのものが突破されたことを示すものではありません。むしろ、Dropboxの2段階認証を設定していなかったアカウントが、外部認証の不備だけで狙われやすい状態になっていたことを示しています。1015

何が見られ、ダウンロードされたのか

Dropboxは、攻撃者が影響を受けたアカウントに保存されていたコンテンツを閲覧・ダウンロードしたと説明しています。公開報道では、ファイルにアクセスされたのは約5,000件のうち3分の1未満です。145

ただし、現時点の報道からは、共通して狙われたファイルの種類、総ダウンロード量、被害データの機密性を一律に確定することはできません。Dropboxのログ上、不正アクセスは確認されたものの、ファイルの閲覧やダウンロードの痕跡はなかったと通知された利用者もいます。2

利用者と研究者が見つけた不審な兆候

一部の被害者は、自分のメールアドレスに見覚えのないLenovo IDが関連付けられていることに気づきました。セキュリティ研究者のYoni Levy氏は、Dropboxから届いた通知のコピーを共有しています。通知には、8月4日から21日にかけての不正アクセスと、LenovoのSSO連携に関する問題が記されていました。23

ログイン元としてダブリンに関連する活動が報じられたケースもあります。ただし、これは偽のアイデンティティプロバイダー用アカウントが入口として使われた可能性とは整合するものの、すべての攻撃者の所在地や、全被害アカウントで同じ手順が使われたことを証明するものではありません。

Dropboxはいつ利用者と規制当局に通知したのか

Dropboxは不正アクセスを特定した後、8月31日から9月1日ごろに影響を受けた利用者への通知を開始しました。また、データ保護当局にも報告したと説明しています。346

報道された対応には、次の措置が含まれます。101230

• 影響を受けたセッションの強制終了
• Lenovo IDとの連携解除または制限
• パスワード変更と2段階認証の有効化の呼びかけ
• 問題のあったログイン経路への制限や追加の安全対策

責任はDropboxとLenovoのどちらにあるのか

今回の事件は、どちらか一社だけの単純な侵害というより、両社にまたがる連携システムの失敗と見るのが適切です。

• Lenovo側の問題とみられる点：旧式の認証フローで、攻撃者が管理していないメールアドレスを使ってLenovo IDを作成できたこと。メールアドレスの所有者であることを確認する仕組みが不十分でした。3512
• Dropbox側の問題とみられる点：外部サービスであるLenovoからの認証情報を、既存のDropboxアカウントへの接続・アクセスに十分な根拠として扱い、既存のDropbox認証情報や再認証、より強固な連携確認を求めなかったことです。3911
• 両社の対応：Lenovoは旧式の連携に関わる問題だと説明し、該当する認証確認の問題に対処したとしています。Dropboxも問題を検知・修正し、セッションを終了させ、連携方式を変更したうえで利用者と規制当局に通知しました。101214

Lenovo側の確認不備が「偽の本人情報」を作り出した一方で、その情報を使って既存のクラウドアカウントを開ける状態にしていたのはDropbox側のアカウント連携ロジックでした。この違いが、今回の事件を単なる「Lenovoの認証情報流出」とは異なるものにしています。

Dropbox株への影響はどの程度だったのか

事件の公表後、Dropbox株は時間外取引で下落しましたが、下落率については報道が一致していません。

Reutersを引用した報道では時間外取引で約**2.4％下落したとされる一方、Investing.comは1.8％**の下落を報じました。69別の報道では6％超の下落とされています。8

一方、**6.6％**という具体的な数字は、提供された情報からは確認できません。異なる基準時点や取引時間帯を指している可能性はありますが、今回の資料だけで確定することはできません。

フェデレーテッド・アイデンティティに残る課題

メールアドレスは利用者を識別するための情報であって、そのアドレスを実際に管理していることや、そこにひも付いたアカウントの所有権を自動的に証明するものではありません。

フェデレーテッド・ログインは、別のサービスで認証することでログインの手間を減らせます。しかし、次のような設計では、1つの弱点が別サービスへの侵入口になり得ます。

• アイデンティティプロバイダーが示すメールアドレス情報を、独自確認なしで受け入れる
• 新しい外部IDを既存アカウントに自動的にひも付ける
• 既存パスワード、MFA、確認済みの復旧手段を経ずにアクセスさせる
• ID連携の変更を、高リスクなアカウント復旧操作ではなく通常のログインとして扱う

より安全な設計では、外部IDを既存アカウントに追加する前に、現在のアカウント所有者による明示的な確認が必要です。再認証、確認済みの復旧経路、フィッシング耐性のある認証などが考えられます。

Dropboxの事件が示すのは、パスワードだけでなく、アイデンティティプロバイダーとの信頼関係やアカウント連携そのものも厳密に検証しなければならないということです。メールアドレスを「本人である証拠」と取り違えた瞬間、別のシステムの不備が既存アカウントを開く鍵になり得ます。