事案の概要データ
| 公表日 | 2026年10月13日 |
|---|---|
| 発見のきっかけ | 自社で実施した脆弱性診断テスト |
| 内容 | 特殊な操作により、他者の支払い証明書が閲覧可能になる脆弱性 |
| 対応完了 | 2026年6月20日 |
| 第三者による閲覧 | 確認されていない |
| 影響件数 | 未公表 |
図解：この事故の構造
何が起きたのか
楽天モバイルは2026年10月13日、「my楽天モバイル」の支払い証明書において、特殊な操作をすると他者の証明書が閲覧できる脆弱性があったことを公表しました。
発見のきっかけは、同社が実施した脆弱性診断テストです。攻撃を受けて判明したのではなく、自ら探して見つけました。対応は2026年6月20日に完了しており、第三者による実際の閲覧は確認されていません。
攻撃される前に自分で見つけた
2026年10月に公表された事案の多くは、攻撃を受けた後の報告でした。そのなかで、この事案は性質が異なります。被害が出る前に、自社の診断で見つけて塞いでいます。
脆弱性診断とは、自社のシステムに対して攻撃者と同じ手法を試し、弱点がないかを確認する取り組みです。外部の専門会社に依頼することもあれば、自社で実施することもあります。
費用はかかりますが、「攻撃されてから対応する」コストと比べれば桁違いに安く済みます。2026年10月の事案を見れば、1件の漏えいがもたらす調査費用、通知費用、信用の低下は計り知れません。
被害がなくても公表する意味
第三者による実際の閲覧が確認されていないにもかかわらず、同社は公表しました。
法的な義務の観点では、実害が確認されていない場合の公表は必須とは限りません。それでも公表することには意味があります。対象となりうる利用者が自分で状況を判断できること、そして同種のサービスを提供する他社が「自社は大丈夫か」と点検する契機になることです。
中小企業でも、自社サイトの不具合を見つけたときに「誰も気づいていないから黙っておこう」という判断をしがちです。しかし、閲覧可能だった期間のログが残っていなければ、「誰も見ていない」ことは証明できません。公表して注意を促すほうが、結果として信頼につながります。
本件は、10月3日のリクエルート「スタディサプリ」（機能の仕様の不備）、10月13日の日本郵便（アプリケーションの不具合）と同様、攻撃ではなく作りの問題に分類される事案です。
時系列で見る経過
- 2026年前半自社で実施した脆弱性診断テストで、他者の支払い証明書が閲覧できる不具合を発見
- 2026年6月20日対応を完了
- 2026年10月13日事案を公表。第三者による実際の閲覧は確認されていないと説明
解決までの道のり
自社の脆弱性診断で発見し、2026年6月20日に対応を完了しています。第三者による実際の閲覧も確認されておらず、被害が発生する前に塞いだ形です。
対応の流れ
- 2026年前半自社で脆弱性診断テストを実施
- 2026年前半特殊な操作により他者の支払い証明書が閲覧可能になる不具合を発見
- 2026年6月20日修正対応を完了
- 2026年6月以降第三者による実際の閲覧の有無を確認
- 2026年10月13日事案を公表し、利用者へ説明
解決できたポイント／残った課題
- 攻撃を受ける前に、自社の診断で発見して塞いだ
- 第三者による実際の閲覧が確認されていない段階で対応が完了している
- 実害が確認されていなくても公表し、利用者が判断できるようにした
- 一方で、対応完了（6月20日）から公表（10月13日）まで約4か月の間がある
中小企業が学ぶべきポイント
- 脆弱性診断は「攻撃されてから対応する」コストに比べれば桁違いに安い。
- 「特殊な操作をすると他人のデータが見える」不具合は、診断でしか見つからないことが多い。
- 実害が確認されていなくても公表する。閲覧されていないことは証明が難しい。
- 攻撃ではなく「作りの問題」による漏えいも、結果は同じ。設計段階の確認が要る。
出典・参考
本記事は、各組織の公表資料および報道をもとに、要点をわかりやすく整理したものです。 被害件数は「漏えいした可能性のある最大件数」として公表されている場合があり、実際に漏えいが確定した件数とは異なることがあります。 また、調査の進展により内容が変わる場合があります。正確な情報は必ず出典元の公式発表をご確認ください。