タカラトミー、「デュエル・マスターズ サポートアプリ」のユーザー認証に設計・実装の脆弱性 — 最大約15万5,000人分が11か月余り閲覧可能な状態に

項目	内容
発生日	2025年8月1日（アプリ公開）〜2026年7月13日（改修完了）の11か月余り、脆弱性が存在した
公表日	2026年7月28日（報道は2026年8月18日）
対象組織・業界	株式会社タカラトミー（「デュエル・マスターズ サポートアプリ」を提供／製造）
影響件数	最大 約155,000名。氏名、住所、電話番号、性別、生年月日、メールアドレス、サービスID、ハンドルネーム、XユーザーIDの9項目
攻撃手法	攻撃の有無は確認されていない。開発段階でユーザー認証機能の設計・実装に脆弱性があり、特定の条件下で第三者が個人情報を閲覧できる可能性があった
情報源	ITmedia NEWS（2026年7月31日）、ScanNetSecurity（2026年8月18日）

概要

株式会社タカラトミーは2026年7月28日、スマートフォンアプリ「デュエル・マスターズ サポートアプリ」のユーザー認証機能に脆弱性があり、特定の条件下で第三者が利用者の個人情報を閲覧できる状態だったと公表しました。

原因は、開発段階でユーザー認証機能の設計・実装に脆弱性があったことです。脆弱性が存在していたのは、アプリを公開した2025年8月1日から、改修を終えた2026年7月13日までの11か月余りにわたります。

対象は最大 約155,000名で、閲覧できた可能性がある情報は氏名、住所、電話番号、性別、生年月日、メールアドレス、サービスID、ハンドルネーム、XユーザーIDの9項目です。

同社は当該脆弱性の改修をすでに完了しており、第三者が顧客情報を閲覧した事実や不正利用の事実は確認されていないとしています。再発防止として、情報セキュリティに関する従業員教育を徹底するとともに、アプリサービスにおけるセキュリティ確認体制を強化するとしています。

経緯

• 2025年8月1日: アプリを公開。この時点でユーザー認証機能の設計・実装に脆弱性が存在
• 2025年8月1日〜2026年7月13日: 特定の条件下で第三者が利用者の個人情報を閲覧できる状態が継続（11か月余り）
• 2026年7月13日: 脆弱性の改修を完了
• 2026年7月28日: タカラトミーが公表。閲覧や不正利用の事実は確認されていないとする
• 2026年8月18日: 報道により広く伝えられる

原因

判明している事実: 開発段階でユーザー認証機能の設計・実装に脆弱性があったことです。脆弱性の技術的な内容、「特定の条件」がどのようなものか、脆弱性が発見された経緯は公表されていません。

考えられる原因（推測）

脆弱性の具体的な内容も、「特定の条件」が何を指すのかも公表されていません。認証機能のどこに不備があったのかは、現時点では分かりません。

分かるのは、11か月余り誰も気づかなかったということです。認証機能の不備は、正しい利用者が正しく使っているかぎり表面化しません。画面は正常に動き、利用者からの問い合わせもエラーの記録も発生しない。「動いているから問題ない」という状態が、そのまま11か月続いたことになります。

発見の経緯も公表されていないため、外部からの指摘だったのか自社の点検だったのかは分かりません。ただ、再発防止に「アプリサービスにおけるセキュリティ確認体制を強化」を挙げているところを見ると、リリース前の確認工程に手を入れる必要があると判断したのでしょう。

対策

組織が学ぶべきこと

1. 認証の設計は、リリース前に第三者の目で検証する

認証機能の不備は、正常な利用では表面化しません。開発した本人が自分の実装を確認しても、想定していない条件は試されません。設計レビューと、リリース前のセキュリティ検証を開発チームの外で行う工程が必要です。

2. アプリが返す情報の範囲を、利用者単位で確認する

「他人の情報が見えるか」は、別の利用者のIDを指定したときに何が返るかを実際に試すことで確認できます。この検証は、機能が正しく動くかのテストとは別に設計する必要があります。

3. アプリに保持する項目を、サービスの目的まで絞る

今回の対象は9項目で、住所と電話番号まで含まれます。カードゲームのサポートアプリという目的に、これらすべてが必要かは検討の余地があります。保持する項目を減らすことは、同種の不備が起きたときの影響を直接下げます。

ヤグラの視点 — 攻撃者のいないインシデント：侵入も攻撃もなく、15万5,000人分が見える状態だった

この事案には、侵入がありません。マルウェアも、フィッシングも、認証情報の窃取もありません。アプリのユーザー認証機能の設計・実装に不備があり、特定の条件下で他人の情報が見えた——起きたのはそれだけです。それでも、最大約15万5,000人分の氏名・住所・電話番号までが、11か月余りにわたって閲覧可能な状態にありました。

このタイプの事案が検知されにくいのは、すべての動作が正常な処理として記録されるからです。不正なログインもなく、エラーも発生しません。仮に誰かが他人の情報を引き出したとしても、記録の上では「認証を通ったリクエストへの応答」になります。侵入を前提に組まれた監視の網には、最初から掛かりません。同社が「閲覧した事実は確認されていない」としている一方で「最大約15万5,000人」という数字を示しているのは、閲覧可能だった範囲は特定できても、実際に閲覧されたかは記録から判断しきれないことの現れと考えられます。

だから有効なのは、監視を厚くすることではなく、リリース前の検証工程に「他人の情報が見えないか」という確認を固定することです。機能が仕様どおり動くかのテストと、想定外の条件で何が返るかの検証は、別の作業です。同社が再発防止に「アプリサービスにおけるセキュリティ確認体制を強化」を挙げているのは、この順序を踏まえた対応にあたります。

攻撃者のいないインシデントに対しては、間違えられる余地を工程の側から外すほうが、事後の監視より確実に効きます。

今後の対応

• 脆弱性の技術的な内容と、「特定の条件」の詳細
• 脆弱性が発見された経緯
• 対象者への連絡状況
• セキュリティ確認体制の強化の具体的内容

判明次第、本記事に追記します。

更新履歴

日時	内容
2026-08-18	2026年7月28日の公表内容および報道をもとに記事を公開