タカラトミー「デュエル・マスターズ サポートアプリ」の認証機能の脆弱性（個人情報閲覧のおそれ）
公表日
タカラトミーは2026年7月28日、「デュエル・マスターズ サポートアプリ」で顧客情報が漏えいした可能性があると発表した。対象の人数や情報の種類は、まだ分かっていない。
対象者は？
「デュエル・マスターズ サポートアプリ」の利用者の個人情報が、特定の条件下で第三者に閲覧される可能性があったとされています。対象人数、情報の種類、実際に閲覧された事実の有無は、まだ発表されていません。
確認方法は、まだ発表されていません。
何が起きたのか
タカラトミーは2026年7月28日、同社が運営する「デュエル・マスターズ サポートアプリ」で、顧客情報が漏えいした可能性があると発表しました。アプリのリリース日である2025年8月1日から2026年7月13日までの間、開発段階でユーザー認証機能の設計・実装に弱点があったとされています。この弱点のため、特定の条件下で、第三者がユーザーの個人情報を見られる可能性がありました。2026年8月18日にはセキュリティ専門媒体のScanNetSecurityがこの件を報じました。
なぜ起きたのか・なぜ広がったのか
原因は、開発段階でユーザー認証機能の設計・実装に弱点があったこととされています。「特定の条件」の中身や、弱点が見つかった経緯は、まだ発表されていません。
いまの状況2026-08-18 時点続報待ち
2026年8月18日時点で、対象人数、情報の種類、実際に閲覧された事実の有無、対応内容は、まだ発表されていません。続報待ちです。
企業として考えたいこと
自社のアプリやサービスで、ログインした人が他の人の情報を見られないことを、公開前と公開後に誰がどのように確かめていますか。
技術的な要約
タカラトミーは2026年7月28日、同社が運営する「デュエル・マスターズ サポートアプリ」で顧客情報が漏えいした可能性があると発表した。原因は、サービスのリリース日である2025年8月1日から2026年7月13日までの間、開発段階でユーザー認証機能の設計・実装に脆弱性があったこと。特定の条件下で、第三者にユーザーの個人情報を閲覧される可能性があった。対象件数や情報の種類、実際に閲覧された事実の有無は、渡された情報からは分からない。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 不明不正アクセスの発生は報じられていない。開発段階でユーザー認証機能の設計・実装に脆弱性があり、特定の条件下で第三者が個人情報を閲覧できる可能性があった。
- 脆弱性
- CVE 非公表報道・研究者デュエル・マスターズ サポートアプリ（ユーザー認証機能）2025年8月1日から2026年7月13日まで存在。設計・実装上の脆弱性。CVEは非公表。
- 攻撃者
- 特定・主張なし
- ATT&CK
- —
影響
- 業務停止
- なし 業務停止は報じられていない。
- データ
- おそれ上限 —確定 —閲覧される可能性があったとされるが、対象件数と情報の種類は渡された情報にない。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- —
時系列
技術解説
公表された内容 事実
タカラトミーは2026年7月28日、同社が運営する「デュエル・マスターズ サポートアプリ」での顧客情報の漏えいの可能性について発表した。ScanNetSecurityの2026年8月18日付の記事によると、原因は、サービスのリリース日である2025年8月1日から2026年7月13日までの間、開発段階でユーザー認証機能の設計・実装に脆弱性があったことである。この脆弱性により、特定の条件下で第三者にユーザーの個人情報を閲覧される可能性があった。伝えられているのは「可能性」であり、渡された情報には、実際に閲覧された事実や対象件数は含まれていない。
攻撃ではなく開発段階の欠陥として現れた構造 解釈
本件で示されているのは、外部からの侵入手口ではなく、認証機能の設計・実装そのものに欠陥があったという点である。認証の仕組みは、利用者本人かどうかを確かめる入口にあたるため、ここに不備があると、他人の情報に到達できる経路が生まれうる。「特定の条件下」という表現から、誰でも常に閲覧できる状態ではなく、何らかの前提が必要だったと読める。ただし具体的な条件や仕組みは渡された情報にないため、認可の不備なのか、識別子の扱いなのかなどは判断できない。以上は一般的な読み方であり、事実としては確定していない。
長期間存在した点の意味 解釈
脆弱性はリリース日から2026年7月13日まで、約11か月半にわたり存在したとされる。公開直後から存在する欠陥は、リリース前の設計レビューやテストで見つけにくい種類のものだった可能性がある。一方、7月13日が修正完了を意味するのか、気づいた日なのかは、渡された情報からは分からない。公表は7月28日で、期間終了日の15日後にあたる。この間に影響範囲の調査が行われたと推測できるが、推測にとどまる。経緯が公表されれば、発見の契機や調査の手順を評価できる。
公表の範囲と評価の限界 解釈
現時点で確認できる情報は、報道記事1件に基づく概要にとどまる。公式発表の文面は渡されておらず、対象件数、情報の種類、閲覧の有無、対応内容、当局への届出は不明である。このため、タカラトミーの対応の適否を評価することはできない。「可能性」の段階で発表している点は、利用者が状況を知る機会につながるという見方もできるが、詳細が出そろうまで判断は留保すべきである。なお、渡された資料にはトミカ商品の自主回収に関する別件の記事も含まれていたが、本事案とは無関係のため扱っていない。
対応
- 封じ込め
- —
- 公表の仕方
- 2026年7月28日に、顧客情報の漏えいの可能性として発表した。
- 当局対応
- —
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 認証・認可は設計段階で検証しないと、公開後に長期間残りうる | 設計レビューに脅威モデリング（STRIDEなど）を組み込み、「他ユーザーのデータにアクセスできないこと」を要件として明記する。リリース前に認可の自動テスト（別ユーザーのIDやトークンでの読み取りが拒否されるか）をCIに組み込む。 |
| 個人情報を扱う新規サービスは、公開前後に第三者の目で診断する | リリース前に外部のペネトレーションテストまたはWebアプリ・API診断を実施し、認証・セッション管理・IDOR（オブジェクト参照の不備）を重点項目にする。大きな機能追加のたびに再診断を行う。 |
| 「閲覧された事実があるか」を後から判断できるログが要る | 認証・データ取得APIのアクセスログを、利用者ID、対象データID、送信元IP、結果コード付きで一定期間保管する。他ユーザーのデータへのアクセスを検知するルールを設け、調査時に影響範囲を特定できるようにする。 |
| 脆弱性の受付経路を整え、発見から公表までの手順を決めておく | 脆弱性報告の窓口（security.txtや報告フォーム）を公開し、受付から修正、影響範囲調査、利用者への通知までの手順と判断基準を事前に文書化する。机上演習で定期的に確認する。 |
| 影響範囲が確定しない段階でも、分かっていることと不明なことを分けて伝える | 公表テンプレートに「対象となりうる人の範囲」「情報の種類」「閲覧の確認有無」「未確定の項目」の欄を設ける。続報の予定時期を示し、確定時に更新できる体制を整える。 |
自組織などでの確認項目
- 自組織のアプリやWebサービスで、ログイン後に他の利用者のIDを指定したリクエストを送ると、データが返らないことを自動テストで確認していますか。
- 個人情報を扱うサービスについて、リリース前に認証・認可を対象とした第三者診断を実施していますか。次の診断はいつですか。
- アクセスログから「ある期間に、他人の情報が閲覧されたか」を調べられますか。ログの保管期間と項目は十分ですか。
- 脆弱性が見つかったとき、影響範囲が未確定の段階で何を誰が判断し、どの時点で利用者へ知らせるかを決めていますか。
未解明点
- 対象となる利用者の人数と、閲覧される可能性があった情報の種類（氏名、メールなど）は何か。
- 「特定の条件下」とは具体的にどのような条件か。
- 実際に第三者が個人情報を閲覧した事実は確認されたか。
- 脆弱性はどのように発見され、2026年7月13日は修正や対策が行われた日なのか。
- 利用者への個別連絡や、個人情報保護委員会などへの報告は行われたか。
出典
- 1coki（公器）2025-09-08報道本文確認済
- 2ScanNetSecurity2026-08-18報道本文確認済