title: "KDDI ISP向けメールシステムに不正アクセス 最大約1,422万件のメールアドレス・パスワード漏えいの可能性【第三者製ソフトの脆弱性が起点】" slug: "kddi-isp-mail-unauthorized-access" description: "KDDIのISP事業者向けメールシステムが不正アクセスを受け、最大約1,422万件のメールアドレス・パスワードに漏えいの可能性。第三者製ソフトの脆弱性という起点を、情シス・CISOがどう自社防御に落とすかを解説。" lead_summary: "KDDIがISP6社向けに提供するメールシステムが不正アクセスを受け、最大約1,422万件の認証情報に漏えいの可能性。起点は自社が利用する第三者製ソフトの脆弱性だった。第三者製部品の棚卸し・脆弱性管理・検知と初動という防御設計の観点で整理する。" date: "2026-06-28" updatedAt: "2026-06-28" category: "セキュリティ" tags: ["不正アクセス", "サプライチェーン", "脆弱性管理", "認証情報漏えい", "ISP", "インシデント対応", "パスワード"] author: "GXO株式会社"
結論：自社が「使っている」第三者製ソフトの脆弱性は、自社サービスの認証情報漏えいに直結する
2026年6月23日、KDDIはISP（インターネットサービスプロバイダ）事業者向けに提供するメールシステムが不正アクセスを受け、最大で約1,422万件のメールアドレスとパスワードが漏えいした可能性があると公表しました。起点となったのは、このシステムが利用していた「第三者製ソフトウェアの脆弱性」です。対象は外部ISP6社（STNet、KDDIウェブコミュニケーションズ、JCOM、中部テレコミュニケーション、ニフティ、BIGLOBE）にまたがります。
情シス・CISOがこの事案から持ち帰るべき教訓は単純です。自社が一行もコードを書いていない「第三者製の部品」であっても、それが認証情報を扱う経路上にあれば、脆弱性は自社サービスの大量漏えいに直結します。本記事は攻撃手法ではなく、第三者製部品の棚卸し・脆弱性管理・検知と初動・パスワード更新運用という防御設計の観点に絞って整理します。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
公表された事実の整理
報道発表で確認できた範囲を時系列で整理します。確認できなかった項目（脆弱性の具体名・CVE番号など）は本記事では扱いません。
| 項目 | 内容 |
|---|---|
| 把握日 | 2026年6月17日 |
| 公表日 | 2026年6月23日 |
| 影響を受けたシステム | KDDIがISP事業者向けに提供するメールシステム |
| 漏えいの可能性がある情報 | メールアドレス、パスワード（ハッシュ化・暗号化されたものを含む） |
| 最大件数 | 約1,422万件 |
| 起点 | システムが利用していた第三者製ソフトウェアの脆弱性の悪用 |
| 対象ISP | STNet、KDDIウェブコミュニケーションズ、JCOM、中部テレコミュニケーション、ニフティ、BIGLOBE の6社 |
| 当局報告 | 個人情報保護委員会・総務省へ報告 |
| 実施した対応 | システム改修、技術的な防御措置、利用者へのパスワード変更呼びかけ |
KDDIは把握後にシステム改修と防御措置を講じ、利用者に対してパスワードの早期変更を呼びかけています。
本ネタ固有の独自分析：影響が「6社」へ広がった構造をどう読むか
この事案で見落としてはならないのは、影響が単一サービスにとどまらず6社のISPにまたがったという構造です。公表事実から導けるのは、ひとつの基盤システムが複数事業者へ提供される「OEM／共通基盤型」の供給形態だったという点です。つまり、ある事業者にとっての脆弱性は「自社が選定したソフトウェア部品」の問題ですが、その基盤を採用した各ISPにとっては「ベンダーが採用していた部品」の問題、すなわち二次・三次のサプライチェーンリスクとして降りかかってきました。
ここから導ける実務的な含意は、利用者へメールサービスを提供している各ISPが、自社では脆弱性を直接管理していなかった可能性が高いということです。共通基盤を採用する側は、コスト効率と引き換えに「部品の脆弱性管理を委ねる」ことになります。だからこそ、委託・OEM契約においては、脆弱性の検知から通知、修正適用までのSLAと、インシデント時の情報連携フローを契約段階で握っておく必要があります。認証情報という最も価値の高いデータを扱う基盤ほど、この設計の有無が被害の広がりを左右します。
情シス・CISOが今日点検すべきチェックリスト
本事案を「自社で起きたら」という前提で読み替えるためのチェック項目です。禁止や精神論ではなく、棚卸しと運用に落とせる形で並べます。
- 認証情報（メールアドレス・パスワード・トークン等）を保存・経由する全システムを洗い出し、どの第三者製ソフト／コンポーネントに依存しているかを台帳化している
- 採用している第三者製ソフト・ライブラリのバージョンと、提供元の脆弱性情報（アドバイザリ）を受け取る購読チャネルを確立している
- OEM・共通基盤・SaaSを採用している箇所について、脆弱性の通知と修正適用に関する責任分界とSLAを契約で明確化している
- パスワードを平文または可逆な形で保持していないか、ハッシュ化・ソルト付与など保存方式を点検している
- 不正アクセスの検知（異常な大量アクセス・認証失敗の急増・想定外の経路からのアクセス）を監視し、アラートが運用担当へ届く体制がある
- 漏えい把握から当局報告・利用者通知・パスワード強制リセットまでの初動手順が文書化され、訓練されている
- 利用者へパスワード変更を依頼する際の正規の連絡経路と、フィッシングと誤認されない告知文面が準備されている
漏えいの可能性がある利用者側の備え
提供事業者だけでなく、メールサービスを使う側の対策も同時に重要です。とりわけパスワードの使い回しがある場合、ひとつのサービスでの漏えいが他サービスへの不正ログイン（リスト型攻撃）の入口になり得ます。心当たりのある利用者は、対象サービスのパスワードを変更するとともに、同じパスワードを使っている他サービスも併せて更新し、可能なサービスでは多要素認証を有効化しておくことが現実的な防御になります。
FAQ
Q. 何が漏えいした可能性があるのですか
公表されているのは、メールアドレスとパスワードに漏えいの可能性があるという点です。最大件数は約1,422万件とされています。
Q. 原因は何ですか
KDDIが利用していた第三者製ソフトウェアの脆弱性が悪用されたことが起点と公表されています。自社開発のコードではなく、採用していた外部部品が突破口になった点が本事案の特徴です。
Q. 自社サービスでも同種のリスクはありますか
認証情報を扱う経路に第三者製ソフトやライブラリ、共通基盤を使っている場合、同種のリスクは存在します。重要なのは、どの部品にどう依存しているかを台帳化し、脆弱性情報を継続的に受け取り、修正適用までの運用を回せているかどうかです。
Q. パスワードはすぐ変えるべきですか
対象サービスを利用していて漏えいの可能性が告知された場合は、早期の変更が推奨されます。同じパスワードを他サービスで使い回している場合は、それらも併せて変更してください。
Q. 委託先・OEM提供を受けている場合の責任はどうなりますか
技術的な脆弱性の管理主体と、利用者への説明・通知責任は必ずしも一致しません。契約上の責任分界、脆弱性通知のSLA、インシデント時の連携フローを事前に定義しておくことが、被害の拡大と対応の遅延を防ぎます。
GXOに相談すべきタイミング
次のいずれかに当てはまる場合は、外部の専門支援を入れる検討に値します。
- 認証情報を扱うシステムが第三者製ソフトや共通基盤に依存しているが、依存関係の棚卸しができていない
- 脆弱性情報の購読・トリアージ・修正適用の運用が属人化しており、SLAとして回っていない
- 漏えい把握から当局報告・利用者通知までの初動手順が未整備、または訓練したことがない
GXOでは、第三者製コンポーネントを含む構成の脆弱性診断や、漏えい・不正アクセスを想定したインシデント対応の体制づくりを支援しています。検知から初動までを継続的に支える運用はセキュリティ顧問サービスで、ゼロトラストを前提とした設計の考え方は中小企業向けゼロトラスト導入ガイドで整理しています。まずは現状を客観視したい場合は、セキュリティを含む全体像の相談窓口からご連絡ください。
