--- title: "ドコモ不正アクセス：最大30万件の流出項目とMy docomo停止の経過、偽連絡の見分け方" url: "https://www.issoh.co.jp/tech/details/19400/" published: 2026-11-06 updated: 2026-11-06 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ドコモ不正アクセス：最大30万件の流出項目とMy docomo停止の経過、偽連絡の見分け方 NTTドコモは2026年11月5日、ドコモオンラインショップとMy docomoへの外部からの不正アクセスで、最大約30万件の顧客情報が流出したと発表しました。流出した項目は氏名・住所・生年月日・携帯電話番号・連絡先電話番号などで、両サイトの手続きは5日の深夜1時5分ごろから止まったままです。前半では、何が漏れたのか、止まった手続きをどこで受けられるのか、本物の問い合わせ番号はどれかを公式発表から整理します。後半は開発者向けに、契約者ポータルで他人の契約情報が読み出される形をアクセスログから見つける検知コードを、実行結果つきで示します。 ## まとめ：ドコモ不正アクセスで流出した最大30万件の項目と、契約者が今日やること [ドコモの第二報](https://www.docomo.ne.jp/info/notice/page/261105%5F03%5Fm.html)によると、11月4日に両サイトへの外部からの不正アクセスを確認し、5日1時5分ごろから各種手続きを止めました。止める前の不正アクセスで一部の顧客情報が流出し、件数は最大約30万件です。緊急メンテナンスを始めてからの新たな流出は確認されていません。原因、侵入経路、流出した範囲と件数は調査中で、復旧の見込みは立っていません。 契約者が今日やることは2つです。ドコモを名乗るメール・SMS・電話に応じないこと、そして急ぎの手続きは店頭か電話で済ませることです。氏名と電話番号と生年月日がそろって漏れたため、本人確認を装った連絡が成り立ちやすくなっています。 | 項目 | 公表内容（2026年11月5日18時30分時点） | | --------- | ------------------------ | | 対象サイト | ドコモオンラインショップ・My docomo | | 不正アクセスの確認 | 2026年11月4日 | | 手続きの停止 | 11月5日1時5分ごろから継続中 | | 流出件数 | 最大約30万件 | | 流出した項目 | 氏名・住所・生年月日・電話番号など | | 調査中 | 原因・侵入経路・範囲・件数の確定値 | | 正規の窓口 | 151（ドコモの携帯）・0120-800-000 | ## ドコモ契約者が最初に確かめること：流出した項目、止まった手続き、正規の窓口 ### 公表された流出項目5つと、カード情報やパスワードがまだ確定していない理由 第二報が挙げた項目は、氏名・住所・生年月日・携帯電話番号・連絡先電話番号の5つで、末尾に「など」が付いています。流出項目の詳細は調べている最中で、分かりしだい対象者に案内するとドコモは書いています。 クレジットカード情報、dアカウントのパスワード、マイナンバーが含まれるかどうかは、11月6日時点の公表文に記載がありません。漏れていないとも書かれていない点に注意してください。両サイトは契約変更や端末購入の手続きに使う画面なので、決済や本人確認の情報を扱っています。対象かどうかを自分で調べるページも、まだ用意されていません。 いま手元でできるのは、My docomoと同じパスワードをほかのサービスで使い回していないかの点検です。使い回しているなら、ほかのサービス側を先に変えておくと、続報でパスワードの流出が分かったときにも被害を広げずに済みます。漏れたIDとパスワードの組を別サービスで試す手口は[パスワードリスト攻撃の検知の指標と漏えい照合](https://www.issoh.co.jp/tech/details/18730/)で解説しています。 ### My docomoとオンラインショップが止まっている間の手続きは店頭と151で受ける 止まっているのは、両サイトでの契約変更、料金プランの変更、機種変更、端末の購入などの手続きです。[ドコモの第一報](https://www.docomo.ne.jp/info/notice/page/261105%5F02%5Fm.html)は、急ぎの手続きならドコモショップや量販店、一般の販売店の店頭で受けられる場合があると案内しています。来店の前に、最寄りの店舗で受けられる手続きかを電話で確かめてください。 サイトが戻る時期は未定です。再開の知らせはドコモのお知らせページに出ます。メンテナンス中に「My docomoの代わりにこちらから手続きを」と別のURLへ誘う連絡が来たら、それは偽物と考えて構いません。 ### ドコモを名乗るSMS・電話を見分ける、151と0120-800-000の正規窓口 問い合わせ先はドコモ インフォメーションセンターで、ドコモの携帯電話からは151、一般電話などからは0120-800-000です。受付は午前9時から午後8時まで、年中無休です。今回の件で特設のダイヤルは設けられていません。 ドコモは、不審なメール・SMS・電話が届くおそれがあるとして、本文のURLを開かない、添付ファイルを開かない、個人情報・パスワード・クレジットカード情報を入力したり答えたりしないよう求めています。電話で生年月日や住所を言い当てられても、それだけで本物と判断しないでください。流出した情報はまさにその本人確認に使われる項目です。かかってきた電話はいったん切り、自分から151にかけ直すのが確実です。偽の連絡が成り立つ仕組みは[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で、届いたSMSを公式の番号と照らした事例は[イエローハット情報漏洩の第二報](https://www.issoh.co.jp/tech/details/17203/)で取り上げました。同じ週には、MS&ADグループの損保2社も契約者向けページへの不正アクセスを公表しています。漏えい項目と窓口は[あいおいニッセイ同和の不正アクセス：44.4万件の漏えい項目と窓口](https://www.issoh.co.jp/tech/details/19427/)で整理しました。 ## 公式発表で追う経過：10月22日の予防的なメンテナンスから11月5日の第二報まで ドコモの発表を日付順に並べると、次のとおりです。 1. 10月22日：コーポレートサイト・My docomo・オンラインショップなどを予防的なセキュリティ対応で一時停止していたと公表し、再開を発表。この時点で不正アクセスは確認されていないと説明 2. 10月23日：PHPの脆弱性への予防的な対応として、エリアメールの一部などの配信を停止（25日20時1分に再開） 3. 11月4日：オンラインショップとMy docomoへの外部からの不正アクセスを確認 4. 11月5日1時5分ごろ：両サイトの各種手続きを停止し、緊急メンテナンスを開始 5. 11月5日9時（第一報）：外部から不正アクセスが行われた可能性が高いと判断したと公表 6. 11月5日18時30分（第二報）：メンテナンス前の不正アクセスで最大約30万件の流出を確認したと公表 第一報は「可能性が高い」という言い方で、流出には触れていませんでした。半日後の第二報で、流出の事実と件数の上限が加わっています。件数が「最大」と書かれているのは、調べきる前の上限値だからです。確定値は続報で下がる場合も上がる場合もあります。 ### 10月のPHP脆弱性への予防対応と、今回の侵入経路がまだ公表されていない点 10月21日、PHPの開発元は任意のコード実行につながる2件の脆弱性を修正した版を公開しました。[JPCERT/CCのPHPの脆弱性に関する注意喚起](https://www.jpcert.or.jp/at/2026/at260033.html)は、8.5.12より前の8.5系、8.4.27より前の8.4系、8.3.36より前の8.3系、8.2.35より前の8.2系を対象とし、実証コードの公開と攻撃を試みる通信の観測を追記しています。ドコモの[10月23日のお知らせ](https://www.docomo.ne.jp/info/notice/page/261023%5F00%5Fm.html)は、PHPの脆弱性への予防的な対応としてエリアメールの一部を止めたと書いています。 ただし、10月22日の各サイトの停止にPHPの名前は出ておらず、11月4日の不正アクセスとPHPの脆弱性を結び付ける発表もありません。侵入経路は調査中です。脆弱性の中身と更新の手順は[PHP2Shell（CVE-2026-109618・109619）の影響範囲と修正版](https://www.issoh.co.jp/tech/details/18738/)にまとめました。10月27日に公表されたドコモ光「plala（Sコース）」会員の流出は、So-netの会員データベースを経由した別の事案です。経緯は[So-net情報漏洩258万件の対象確認](https://www.issoh.co.jp/tech/details/19044/)で扱っています。 ### 個人情報保護委員会への報告期限から見た、原因と侵入経路の続報が出る時期 [個人情報保護委員会の漏えい等の対応ページ](https://www.ppc.go.jp/personalinfo/legal/leakAction/)は、速報を知った日から3〜5日以内、確報を30日以内とし、不正の目的によるおそれがある漏えいは確報を60日以内としています。不正アクセスによる漏えいは、件数にかかわらず報告の対象です。11月4日を起点にすると、確報の期限は2027年1月上旬になります。原因と侵入経路は、遅くともそのころまでに続報として出る見込みです。速報と確報に書く内容は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で整理しました。 ## 開発側の作業：契約者ポータルの大量読み出しをアクセスログから見つけるPythonの手順 ### マイページ型のサービスで、1つのセッションが他人の契約情報を引く形を疑う理由 侵入経路は未公表なので、ここからはドコモの事案を離れた一般論です。契約者が自分の情報だけを見るマイページで30万件規模の流出が起きるとき、典型は2つあります。1つはサーバの脆弱性でデータベースを直接読まれる形、もう1つは画面の裏のAPIが、ログイン中の利用者と別の契約番号を受け付けてしまう形です。 後者は[OWASP API Security Top 10 2023のAPI1](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/)で「Broken Object Level Authorization（BOLA）」と呼ばれ、APIの弱点の筆頭に置かれています。URLの契約番号を1ずつ変えるだけで他人の情報が返るので、攻撃側は特別な道具を要しません。[JPCERT/CCの国内組織の不正アクセスに関する注意喚起](https://www.jpcert.or.jp/at/2026/at260030.html)も、2026年9月前後の被害の一類型として、公開アプリを解析して内部APIを特定し、権限の変更や不正なアカウント作成に悪用した手口を挙げています。 ### アクセスログから送信元ごとの読み出し件数を数え、上限で止める検知コードの実行 次のコードは標準ライブラリだけで動きます。1行1件のJSON形式のアクセスログを読み、ログイン中の契約と違う契約IDを読めた行と、10分の間に読んだ契約IDの種類が上限を超えた送信元を出します。ログに残す項目は[OWASPのLogging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)が挙げる「いつ・どこから・誰が・何に」の4点に合わせました。 ``` # 会員ポータルのアクセスログから「他人の契約情報の読み出し」と「大量読み出し」を拾う（Python 3.8以上・標準ライブラリのみ） # 使い方: python portal_scan.py import json from collections import defaultdict from datetime import datetime, timedelta # 1行1件のJSON形式のアクセスログ（実運用ではファイルから読む） LOG = """ {"ts":"2026-11-04T21:00:05","src":"198.51.100.7","login":"C1001","path":"/api/contract/C1001","status":200} {"ts":"2026-11-04T21:00:40","src":"198.51.100.7","login":"C1001","path":"/api/contract/C1001/bill","status":200} {"ts":"2026-11-04T23:10:01","src":"203.0.113.50","login":"C2002","path":"/api/contract/C2002","status":200} {"ts":"2026-11-04T23:10:02","src":"203.0.113.50","login":"C2002","path":"/api/contract/C2003","status":200} {"ts":"2026-11-04T23:10:02","src":"203.0.113.50","login":"C2002","path":"/api/contract/C2004","status":200} {"ts":"2026-11-04T23:10:03","src":"203.0.113.50","login":"C2002","path":"/api/contract/C2005","status":200} {"ts":"2026-11-04T23:10:03","src":"203.0.113.50","login":"C2002","path":"/api/contract/C2006","status":404} """ WINDOW = timedelta(minutes=10) # 数える時間幅 LIMIT = 3 # 時間幅の中で読める契約IDの上限（本人は通常1件） def contract_id(path): parts = path.split("/") return parts[3] if len(parts) > 3 and parts[2] == "contract" else None seen = defaultdict(list) # 送信元ごとの (時刻, 契約ID) for line in LOG.strip().splitlines(): r = json.loads(line) cid = contract_id(r["path"]) if cid is None or r["status"] != 200: continue ts = datetime.fromisoformat(r["ts"]) # 1) ログイン中の契約と違うIDを読めた＝認可の抜け（BOLA）の疑い if cid != r["login"]: print("[BOLA ]", r["ts"], r["src"], "login", r["login"], "read", cid) # 2) 時間幅の中で読んだ契約IDの種類数が上限を超えたら止める候補 seen[r["src"]].append((ts, cid)) recent = {c for t, c in seen[r["src"]] if ts - t <= WINDOW} if len(recent) > LIMIT: print("[BULK ]", r["ts"], r["src"], "distinct", len(recent), "-> block") print("[total]", {src: len({c for _, c in v}) for src, v in seen.items()}) ``` Python 3.14.10（Windows）で実行した結果です。 ``` $ python portal_scan.py [BOLA ] 2026-11-04T23:10:02 203.0.113.50 login C2002 read C2003 [BOLA ] 2026-11-04T23:10:02 203.0.113.50 login C2002 read C2004 [BOLA ] 2026-11-04T23:10:03 203.0.113.50 login C2002 read C2005 [BULK ] 2026-11-04T23:10:03 203.0.113.50 distinct 4 -> block [total] {'198.51.100.7': 1, '203.0.113.50': 4} ``` 198.51.100.7は自分の契約C1001と請求画面を見ただけなので、何も出ません。203.0.113.50はC2002でログインしたまま、2秒の間にC2003からC2005を読めています。この3行が出た時点で、API側の認可に穴があると分かります。4行目は、10分の間に4種類の契約IDを読んだ時点で止める候補として出た行です。最後の404は存在しない契約番号への要求で、番号を順に試しているときに混ざる形です。 本番では、BOLAの行は1件でも出たら即座に調べる対象にしてください。件数の上限は、家族の回線をまとめて管理する契約のように1人で複数の契約を見る場合を確かめてから決めます。根本の対策は検知ではなく、APIが受け取った契約IDとログイン中の利用者の権限を毎回照合することです。照合とレート制限の実装は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で、ログから侵入の痕跡を追う手順は[不正アクセスの調べ方とログの確認方法](https://www.issoh.co.jp/tech/details/2788/)で扱っています。 ### PHPで動く会員サイトの版番号とアップロード進捗機能の設定確認手順 自社の会員サイトがPHPで動いているなら、ドコモの事案と関係なく、版番号を先に見てください。JPCERT/CCは修正版を当てられない場合のつなぎとして、`session.upload_progress.enabled`を0にしてすべてのワーカーを再起動する設定を挙げています。この設定の意味は[PHPマニュアルのセッションのアップロードの進捗](https://www.php.net/manual/ja/session.upload-progress.php)に書かれています。 ``` # 動いているPHPの版と、アップロード進捗機能の設定を確かめる（Linux） php -v php -i | grep session.upload_progress.enabled # php-fpm を使う場合は、FPM側の設定も確かめる php-fpm -i | grep session.upload_progress.enabled ``` コマンドラインのphpとWebサーバが呼ぶphp-fpmでは、読み込むphp.iniが違う場合があります。値が0でも、修正版への更新を済ませるまでは対策が終わっていません。JPCERT/CCは侵害の痕跡として、過去の応答に長すぎるPHPSESSIDが出ていないか、不審なmultipart/form-dataの要求の前後にメモリ上限のエラーやHTTP 500が出ていないか、PHPのワーカーが異常終了していないかを見るよう勧めています。 ## 事業者の判断：契約者ポータルとECを同じ基盤で持つ企業が診断を入れる条件 ### 会員の連絡先と契約情報を画面に出すサービスは、APIの認可を年1回点検 ドコモのように、契約者向けのマイページと通販サイトを並べて運用している事業者は珍しくありません。両方が同じ会員情報を読むと、片方への侵入がもう片方の情報まで届きます。今回も2つのサイトの手続きがまとめて止まりました。 次の3つのどれかに当てはまるなら、外部の脆弱性診断と、APIの認可の点検を年1回入れるべきです。スマホアプリや画面の裏に、契約番号や会員番号をURLで受け取るAPIがあること、1つのセッションが読んだ会員IDの種類数をログで数えていないこと、PHPなど実行環境の更新を四半期より長く止めていることです。逆に、会員情報を持たず決済を外部サービスに任せている小さなECなら、まずは管理画面の公開範囲と更新の棚卸しを先に済ませれば足ります。診断の種類と費用の考え方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)、企業として点検する範囲は[不正アクセス対策の点検手順](https://www.issoh.co.jp/column/details/18313/)で解説しています。 会員サイトやアプリのAPIに同じ弱点が残っていないかを第三者に確かめてもらいたいなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 ドコモの不正アクセスについて、契約者から出やすい質問をまとめました。 ### ドコモの不正アクセスで自分の情報が流出したか確かめる方法はありますか？ 11月6日時点で、対象かどうかを自分で調べるページはありません。ドコモは、流出した項目の詳細が分かりしだい、対象の契約者に案内するとしています。その案内を装った連絡が先に届くおそれがあるため、届いた連絡のURLからではなく、ドコモの公式サイトのお知らせか151で確かめてください。 ### My docomoはいつから使えるようになりますか？ 11月5日18時30分時点の第二報では、復旧の見込みは未定です。ドコモオンラインショップとMy docomoの各種手続きは、11月5日1時5分ごろから止まっています。急ぎの手続きは、ドコモショップや量販店などの店頭で受けられる場合があるので、最寄りの店舗に確かめてください。 ### dアカウントのパスワードは変えたほうがいいですか？ 公表された流出項目にパスワードは挙がっていませんが、項目の詳細は調査中で、漏れていないとも書かれていません。My docomoと同じパスワードをほかのサービスでも使っているなら、ほかのサービス側を先に変えておくと安全です。変更はサイトの再開後に、公式のページから行ってください。 ### ドコモからの電話やSMSが本物か見分けるにはどうすればいいですか？ ドコモの正規の問い合わせ先は、ドコモの携帯電話からは151、一般電話からは0120-800-000です。電話で生年月日や住所を言い当てられても本物とは限りません。流出した項目そのものだからです。いったん切って自分から151にかけ直し、SMSやメールのURLは開かないでください。 ### So-netやドコモ光plalaの情報流出と同じ事案ですか？ 別の事案です。10月27日に公表されたドコモ光「plala（Sコース）」会員約44万件の流出は、So-netの会員データベースへの不正アクセスによるものでした。今回はドコモ自身のオンラインショップとMy docomoへの不正アクセスで、11月4日に確認されています。両方の契約がある人は、それぞれの窓口の案内を確かめてください。 ## 関連記事 - [So-net情報漏洩258万件：対象の確認、メールのパスワード再設定とマイページにログインできない時の対処](https://www.issoh.co.jp/tech/details/19044/)：ドコモ光plala（Sコース）会員も対象になった別の事案 - [PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、悪用の実態と更新できない場合の設定【2026年10月】](https://www.issoh.co.jp/tech/details/18738/)：10月に公開されたPHPの脆弱性と更新の手順 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：契約IDの照合とレート制限の実装 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい時に事業者が報告する内容と期限 - [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：流出した個人情報を使った偽の連絡の手口 --- 出典: [ドコモ不正アクセス：最大30万件の流出項目とMy docomo停止の経過、偽連絡の見分け方]()（株式会社一創）