KDDIメール不正アクセス最大1,422万件漏洩の可能性｜対象6社と今すぐやること

2026年6月23日にKDDIが公表したISP向けメールシステムへの不正アクセス事案を正確に解説。対象6社の確認方法と、利用者・開発者それぞれが今すぐ取るべき具体的な対策をまとめました。

「自分も対象かもしれない」と思ったら、まずこの記事を読んでください

2026年6月23日、KDDIはISP事業者向けに提供しているメールシステムが不正アクセスを受けたことを公式に発表しました。最大1,422万件のメールアドレスおよびパスワードが漏洩した可能性があるとされており、@niftyやBIGLOBE、J:COMといった馴染みのあるサービスのユーザーも対象に含まれます。

「自分のメールアドレスは大丈夫？」「パスワードを変えた方がいい？」——そう感じた方は、この記事で確認すべきことが整理できます。逆に「自分には関係ない」と思った方も、同じパスワードを複数のサービスで使い回している場合は他人事ではありません。

この記事では、確認済みの事実をもとに事案の概要・対象サービスの確認方法・今すぐ取れる具体的な対策を、利用者向けと開発者・運用担当者向けに分けて解説します。煽ることなく、でも必要な危機感は正確に伝えることを心がけました。

1. 何が起きたか——事実を時系列で整理する

事案の概要

KDDIがISP（インターネットサービスプロバイダー）事業者向けに提供しているメールシステムが、外部からの不正アクセスを受けました。原因はそのシステムで利用していた第三者製ソフトウェアの脆弱性が悪用されたことによるものです。KDDIの公式発表によると、2026年6月17日に不正アクセスを確認し、同日中に改修および防御措置を講じています。

漏洩した可能性があるのはメールアドレスとパスワードで、最大1,422万件とされています。ただし、これはあくまで「漏洩した可能性がある最大数」であり、実際にすべてが外部に持ち出されたことが確定しているわけではありません。KDDIおよび対象ISPは現在も被害範囲の調査を継続しています。

パスワードについては、ハッシュ化・暗号化された状態のものも含まれるとKDDIは説明しています。ハッシュ化されていれば即座に平文パスワードとして悪用されるリスクは低減されますが、使用されているアルゴリズムや強度によっては解読されるリスクがゼロとは言えません。

また、現在サービスを解約済みの方や、長期間利用していない休眠アカウントも対象に含まれうる点には注意が必要です。「昔使っていたメールアドレスだから関係ない」とは言い切れない状況です。

2. 対象6社と「自分が対象かどうか」の確認方法

対象となる6つのISP

※ドメインはあくまで代表例です。各サービスには複数のドメインが存在する場合があります。公式サイトで正確なドメイン一覧をご確認ください。

確認の手順

1. 現在使用中のメールアドレスのドメイン（@以降の文字列）を確認する
2. 上記6社のいずれかに該当するか照合する
3. 該当する場合、または過去に利用していた可能性がある場合は、次のセクションの対策を実施する
4. 各ISPの公式サイトやお知らせページで個別の案内が出ているので、そちらも確認する

「使っているかどうか覚えていない」という方は、登録済みサービスの一覧を確認するか、パスワード管理ツールに保存されているメールアドレスのドメインを確認してみてください。

3. 【今すぐやること】利用者向け5つの具体的対策

事案が公表された直後は、焦って誤った操作をしてしまうケースも少なくありません。落ち着いて、以下の手順を順番に実施してください。

① 該当メールサービスのパスワードを変更する

最優先で対応すべきはこれです。各ISPの公式サイトにログインし、パスワード変更の手続きを行ってください。その際、新しいパスワードは他のサービスで使用していないものを設定することが重要です。

強いパスワードの目安は以下の通りです。

• 12文字以上
• 英大文字・英小文字・数字・記号を組み合わせる
• 辞書に載っている単語や誕生日など推測されやすい文字列を使わない
• パスワード管理ツール（1Password、Bitwarden等）を使って生成・管理する

② 同じパスワードを使い回している他サービスも変更する

これが特に重要です。仮に今回漏洩したパスワードが解読された場合、攻撃者は**同じメールアドレスとパスワードの組み合わせを他のサービスに試し、不正ログインを図る「パスワードスプレー攻撃」や「クレデンシャルスタッフィング攻撃」**を仕掛けてくる可能性があります。

銀行・ネットショッピング・SNS・業務システムなど、同じパスワードを使っているサービスがないか確認し、すべて変更してください。

③ 二段階認証（多要素認証）を設定する

パスワードが漏洩した場合でも、二段階認証が設定されていれば不正ログインのリスクを大幅に低減できます。各ISPおよび他の重要なサービスで二段階認証の設定が可能かどうかを確認し、可能であれば有効化してください。

認証アプリ（Google Authenticator、Authyなど）を使ったTOTP方式はSMSよりも安全性が高いためおすすめです。

④ フィッシングメールに警戒する

メールアドレスが漏洩した場合、そのアドレスを使って**「パスワード変更を促す偽メール」や「KDDIを装ったフィッシングメール」**が届く可能性があります。

以下の点に注意してください。

• メール内のリンクを直接クリックしない。公式サイトはブラウザから直接アクセスする
• 送信元のメールアドレスをよく確認する（偽装されている場合もあるため過信しない）
• 「今すぐパスワードを入力してください」と急かすメールは疑う
• 不審なメールは開封せず削除する

⑤ 漏洩確認サービスで状況を確認する

**Have I Been Pwned（haveibeenpwned.com）**は、入力したメールアドレスが過去の漏洩事案に含まれているかどうかを確認できる無料のサービスです。今回の事案データが反映されるまでには時間がかかる場合がありますが、過去の漏洩履歴を把握するためにも一度確認しておくことをおすすめします。

4. 【作る側の教訓】開発者・システム運用者が今回から学べること

今回の事案は「KDDI固有の問題」として他人事にするのではなく、Webシステムを構築・運用するすべての担当者が自分ごととして捉えるべき事案です。原因となった「第三者製ソフトウェアの脆弱性の悪用」は、あらゆるシステムに潜在するリスクです。

ソフトウェアコンポジション解析（SCA）と依存パッケージの定期更新

現代のWebシステムは、自社で書いたコードだけでなく、多数のオープンソースライブラリや第三者製コンポーネントの上に成り立っています。これらのいずれかに脆弱性が発見された場合、そのシステム全体がリスクに晒されます。

**ソフトウェアコンポジション解析（SCA: Software Composition Analysis）**は、使用している依存パッケージの脆弱性を継続的に検知するための手法です。GitHub Dependabot、Snyk、OWASP Dependency-Checkといったツールを導入し、脆弱性が報告されたパッケージを迅速に検知・更新する仕組みを整えることが重要です。

# composer.jsonの依存関係を確認
composer audit

# パッケージを最新の安全なバージョンに更新
composer update --with-all-dependencies

# セキュリティアドバイザリを確認
composer require --dev roave/security-advisories:dev-latest

# 脆弱性のある依存パッケージを一覧表示
npm audit

# 自動修正可能なものを更新
npm audit fix

# 詳細な脆弱性レポートを確認
npm audit --json | jq '.vulnerabilities'

定期的な実行だけでなく、CI/CDパイプラインに組み込んでデプロイ前に自動チェックが走る仕組みにすることが、より効果的な運用につながります。

パスワードは必ずハッシュ化して保存する

今回の事案では、漏洩した可能性があるパスワードには「ハッシュ化・暗号化されたものも含まれる」とKDDIは説明しています。これは言い換えれば、ハッシュ化されていないパスワードも含まれる可能性を示唆しています。

パスワードの保存にはbcryptやArgon2といった、パスワードハッシュ専用のアルゴリズムを使用することが現在の標準的なプラクティスです。MD5やSHA-1は速度が速すぎるためブルートフォース攻撃に弱く、パスワード保存には適していません。

<?php
// Laravel での推奨例
// config/hashing.php でドライバーを指定
// 'driver' => 'bcrypt' または 'argon2id'

use Illuminate\Support\Facades\Hash;

// パスワードのハッシュ化（保存時）
$hashedPassword = Hash::make($plainPassword);
// → bcryptまたはArgon2idで自動的にハッシュ化される

// パスワードの照合（ログイン時）
if (Hash::check($plainPassword, $hashedPassword)) {
    // 認証成功
}

// ハッシュの再計算が必要か確認（設定変更後などに）
if (Hash::needsRehash($hashedPassword)) {
    $hashedPassword = Hash::make($plainPassword);
    // DBに再保存する
}

Laravelはデフォルトでbcryptを使用しており、適切に設定されていれば安全なハッシュ化が行われます。ただし、独自実装やレガシーコードが混在するシステムでは、平文保存や脆弱なアルゴリズムが使われていないか定期的な監査が必要です。

最小権限の原則と監査ログの整備

システムの各コンポーネントが必要以上のアクセス権限を持っていると、ひとつの脆弱性が突かれた際の被害範囲が広がります。**最小権限の原則（Principle of Least Privilege）**に基づき、データベースユーザー・APIキー・サービスアカウントにはそれぞれ必要最小限の権限のみを付与してください。

あわせて、**監査ログ（アクセスログ・操作ログ）**を適切に記録・保存しておくことで、不正アクセスが発生した際の検知と事後調査が容易になります。ログが存在しなければ「何が起きたか」すら把握できません。

脆弱性公表後の迅速なパッチ適用

ソフトウェアの脆弱性は、公表された瞬間から悪用が急増します。「次の定期メンテナンスのときに対応しよう」という判断が、取り返しのつかない事態を招くことがあります。重要度の高い脆弱性（CVSSスコアが高いもの）については、緊急パッチ適用のフローを事前に定めておくことをおすすめします。

5. まとめ——落ち着いて、でも確実に対処を

今回のKDDI事案は、規模は大きいものの、利用者側でできる対策は明確です。「漏洩した可能性がある」という段階であること、そしてKDDIが発覚後すぐに防御措置を講じていることは、確認済みの事実として押さえておきましょう。

不確実な情報に振り回されず、以下の対処を順番に実施するだけで、リスクの大部分は低減できます。

セキュリティ対策について相談したい方へ

Webサイトやシステムのセキュリティ対策、依存パッケージの脆弱性管理、パスワード管理の仕組みについてご不安をお持ちの方は、Fivenine Designまでお気軽にご相談ください。初回のご相談は無料で承っています。「何から手をつければよいかわからない」という段階からでも、一緒に整理するお手伝いができます。