楽天モバイル株式会社は2026年10月13日、契約者向けサービス「my 楽天モバイル」からダウンロードできる支払い証明書について、第三者が閲覧できる可能性のある脆弱性が見つかったと公表しました。同社が実施した脆弱性診断テストで判明したもので、氏名、住所、電話番号、データ利用量、利用料金などの情報が対象となり得る状態でした。
同社は6月20日にシステム改修などを完了しています。確認可能な記録を調査した結果、10月13日時点で第三者による閲覧や二次被害は確認されていません。実際に個人情報が漏えいしたと確定した事案ではありません。
楽天モバイルの支払い証明書閲覧問題のサマリー
- 公表日:2026年10月13日
- 対象サービス:「my 楽天モバイル」
- 対象機能:支払い証明書のダウンロード
- 発見方法:楽天モバイルが実施した脆弱性診断テスト
- 脆弱性によるリスク:第三者が特定のプログラムなどを用いて特殊な操作を行うと、支払い証明書を閲覧できる可能性
- 閲覧され得た情報:氏名、住所、電話番号、データ利用量、利用料金、その他の明細情報
- 対象外:クレジットカードなどの金融情報、通話履歴
- 改修状況:2026年6月20日にシステム改修などを完了
- 実際の閲覧:確認できる範囲の記録では確認されず
- 二次被害:公表時点で確認されず
- 関係当局:報告済み
影響を受けた可能性のある契約者数や支払い証明書の件数は、今回の公表では示されていません。
どのような脆弱性が見つかったのか
楽天モバイルによると、通常のサービス利用では実施しない特殊な操作を、第三者が特定のプログラムなどを使って意図的に行うことで、支払い証明書を閲覧できる可能性がありました。
ここでいう脆弱性とは、システムのプログラムや設計、設定などに存在するセキュリティ上の弱点です。悪用されると、本来アクセスできない情報の閲覧や機能の不正利用につながる場合があります。
ただし、楽天モバイルは具体的な原因や操作方法、脆弱性の種類、CVE番号を公表していません。今回の問題が認証回避や特定のアクセス制御不備によって起きたと断定することはできません。
関連するリスク:アクセス制御の不備とは
Webサービスで利用者ごとに保管する請求書や証明書は、本人以外が閲覧できないよう制限する必要があります。
ここでは「認証」と「認可」の違いがポイントになります。
| 項目 | 確認すること | 支払い証明書に当てはめた例 |
|---|---|---|
| 認証(Authentication) | 操作者が誰なのか | 契約者が正しくログインしたか |
| 認可(Authorization) | その操作・情報への権限があるか | ログイン中の契約者が、その証明書を閲覧してよいか |
ログインできる利用者であっても、別の利用者の証明書を閲覧できてよいわけではありません。OWASPは、Webアプリケーションの主要リスクをまとめた「OWASP Top 10:2025」で、アクセス制御の不備を最上位のリスクとして挙げています。たとえば、書類の識別子を指定し直した際に別の利用者の情報まで取得できる「IDOR(安全でない直接オブジェクト参照)」は、その代表例です。
これらは類似する問題を理解するための一般的な説明であり、楽天モバイルの脆弱性がIDORだったと確認されたものではありません。
第三者が閲覧できる可能性があった情報
支払い証明書に含まれ、第三者に閲覧される可能性があった情報は、氏名、住所、電話番号、データ利用量、利用料金、その他の明細情報です。
クレジットカードなどの金融情報や通話履歴は、支払い証明書には含まれていません。
一方、氏名や連絡先に請求・利用状況が組み合わさると、契約者を装った問い合わせや請求を装う不審な連絡に悪用されるリスクがあります。これは一般的に想定されるリスクであり、今回の情報が実際に悪用されたことを示すものではありません。
6月20日に改修完了、10月13日に公表
楽天モバイルは、自社の脆弱性診断テストによって問題を把握し、2026年6月20日にシステム改修などを完了しました。
同社が確認可能な記録を調査したところ、第三者による支払い証明書の閲覧は確認されておらず、本件に関する二次被害も確認されていません。関係当局への報告も済ませています。
10月13日の公表は、脆弱性の存在と改修状況を利用者に伝えるもので、不正アクセスによる情報窃取が判明したという発表ではありません。
なお、楽天モバイルの「特定利用者情報の漏洩事案の公表について」にも、2026年6月に認知した事象として掲載されています。同ページに掲載された別時期の事象と、今回の支払い証明書の問題は区別する必要があります。
なぜ脆弱性診断が必要なのか
Webアプリケーションでは、正常なログインや支払い証明書のダウンロードが機能していても、通常とは異なる要求を送った場合の処理まで正しく制御されているとは限りません。
脆弱性診断は、利用者による通常操作だけでは見つけにくい実装や設定の問題を、第三者による悪用が発生する前に発見し、修正につなげるために実施します。
とくに、個人情報を含む書類を発行するサービスでは、次のような観点が確認対象になります。
- 利用者ごとの閲覧権限:他人の契約情報や書類を要求した際、サーバー側で確実に拒否されるか。
- ダウンロード機能とAPI:画面上だけでなく、書類生成・取得の処理ごとに権限が検証されるか。
- 通常と異なる操作への耐性:想定外の入力や連続した要求により、権限外のデータへアクセスできないか。
- ログの記録・調査能力:書類の閲覧・取得やアクセス拒否を記録し、問題の発覚後に影響を調べられるか。
- 修正後の再診断:脆弱性を修正した後、同じ問題が再現しないことを確認できるか。
自動診断ツールで共通的な脆弱性を探すだけでなく、異なる利用者アカウントや権限を使った手動検証も検討対象です。利用者間のアクセス制御や複雑な業務ロジックは、自動診断だけでは十分に検査できない場合があります。
脆弱性診断の種類や実施時期は、脆弱性診断とは?目的や種類、実施頻度を解説で整理しています。
利用者は楽天モバイルを装った不審な連絡に注意
楽天モバイルは、同社を装った不審な連絡への注意を呼びかけています。現時点で二次被害は確認されていませんが、利用料金や契約情報を示して確認を迫るメール・SMS・電話を受けた場合は、発信元を慎重に確認してください。
不審なメッセージに記載されたリンクからログインしたり、認証コードを伝えたりせず、「my 楽天モバイル」の公式アプリまたは公式サイトを直接開いて確認する方法があります。
本件の問い合わせ先は、楽天モバイルが案内する専用窓口 0800-600-6660(年中無休、9時~17時) です。
情報システム部門が確認したいポイント
今回の事案は、脆弱性診断で発見された問題が、実際の第三者閲覧が確認される前に修正されたケースです。企業が同様のリスクを点検する際は、請求書、給与明細、契約書、顧客向けレポートなど、利用者別にファイルを出力する機能を洗い出すことが出発点になります。
とくに認証済みの複数アカウントを用いた認可テスト、書類の生成・ダウンロードAPIのアクセス制御、閲覧ログの保存と異常検知、改修後の再確認までをセットにすると、脆弱性の発見から対応完了まで追跡できます。
診断ツールの対象範囲や自動・手動診断の違いについては、脆弱性診断ツールの種類と選び方でも解説しています。








