KDDIメール不正アクセスまとめ｜漏えい確定1,223万件・パスワード761万件とゼロデイの教訓【2026年7月更新】

結論：ゼロデイでも「初動と局限」で差がつく。自社が使う第三者製部品を棚卸ししているかが分かれ目

KDDIがISP（インターネットサービスプロバイダ）事業者向けに提供するメールシステムが不正アクセスを受けた事案は、2026年6月23日の第一報では「最大約1,422万件が漏えいの可能性」という表現でしたが、7月6日の続報で被害が確定しました。漏えいが確認されたのはメールアドレス12,233,087名分、うちパスワードは7,616,173名分です（数字はいずれもKDDIの報道発表資料による）。起点は、KDDIがシステムの一部として導入していた第三者製ソフトウェアの脆弱性で、しかも**KDDIが不正アクセスを確認した6月17日時点では、ソフトウェアのベンダー自身も把握していなかった脆弱性（＝ゼロデイ）**でした。

中小企業の経営者・情シスがこの事案から持ち帰るべき教訓は、「大企業でも破られるのだから仕方ない」という諦めでも、「うちは小さいから狙われない」という油断でもありません。要点は次の3つです。第一に、一行も自社で書いていない「第三者製の部品」であっても、それが認証情報を扱う経路上にあれば、自社サービスの大量漏えいに直結すること。第二に、ゼロデイは「発生をゼロにできない」前提の脅威であり、勝負は発生後の検知の早さ・被害の局限（封じ込め）・利用者保護の初動で決まること。第三に、KDDIの対応（確認当日のシステム改修、4日後の全サーバーEDR導入、6日後の第三者フォレンジック調査）は、規模こそ違えど中小企業がそのまま「初動の型」として翻訳できること。本記事は攻撃手法の解説ではなく、この教訓を自社の棚卸し・契約・検知・初動に落とすための実務フレームとして整理します。

この記事を読むべき人

• 自社サービスやメール・会員システムで、認証情報（メールアドレス・パスワード・トークン）を第三者製ソフトや共通基盤・SaaSに預けている中小企業の経営者・事業責任者
• 情シスが1人ないし兼任で、脆弱性情報の購読やパッチ適用が属人化している会社
• OEM・共通基盤を採用している、あるいは自社が誰かにOEM提供している事業者
• 「ゼロデイなら防げないのでは」と対策の優先度を下げかけている決裁者

なぜ今読むべきか：第一報の「可能性」から確定被害・行政報告フェーズへ移った

この事案は動いています。時系列を追うと、報道の「最大◯◯万件の可能性」という第一報だけを見て判断すると、実像を見誤ります。

第一報の「1,422万件」は調査継続中の最大値、7月6日の「1,223万件／761万件」は漏えいが確認された確定値です。両者は矛盾ではなく、調査が進んで実数に絞り込まれた結果です。記事や社内報告で数字を引用する際は、どの日付のどの数字かを必ず添えてください。ここを曖昧にすると、経営会議での説明が二次報道の受け売りに見えてしまいます。

確定した事実の整理（公式一次発表ベース）

KDDIの2つの報道発表資料と総務省の公表から確認できた事実のみを整理します。脆弱性の具体名やCVE番号、攻撃者の属性など、公式に開示されていない事項は本記事では扱いません（不明は不明と明記します）。

なお、公式資料には「不審な痕跡は本脆弱性以外に存在しないことを第三者機関のフォレンジックで確認した」とあります。これは「メール本文まで抜かれたかどうか」を断定するものではなく、開示されているのは上記の認証情報の漏えい確定までです。ここを超えた被害範囲の推測は行いません。

独自の読み方1：ゼロデイだから「防げなかった」は半分だけ正しい

この事案を「ベンダーも知らない脆弱性なら、誰も防げない。だから対策しても無駄」と読むのは危険な短絡です。ゼロデイは確かに侵入の入口を事前に塞ぐことが困難ですが、被害の大きさを決めるのは入口だけではありません。侵入から発覚までの時間、発覚後にどれだけ早く封じ込めたか、認証情報を流出後に無力化できたか——この3点で結果は大きく変わります。

本事案では、発生（5月16日）から確認（6月17日）まで約1か月の滞留がありました。ここは中小企業がまず直視すべき数字です。侵入自体を防げなくても、「いつもと違う大量アクセス」「認証失敗の急増」「想定外の経路からのアクセス」を検知する仕組みがあれば、滞留期間＝被害の蓄積時間を短くできます。KDDIが確認当日にシステムを改修し、4日後にEDR（端末・サーバの挙動監視と対応）を全サーバーへ導入したのは、「入口は塞げなくても、次の侵入と横展開は検知・遮断する」という局限の発想です。

中小企業に翻訳すると、優先すべきは高価な最新防御製品の導入ではなく、次の順番です。(1) 認証情報を扱うサーバ・SaaSのログが取れているか、(2) 異常を人が気づける通知経路があるか、(3) 侵入が疑われたときに通信を止め、パスワードを強制リセットできる手順があるか。この3点が未整備なまま「うちはゼロデイだから守れない」と言うのは、鍵の話をしているのに家に監視カメラも警報も付けていない状態です。ゼロデイは対策不要の理由ではなく、初動体制を持つ理由です。

独自の読み方2：被害が「6社」に広がった構造＝共通基盤リスクの縮図

見落としてはならないのは、影響が単一サービスではなく6社のISPにまたがった点です。KDDIが自社開発したメール基盤を複数のISPへOEM／共通基盤として提供し、各ISPが自社ブランド（@niftyメール、BIGLOBEメール等）で利用者へ届けていた——この供給構造が、ひとつの部品の脆弱性を6社分の被害へ増幅しました。

ここには二つの立場が入れ子になっています。KDDIにとっては「自社が選定した第三者製ソフトの脆弱性」ですが、その基盤を採用した各ISPにとっては「委託先が採用していた、さらにその先の部品の脆弱性」、つまり二次・三次のサプライチェーンリスクです。共通基盤を採用する側は、コスト効率と引き換えに部品の脆弱性管理を委ねることになります。だからこそ、委託・OEM・SaaS契約では、脆弱性の検知から通知・修正適用までのSLAと、インシデント時の情報連携フローを契約段階で握っておく必要があります。

この構造は大企業だけの話ではありません。中小企業でも、会員サイトの認証を外部SaaSに預けている、メール配信を他社基盤で回している、業務システムをOEMで導入している——どれも同じ入れ子構造です。自社が「エンドユーザーに見えている顔」である以上、部品の障害でも説明責任は自社に来ます。次章の棚卸しフレームは、この「顔と部品のズレ」を可視化するためのものです。

自社に落とす：第三者製部品の棚卸しフレーム（4層で見る）

「うちは第三者製ソフトなんて使っていない」と思う会社ほど危険です。ほとんどのシステムは外部部品の積み木で動いています。認証情報が通る経路を、次の4層で棚卸ししてください。

本事案の起点は①〜②の層、すなわち「基盤ベンダーが採用していた部品」でした。中小企業が自力で②の内部まで完全に見通すのは困難です。だからこそ現実的な打ち手は、②を自力で解剖することではなく、①の契約で②の管理責任と通知義務をベンダーに負わせることです。この棚卸しは一度作れば資産になります。どの外部部品にどう依存しているかが1枚で見える状態は、次にニュースが出たとき「うちは対象か」を即答できる防御力そのものです。第三者製コンポーネントを含む構成の点検は脆弱性診断サービスで外部の目を入れると、自社では気づけない依存関係が浮かびます。

KDDIの対応を「中小企業の初動テンプレ」に翻訳する

規模は違っても、KDDIが踏んだ手順は初動の型として普遍的です。自社版の初動手順書を作るときの骨格として使えます。

1. 確認即封じ込め：不正アクセスを確認した当日にシステムを改修し、脆弱性へ対処。中小企業版＝疑いの段階で該当システムの外部通信を止める・当該サービスを一時停止する判断権限を、事前に誰が持つか決めておく。
2. 検知の底上げ：数日内に全サーバーへEDRを導入。中小企業版＝全社一斉のEDRが無理でも、認証情報を扱うサーバだけでもログ監視と挙動検知を優先配備する。
3. 第三者による裏取り：フォレンジック調査で「他に不審な痕跡がない」ことを確認。中小企業版＝自社の「たぶん大丈夫」で幕を引かず、外部のインシデント対応の専門家に痕跡調査と原因特定を委ねる。この一手が、後の当局報告・顧客説明の信頼性を担保する。
4. 利用者保護を強制力で：休眠ユーザーも含めパスワードを強制変更。中小企業版＝「変更をお願いします」の通知だけで終わらせず、リセットを強制できる仕組みを平時に用意しておく。
5. 行政報告と再発防止の公表：電気通信事業法に基づき総務省へ報告書を提出。中小企業版＝個人情報保護法上の報告・本人通知の要否と期限を、事案発生前に把握しておく（漏えい時の個人情報保護委員会への報告義務がある業種・規模に該当するか）。

このテンプレの価値は、事案が起きてから作ると必ず抜けが出るという点にあります。特に1（誰が停止判断をするか）と4（強制リセットの仕組み）は、平時に決めていないと当日に動けません。

発注前・契約前にベンダーへ聞くべき質問リスト

新規にシステムやSaaSを発注する、あるいは既存契約を見直すとき、次を確認してください。答えられないベンダーは、いざというとき自社を守れません。

• 使用している主要な第三者製部品（ライブラリ・ミドルウェア）を開示できますか。SBOM（部品表）は提供できますか。
• 部品に脆弱性が出た場合、貴社から当社への通知は何時間以内ですか。それは契約書に明記されますか。
• ゼロデイを含む緊急脆弱性の修正適用SLA（暫定対処・恒久対処の期限）はどうなっていますか。
• 認証情報（パスワード等）の保存方式（ハッシュ方式・ソルト・鍵管理）を説明できますか。
• インシデント発生時、当社への一次連絡・情報連携フローと、当局報告・顧客通知の役割分担はどうなりますか。
• 当該サービスは他社にもOEM／共通提供されていますか（＝影響が横に広がる構造か）。

これらは「相性の良いベンダーを選ぶ」ためではなく、「安く見えて有事に無力な契約」を避けるための質問です。価格表には出てこないこの条項の有無が、5年後の被害額を左右します。

情シス・CISOが今日点検するチェックリスト

• 認証情報を保存・経由する全システムを洗い出し、どの第三者製ソフト／基盤に依存しているかを台帳化している
• 採用している外部部品・基盤の脆弱性情報（アドバイザリ）を受け取る購読チャネルがある
• OEM・共通基盤・SaaSについて、脆弱性通知と修正適用の責任分界・SLAを契約で明確化している
• パスワードを平文・可逆な形で保持していないか、ハッシュ化・ソルト付与を点検している
• 異常な大量アクセス・認証失敗の急増・想定外経路のアクセスを検知し、アラートが担当へ届く
• 侵入疑い時に通信を止め、パスワードを強制リセットできる手順と権限者が決まっている
• 漏えい把握から当局報告・利用者通知・強制リセットまでの初動が文書化され、訓練されている
• 利用者へパスワード変更を促す際の正規の連絡経路と、フィッシングと誤認されない告知文面が用意されている

最後の項目は本事案で特に重い意味を持ちます。大規模漏えいの直後は、その騒ぎに便乗した偽の「パスワード変更のお願い」フィッシングが増えます。正規の告知が本物だと利用者に信じてもらえる経路設計まで含めて、初動は完成します。

漏えいの可能性がある利用者側の備え

対象6社のメールを使っている個人・企業は、次を実行してください。パスワードの使い回しがある場合、ひとつのサービスでの漏えいが他サービスへの不正ログイン（リスト型攻撃）の入口になります。

• 対象サービスのパスワードを変更する（ISP事業者からの正規の案内を確認のうえ）。
• 同じパスワードを使っている他サービスも併せて変更する。ここを怠ると被害が横に広がる。
• 可能なサービスでは多要素認証（MFA）を有効化する。
• 「パスワード変更」を促すメールやSMSが来ても、リンクを直接踏まず、公式サイト・アプリから自分でアクセスして手続きする（便乗フィッシング対策）。

「自社は対象か」「便乗詐欺か」を見分ける実務判断

大規模漏えいのニュースが出ると、社内から真っ先に来る質問は「うちは関係あるのか」です。ここで曖昧に「たぶん大丈夫」と流すと、対象だった場合の初動が遅れます。判定は単純で、対象6社（STNet／KDDIウェブコミュニケーションズ／JCOM／中部テレコミュニケーション／ニフティ／ビッグローブ）が提供するメールアドレス、具体的には@nifty系・BIGLOBE系・J:COM系・コミュファ系・ピカラ系・CPI（レンタルサーバ）系のメールを、業務や会員登録・各種サービスのログインIDに使っているかを確認します。使っていれば対象として扱い、使っていなくても「そのメールを他サービスの連絡先やID回復先に登録していないか」まで一段掘り下げてください。メールアドレスは平文で漏れているため、対象メールを鍵の受け取り口にしている他サービスも間接的な影響下に入ります。

同時に警戒すべきは、事案に便乗した二次攻撃です。漏えいの直後は「至急パスワードを変更してください」という体裁のフィッシングメールやSMSが急増します。本物と偽物を見分ける実務的な線引きは3つです。第一に、メール内のリンクは押さず、ブックマークや公式アプリから自分でログインして案内の有無を確かめること。第二に、パスワードや認証コードをメールの返信・フォームに入力させる案内は正規ではないと判断すること（正規のISPが返信でパスワードを聞くことはありません）。第三に、送信元アドレスやリンク先ドメインが公式と一致するかを目視し、少しでも違えば無視することです。この3点を社内の全員が共有できているかどうかが、漏えいそのものより大きな二次被害を防ぐ分かれ目になります。

放置した場合と、体制を整えた場合の違い

本事案を自社に当てはめたとき、平時に何を整えているかで有事の結果が変わります。一般論ではなく、認証情報漏えいという文脈に絞って対比します。

FAQ

Q. 結局、何件・何が漏えいしたのですか

7月6日の続報時点で**確定しているのは、電子メールアドレス約1,223万件（12,233,087名）と、そのうちパスワード約761万件（7,616,173名）**です。第一報（6月23日）の「最大約1,422万件」は調査継続中の最大値で、確定値ではありません。パスワードにはハッシュ化・暗号化されたものも含まれます。

Q. 原因は何ですか。KDDIの作ったシステムが悪かったのですか

起点は、KDDIがシステムの一部として導入していた第三者製ソフトウェアの脆弱性です。しかもKDDIが不正アクセスを確認した6月17日時点では、そのソフトのベンダー自身も把握していなかったゼロデイ脆弱性だったと公表されています。自社開発コードのバグではなく、採用していた外部部品が突破口になった点が本事案の構造的な特徴です。

Q. ゼロデイなら、うちが対策しても無駄では？

入口を事前に塞ぐのは困難でも、被害の大きさは検知の早さ・封じ込め・利用者保護の初動で変わります。本事案でもKDDIは確認当日の改修、EDR導入、フォレンジック、強制パスワードリセットで被害を局限しました。ゼロデイは対策不要の理由ではなく、初動体制を持つ理由です。

Q. au メールや UQ mobile メールは大丈夫ですか

KDDIは、au メール・UQ mobile メール・au one net メールは異なる設備で構築されており、本件による影響や漏えいはないと公表しています。

Q. 自社サービスにも同種のリスクはありますか

認証情報を扱う経路に第三者製ソフト・ライブラリ・共通基盤・SaaSを使っている場合、同種のリスクは存在します。重要なのは、どの部品にどう依存しているかを台帳化し、脆弱性情報を継続的に受け取り、修正適用までの運用を回せているか、そして契約で通知義務とSLAを握れているかです。

Q. 委託先・OEM提供を受けている場合、責任はどうなりますか

技術的な脆弱性の管理主体と、利用者への説明・通知責任は必ずしも一致しません。本事案でも、基盤を提供したKDDIと、利用者に顔を向ける各ISPで役割が分かれました。契約上の責任分界、脆弱性通知のSLA、インシデント時の連携フローを事前に定義しておくことが、被害拡大と対応遅延を防ぎます。

GXOに相談すべきタイミング

次のいずれかに当てはまる場合は、外部の専門支援を入れる検討に値します。ニュースを読んで不安になった今が、平時のうちに体制を作る好機です。

• 認証情報を扱うシステムが第三者製ソフトや共通基盤・SaaSに依存しているが、依存関係の棚卸し（台帳）ができていない
• 脆弱性情報の購読・トリアージ・修正適用が属人化しており、SLAとして回っていない
• 侵入疑い時に「誰が通信を止め、誰がパスワードを強制リセットするか」が決まっていない
• 漏えい把握から当局報告・利用者通知までの初動手順が未整備、または訓練したことがない

GXOでは、こうした事案を単なる情報収集で終わらせず、自社資産・影響判定・対応期限・経営報告へ変換するところまでを支援します。まずは現状を客観視したい場合は、SIEM/SOCから脆弱性診断・インシデント対応までを一体で見るセキュリティ体制の再構築の相談窓口が入口です。検知から初動・月次の脆弱性運用までを継続的に支える体制づくりは中小企業向けのセキュリティ顧問（リテイナー）で、漏えい・不正アクセスを想定した平時の備えと有事の初動設計はインシデント対応の相談で扱います。ゼロトラストを前提とした認証・アクセス設計の考え方は中小企業向けゼロトラスト導入ガイドで整理しています。

なお、本記事は公式発表の範囲で構成しており、GXOの個別支援実績や費用に関する数値は記載していません。自社構成に即した診断範囲や概算は、相談時に構成をお預かりしたうえでご提示します。

出典

• KDDI 報道発表資料「ISP事業者向けメールシステムに対する不正アクセスの発生について」（2026年6月23日・第一報）
• KDDI 報道発表資料「ISP事業者向けメールシステムに対する不正アクセスについてのお詫びとご報告」（2026年7月6日・確定被害の続報）
• 総務省「KDDI株式会社に対する報告徴収」（2026年6月24日）
• KDDIウェブコミュニケーションズ「当社メールサービスに対する不正アクセスの発生について」
• piyolog「KDDIのISP事業者向けメールシステムへの不正アクセスについてまとめてみた」（二次情報・時系列の参考） [//]: # (rewrite-evaluation-extension-20260717)

GXO式「委託メール・第三者ソフト緊急点検」100点評価表

GXO独自分析の前提条件は、KDDIの事案を自社へそのまま当てはめず、同じ依存構造と証拠不足があるかを点検することだ。

80点以上でも侵害兆候があれば封じ込めを優先する。ログ欠落、管理者アカウント共有、第三者ソフト版不明、MFAなし、委託先の通知期限なしは強制対応条件である。記事を読んで「自社はKDDIではない」と見送る判断は向かない。

24時間初動テンプレート

0〜1時間：対象 / 版 / 公開IP / 管理者 / 委託先 / 証拠保全
1〜4時間：隔離 / 認証情報 / セッション / API / ログ / IOC
4〜12時間：影響期間 / 人数 / データ項目 / 継続侵害
12〜24時間：経営 / 法務 / 当局 / 顧客 / 復旧・監視
費用：調査___万円 / 通知___万円 / 復旧___万円 / 監視月___万円

対象1万人、通知単価100円という仮置きなら発送等だけで100万円だが、実費は方法・対象・窓口で変わる。このGXO計算例は相場ではなく、フォレンジック、通知、問合せ、復旧を別費用にするためのものだ。

一次資料と根拠と検証方法

• 個人情報保護委員会 漏えい等の対応
• IPA 情報セキュリティ10大脅威
• JPCERT/CC インシデント対応
• 総務省 サイバーセキュリティ

版番号: GXO-KDDI-MAIL-20260717-v1.0。確認日: 2026年7月17日。記事本文の件数・時系列はKDDIの最新公式発表と突合し、検証可能性の証拠は公式発表、ログ、資産・権限台帳、通知・復旧記録とする。KDDIの追加発表、影響件数、原因、脆弱性、対応変更を更新条件にする。公式発表の事実とGXOの見解である配点・費用例を分離している。個別企業への攻撃経路を一般化できないという限界があり、自社侵害の有無を保証しない。兆候・ログ欠落・委託先不明がある企業はインシデント対応相談が向く。平時の委託先・システム責任分界から見直す場合はシステム相談、緊急性の判断がつかない場合は状況を連絡することもできる。