KDDI情報漏洩とは｜ISPメールのパスワード761万人分が平文、対象の見分け方・原因と利用者がやること

KDDI情報漏洩は、KDDI が ISP（インターネット接続事業者）向けに提供していたメールシステムへの不正アクセスです。2026年6月23日に公表され、7月6日の続報で、メールアドレス12,231,954名分とパスワード7,616,173名分の漏えいが確認されました。個人情報保護委員会は8月19日、このパスワードが平文のまま保存されていて、盗んだ第三者がメールボックスの中身を読める状態だったと公表しています。

サプライチェーン全体の守り方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

KDDI情報漏洩の時系列

侵入が始まってから KDDI が確認するまで、約1か月ありました。総務省の指導文書は、5月16日から6月17日にかけての不正アクセスで、約762万人のメールボックス内の情報が閲覧可能な状態になっていたとしています。

何が起きたか——第三者製ソフトの脆弱性と平文保存

数字は出どころによって意味が違います。並べると次のとおりです。

KDDI情報漏洩の原因について、KDDI はシステムに組み込んでいた第三者製ソフトウェアの脆弱性が悪用されたとしています。製品名や脆弱性の識別番号は、当サイトが確認できた発表には書かれていません。

被害を大きくしたのは保存の仕方です。個人情報保護委員会は、KDDI が複数の ISP への提供を前提にシステムを開発しながら、多くのパスワードを平文で保存していたと指摘しました。侵入されたあとの被害の広がりを抑える多層的な対策が要るのに、アクセス制御などが十分でなかったとも判断しています。平文保存の一部は ISP 側の事情によるもので、その ISP も指導を受けました。どの ISP のどんな事情かは公表されていません。

総務省も、脆弱性の悪用に加えて、パスワードが暗号化などの安全管理措置なしに保存されていた点を問題にしています。パスワードがハッシュで保存されていれば、盗まれても元のパスワードには簡単に戻せず、そのままメールにログインすることはできません。平文だったため、盗まれた値がそのまま「受信箱の鍵」になりました。

対象の ISP とサービス

KDDI は対象を6社としています。各社の公式発表で確認できた内容は次のとおりです。漏れた範囲は事業者ごとに違います。

KDDI は、au メール・UQ mobile メール・au one net メールは別の設備で構築しており、影響や漏えいはないと説明しています。

KDDI情報漏洩の対策——利用者がやること

ISP 側が強制リセットや無効化を済ませていても、利用者の側に残る作業があります。

・契約先の案内を開く：ISP のサイトを自分で開いて確かめる。メールや SMS のリンクからは開かない
・メールのパスワードを変える：無効化された人は、ISP の手順で再設定する。メールソフトやスマートフォンに保存したパスワードも入れ直す
・使い回し先を変える：同じパスワードを使っている通販・SNS・クラウドなどを先に変える。個人情報保護委員会も、使い回し先へのリスト型攻撃に注意を呼びかけている
・受信箱を見直す：パスワード再設定のメール、請求書、本人確認の書類などが読まれた前提で、関係するサービスのパスワードや登録情報を確かめる
・名乗る連絡を疑う：ISP や KDDI を名乗る「パスワード変更」のメールは、本物の案内と見分けにくい

使い回しが狙われる仕組みと、サービス側の守り方は リスト型攻撃の対策｜他社で漏れたパスワードで自社が破られる仕組みと、パスワード漏洩確認の実装・ログでの検知 で扱っています。

開発者・運用者の対策と、自システムの確認コマンド

今回の事案から運用側が持ち帰れることは3つです。

メールサーバーには、平文が残りやすい事情があります。CRAM-MD5 や APOP のような認証方式は、サーバー側で平文か平文と同等の値を持たないと照合できません。古いクライアントのためにこうした方式を残していると、保存も平文のままになりがちです。今回の「ISP 側の事情」がこれに当たるかは公表されていないため、ここでは一般論として挙げます。ハッシュと暗号化の違いと移行の手順は パスワードのハッシュ化と暗号化の違い｜鍵ごと盗まれる保存をやめ、遅いハッシュとソルトへ移す手順を実測で解説 にまとめています。

自分のシステムが平文で持っていないかは、保存値の形で見分けられます。次のスクリプトは、1行1件の保存値を読み、既知のハッシュ形式に当たらない行の番号だけを出します（値そのものは表示しません）。

# check_pw_storage.py — 保存値を「遅いハッシュ / 速いハッシュ / 平文の疑い」に分ける
import re, sys

SLOW = [r"\$2[aby]\$\d\d\$", r"\$argon2(id|i|d)\$", r"\$scrypt\$", r"\$7\$", r"\$[56]\$",
        r"\$pbkdf2-sha(256|512)\$", r"pbkdf2_sha(256|1)\$", r"pbkdf2:sha(256|512)", r"scrypt:\d+"]
FAST = [r"\$1\$", r"[0-9a-fA-F]{32}", r"[0-9a-fA-F]{40}", r"[0-9a-fA-F]{64}"]

def classify(v):
    m = re.match(r"\{([A-Z0-9.-]+)\}(.*)", v)          # Dovecot 形式 {SCHEME}値
    if m:
        scheme, v = m.groups()
        if scheme in ("PLAIN", "CLEARTEXT", "PLAIN-TRUNC"):
            return "plaintext"
        if scheme in ("PLAIN-MD5", "MD5", "SHA", "SHA1", "SHA256", "SHA512"):
            return "fast-hash"
    if any(re.match(p, v) for p in SLOW):
        return "slow-hash"
    if any(re.fullmatch(p, v) for p in FAST):
        return "fast-hash"
    return "plaintext"                                  # どの形式にも当たらない＝平文の疑い

counts, flagged = {}, []
for n, line in enumerate(open(sys.argv[1], encoding="utf-8", errors="replace"), 1):
    v = line.rstrip("\n")
    if not v:
        continue
    c = classify(v)
    counts[c] = counts.get(c, 0) + 1
    if c == "plaintext":
        flagged.append(n)                               # 値そのものは表示しない
print(counts)
print("平文の疑いがある行:", flagged[:20], "…" if len(flagged) > 20 else "")
sys.exit(1 if flagged else 0)

SQLite の例で、パスワード列を書き出して渡します。Dovecot を使うメールサーバーなら、平文の保存方式を既定にしている設定も探せます。

sqlite3 -noheader app.db "SELECT password FROM users;" > pw.txt
python3 check_pw_storage.py pw.txt; echo "exit=$?"
rm pw.txt
grep -rnE '(default_pass_scheme *= *|scheme=)(PLAIN|CLEARTEXT)\b' /etc/dovecot/

Python 3.13.16・SQLite 3.45.1 で、陽性対照と陰性対照を作って確かめました。bcrypt・Argon2id・Django の pbkdf2_sha256・Werkzeug の scrypt・SHA512-CRYPT（Dovecot の {SHA512-CRYPT}・{ARGON2ID} 付きを含む）の7件だけの表では、{'slow-hash': 7}・該当行なし・exit=0 でした。そこに平文1件、{PLAIN} 付き1件、塩なし MD5 を1件足した表では、{'slow-hash': 7, 'plaintext': 2, 'fast-hash': 1}・該当行 [8, 9]・exit=1 になりました。grep は default_pass_scheme = PLAIN と scheme=CLEARTEXT を置いた設定で2行を出し、ARGON2ID・SHA512-CRYPT だけの設定では何も出しませんでした（PLAIN-MD5 も当たります。これも塩のない速いハッシュなので見直す対象です）。

PostgreSQL や MySQL でも、パスワードの列を1行1件のテキストに書き出せば同じスクリプトに渡せます。書き出したファイルは確認が済んだらすぐに消してください。32桁などの16進だけの平文パスワードは「速いハッシュ」に数えられるため、fast-hash が出たら中身の作り方を設計書で確かめます。

この結果は、保存値の形から見た目安です。判定ではありません。slow-hash だけでも、計算コストの設定が弱ければ安全とは言えません。逆に平文の疑いが出ても、その列を照合に使っていない場合があります。最終判断は、ログインの照合処理と設計書で確かめてください。

影響範囲と、続報で見るべき点

漏えいを確認したのは、KDDI のメール基盤を使う ISP 6社の利用者で、メールアドレス12,231,954名分、パスワード7,616,173名分です。パスワードが漏れた人は、メールボックスの中身を読まれうる状態でした。実際にどの受信箱が読まれたか、二次被害が出ているかは、当サイトが確認できた発表の範囲では分かっていません。

続報では次の点を見ると、自分の対応を見直しやすくなります。

・個人情報保護委員会への報告（期限10月19日）と、総務省への四半期ごとの報告で示される再発防止策
・悪用された第三者製ソフトウェアの製品名と、同じ製品を使う他の事業者への影響
・不正ログインや、受信箱の情報を使ったなりすましなどの二次被害の報告

続報が出たら、本記事も更新します。

参照ソース

• KDDI「ISP 事業者向けメールシステムに対する不正アクセスの発生について」2026-06-23
• KDDI 報道発表資料 2026-07-06（2026-07-21 更新）
• 個人情報保護委員会「ＫＤＤＩ株式会社及びインターネットサービスプロバイダに対する個人情報の保護に関する法律に基づく行政上の対応並びにメールサービス利用者に対する注意喚起」2026-08-19
• 個人情報保護委員会「メールサービス利用者に対する注意喚起」2026-08-19
• 総務省「KDDI株式会社に対する報告徴収」
• 総務省「KDDI株式会社に対する通信の秘密の保護に係る措置（指導）」 と 指導文書（総基用第71号）
• ビッグローブ「BIGLOBEメール」への不正アクセス発生のお詫びとご報告
• ニフティ【第二報】当社メールサービスへの不正アクセスについて
• JCOM（更新）当社メールサービスに対する不正アクセスの発生について
• 中部テレコミュニケーション「コミュファ光・ビジネスコミュファのメールサービスに対する不正アクセスの発生について」（題名のみ確認）
• STNet「弊社メールサービスへの不正アクセス事案の発生について」（題名のみ確認）
• CPI（KDDIウェブコミュニケーションズ）「弊社メールサービスへの不正アクセスに関する調査結果および対応完了のご報告」