セキュリティ

ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期

ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期

ふるさと納税サイト「ふるさとチョイス」を運営するトラストバンクは、2026年10月20日、会員情報4,454,097件が不正アクセスで外部に流出したと公表しました。流出したのは氏名、メールアドレス、住所、電話番号、ハッシュ化されたパスワード、寄附控除試算額の6項目です。本記事では、寄附者が知りたい「自分は対象か」「パスワードはどうするか」「いつ再開するか」「届いた連絡は本物か」に公式発表の文言で先に答えます。10月5日に公表された別の漏えい（Amazon Pay寄付手続きの不具合）との違いも整理しました。後半では、会員サービスを運営する側に向けて、全会員のパスワード再設定で流出済みパスワードを弾く実装と、外部決済から戻る処理を安全側に止める実装を、手元で動かしたPythonで示します。

まとめ：ふるさとチョイス不正アクセスで公表された事実と寄附者が今日やること

確定しているのは次の事実です。10月19日に通常と異なるアクセス傾向を把握して確認したところ、10月17日（土）に不正アクセスがあり、会員の個人情報が外部に流出したことが判明しました。同日15時50分に「ふるさとチョイス」関連サービスを停止し、外部の専門家と調査を進めています。件数と項目は現時点のもので、今後の調査で変わる可能性があると明記されています。

寄附者が今日やることは1つです。ふるさとチョイスと同じメールアドレスとパスワードの組み合わせを他のサービスで使っているなら、そちらのパスワードを変えてください。運営側が学べるのは、全会員に再設定を求める局面で、流出済みの弱いパスワードを再び登録させない仕組みが要る点です。

項目 公表されている内容（10月20日時点）
不正アクセスの日 2026年10月17日（土）
把握と停止 10月19日（月）把握・15時50分に停止
流出件数 4,454,097件（今後変動の可能性）
流出した項目 氏名・メール・住所・電話・PWハッシュ・控除試算額
侵入経路 未公表（検知した脆弱性に対応中）
再開時期 未定（安全性の確認状況を踏まえて決定）
当局への対応 10月20日に個人情報保護委員会へ報告完了

表中のメールはメールアドレス、PWハッシュはハッシュ化されたパスワード、控除試算額は寄附控除試算額を指します。

寄附者が最初に確かめる5点｜対象確認・パスワード・再開時期・偽連絡・控除試算額

会員登録をしていれば対象になり得る前提で動くのが安全な理由と問い合わせ先

10月20日の発表は、対象を「ふるさとチョイス」の会員情報としています。445万件という件数は会員として登録した寄附者を対象にした数字で、個別に対象かどうかを確かめる方法や、本人への個別連絡の段取りは書かれていません。会員登録をしていれば対象になり得る、と考えて動くのが安全です。

会員登録をせずに寄附した人が含まれるかは、発表からは判断できません。寄附者向けの問い合わせ窓口は、発表の末尾に載っているトラストバンクのメールアドレスです。連絡の真偽を確かめるときも、発表ページに書かれた宛先を使ってください。

同じパスワードを使い回している他サービスから先に変更する順番

発表は、同じメールアドレスとパスワードの組み合わせを他のサービスで使っている場合、不正ログインを防ぐため他のサービスのパスワードを変えるよう求めています。ふるさとチョイスはサービスごと止まっているので、今このサイトでパスワードを変える手段はありません。

先に変える順番は、メールアカウント、ネット銀行と決済、通販サイトの順が目安です。メールを乗っ取られると、他のサービスのパスワード再設定まで奪われます。使い回しを避ける決め方はパスワード管理のベストプラクティスで整理しています。

再開時期は未定で安全性の確認状況を踏まえ決定次第知らせる段階

発表は、サービスの再開時期は現時点で未定で、安全性の確認状況を踏まえて決まり次第知らせるとしています。2026年10月21日に当社が確認した時点で、furusato-tax.jpのトップページは応答コード503（サービス一時停止）を返していました。

年末に向けて寄附を予定している人は、再開を待つか、自治体の受付窓口や他の手段で寄附するかを決める必要があります。寄附の上限額の考え方はふるさと納税の仕組み、確定申告で寄附金控除を受ける手順はふるさと納税の確定申告のやり方で解説しました。

トラストバンクや自治体を装うメール・SMS・電話・郵便物への注意

発表は、同社や関係先を装った不審なメール、SMS、電話、郵便物に注意するよう呼びかけています。流出項目に住所と電話番号が入っているため、メールだけでなく郵便と電話の詐欺にも使われ得る点が、メールアドレス中心だった他の事案と違います。身に覚えのないメールやSMSのURLと添付ファイルは開かず、不審なサイトにパスワードを入力しないでください。

「再開に伴う再設定」「お詫びのポイント付与」をうたう連絡は、本物の案内がいずれ来る前提があるぶん信じやすい内容です。連絡のリンクからではなく、自分でブラウザに公式サイトのアドレスを入れて確かめます。最新のフィッシング報告はフィッシング対策協議会が公開しています。

寄附控除試算額が流出したことで推測され得る情報と気をつける連絡

寄附控除試算額は、控除を受けられる寄附の上限額をサイト上で見積もった値です。上限額は年収や家族構成から計算するので、試算額から収入のおおよその水準を推測される可能性があります。これは当社の分析で、発表はこの点に触れていません。

氏名と住所と収入の目安がそろうと、資産運用や節税をうたう勧誘の宛先選びに使われかねません。「寄附金控除の手続きに不備がある」と税務の話を装う連絡にも注意してください。控除の手続きを自治体や税務署がメールのリンクで求めることは、通常ありません。

公式発表を時系列で確認する｜10月17日の不正アクセスから20日の流出公表まで

停止告知から流出公表までの2日間で分かったことと未公表の4点

10月19日の停止告知は「不正アクセスの疑いがある事象を検知した」として関連サービスを一時停止したという内容で、流出の有無は書いていませんでした。翌20日の発表で、流出の事実、件数、項目が初めて示されました。

日付 出来事
10月17日（土） 不正アクセス（20日発表で確認）
10月19日（月） 異常なアクセス傾向を把握・15時50分に停止
10月20日（火） 流出を公表・個人情報保護委員会へ報告完了
10月21日（水） 所轄警察署へ被害申告の予定（20日発表）

未公表のまま残っているのは、侵入経路と攻撃手法、パスワードのハッシュ方式、不正アクセスが17日の何時から続いたか、寄附履歴やお礼の品の配送先が含まれるかの4点です。発表は「検知した脆弱性」への対応を進めているとだけ書いており、本記事も手口を断定しません。漏えい時の報告の段取りは個人情報保護委員会への報告義務で整理しました。様式は個人情報保護委員会の「漏えい等の対応とお役立ち資料」にあります。

ハッシュ化されたパスワードでも他サービスの変更が求められる理由

ハッシュ化されたパスワードは、元の文字列をそのまま保存せず、元に戻せない形に変換した値です。そのままでは読めませんが、どの方式で変換したかは公表されていません。短いパスワードや辞書にある語は、方式によっては総当たりで割り出されます。

OWASP Password Storage Cheat Sheetは、Argon2idをメモリ19MiB・反復2・並列度1以上で使い、古いシステムでbcryptを使うならwork factorを10以上にするよう勧めています。これらは解読を遅らせる設定で、解読を不可能にはしません。ハッシュと暗号化の違いはハッシュ化とは、解読にかかる手間の見積もりは銀のさらの不正アクセスの記事で扱いました。

10月5日公表のAmazon Pay寄付手続きの不具合254件と今回の不正アクセスの違い

別の利用者の申込情報が画面に出た不具合の対象期間と原因の公表内容

トラストバンクは今回の2週間前、10月5日のお知らせで別の漏えいを公表していました。Amazon Payを使った寄付手続きで、他の利用者が入力した個人情報が別の利用者の画面に表示される可能性があったという内容です。

比較項目 10月5日公表 10月20日公表
種類 自社システムの不具合 第三者による不正アクセス
件数 254件（閲覧可能な状態） 4,454,097件（流出）
期間 2025年11月13日〜2026年9月7日 2026年10月17日
項目 氏名・住所・電話・メール・配送先等 氏名・メール・住所・電話・PWハッシュ・控除試算額
状態 修正完了・継続して発生しない サービス停止中・調査中

2つの事案の関連は、どちらの発表にも書かれていません。10月5日の事案で通知を受けた人と、今回の会員とは別の集団として扱う必要があります。

識別情報が取れなかったときに処理を止めなかった復元処理の確認不足

10月5日の発表によると、原因はAmazon Payの認証後に申込情報を復元する処理で、利用者を識別する情報が取得できなかった場合の確認が不十分だったことです。本来は処理を止めるべきところで、別の利用者の申込情報を取得し得る状態になっていました。Amazon Payの決済機能に起因するものではないとも明記しています。

254件のうち19件が申し込み画面まで進み、6件が決済手続きまで進みましたが、いずれも操作した本人のAmazonアカウントによるもので、不正な決済は確認されていません。修正の中身は「識別情報が不足または不正確な場合に処理を停止する」です。この型の不具合を作らない書き方を、後半のコードで示します。

再設定時の流出パスワード照合｜Pwned PasswordsのPython実装例

NIST SP 800-63B-4のblocklist照合とパスワード最小15文字

全会員にパスワードの再設定を求めるとき、運営側が入れるべき仕組みは、新しいパスワードを既知の流出パスワードと照合する処理です。NIST SP 800-63B-4は、パスワードの設定や変更の際に、よく使われる値や流出済みの値を集めたblocklistと照合することを必須（SHALL）にしています。一致したら別のパスワードを選ばせ、理由も示します。

同じ文書は、単要素で使うパスワードを最低15文字、多要素認証の一部として使う場合は最低8文字とし、文字種の混在ルールは課さないとしています。定期的な変更の強制は禁じる一方、侵害の証拠がある場合は変更を強制するとしています。今回のような流出は、まさに強制変更の場面です。

SHA-1の先頭5文字だけを送るrange APIで再設定時に照合するスクリプト

照合の相手には、Have I Been PwnedのPwned Passwords APIが使えます。パスワードのSHA-1ハッシュの先頭5文字だけを送ると、同じ先頭を持つハッシュの残り35文字と出現回数の一覧が返り、一致の判定は手元で行います。パスワードそのものも完全なハッシュも外に出ない方式で、API キーは不要です。Add-Paddingヘッダーを付けると、応答の件数が800〜1,000件に水増しされ、応答サイズから検索内容を推測されにくくなります。次のコードをpwned_check.pyとして保存します。

import hashlib, sys, urllib.request

# 再設定時に入力されたパスワードが既知の流出パスワードかを判定する
# Pwned Passwords の range API には SHA-1 の先頭5文字だけを送る（k-匿名性）
def pwned_count(password: str) -> int:
    sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    req = urllib.request.Request(
        f"https://api.pwnedpasswords.com/range/{prefix}",
        headers={"User-Agent": "pw-reset-check", "Add-Padding": "true"},
    )
    with urllib.request.urlopen(req, timeout=5) as res:
        body = res.read().decode("utf-8")
    for line in body.splitlines():
        h, count = line.split(":")
        if h == suffix:
            return int(count)  # パディング行は count=0 で返る
    return 0

def validate_new_password(password: str) -> str:
    if len(password) < 15:
        return "NG: 15文字以上にしてください"
    try:
        n = pwned_count(password)
    except OSError:
        return "HOLD: 照合できないため再設定を保留"  # 照合不能で素通りさせない
    if n > 0:
        return f"NG: 過去の流出データに{n:,}回出現"
    return "OK"

for pw in sys.argv[1:]:
    print(f"{pw!r:28} {validate_new_password(pw)}")

2026年10月21日に、Python 3.14.7で実行した結果です。17文字の「password123456789」は長さの条件を満たしますが、流出データに38,884回出ていたため弾かれました。

$ python pwned_check.py furusato2026 "P@ssw0rd" password123456789 kumo-sango-hashi-1027
'furusato2026'               NG: 15文字以上にしてください
'P@ssw0rd'                   NG: 15文字以上にしてください
'password123456789'          NG: 過去の流出データに38,884回出現
'kumo-sango-hashi-1027'      OK

全会員の一斉再設定で照合APIが落ちたときの扱いと自前リストへの切り替え

コードは照合に失敗したとき、OKにせず「保留」を返します。全会員の再設定が始まった直後は、外部の照合先への問い合わせ件数も一気に増える状況です。外部APIが応答しないときに素通りさせると、弱いパスワードがまとめて登録されます。

会員数が数十万件を超えるなら、Pwned Passwordsのハッシュ一覧を自社側に取り込み、外部に問い合わせない照合に切り替える設計も検討してください。再設定画面への集中は、2026年10月のソースネクストの不正アクセスでも起きました。OWASP Credential Stuffing Prevention Cheat Sheetは、多要素認証と流出パスワードの照合を、使い回しによる不正ログインへの主な対策に挙げています。Cognitoでの管理者リセットとロックアウトの設計はCognitoのパスワードリセット実装にまとめました。

外部決済から戻る復元処理を安全側で止める｜識別子が欠けたときのfail-closed実装

識別子が取れないとき直近の申込に落ちる実装と止める実装を並べたコード

10月5日の事案の原因は、識別情報が取れないときに処理を続けたことでした。外部決済の画面から戻った後に、入力途中の申込を復元する処理は多くのECや寄付サイトにあります。次のコードは、識別子が欠けたときに「直近の申込」へ落ちる実装（fail-open）と、止める実装（fail-closed）を並べたものです。データは架空で、restore_failclosed.pyとして保存します。

# 外部決済から戻った後に申込情報を復元する処理の比較
# 識別子が取れないときに「直近の申込」へ落ちる実装（fail-open）と、止める実装（fail-closed）
DRAFTS = {  # 申込の下書き（キー = 復元用トークン）
    "tok-A": {"owner": "user-A", "name": "佐藤 花子", "zip": "100-0001"},
    "tok-B": {"owner": "user-B", "name": "鈴木 一郎", "zip": "530-0001"},
}
LATEST = "tok-B"  # 直前に保存された下書き

class RestoreError(Exception):
    pass

def restore_fail_open(session):
    token = session.get("restore_token") or LATEST  # 取れなければ直近へ落ちる
    return DRAFTS[token]

def restore_fail_closed(session):
    token = session.get("restore_token")
    if not token or token not in DRAFTS:
        raise RestoreError("復元トークンなし: 入力画面へ戻す")
    draft = DRAFTS[token]
    if draft["owner"] != session.get("user_id"):
        raise RestoreError("所有者不一致: 入力画面へ戻す")
    return draft

# user-A の戻り遷移で、セッション切れなどにより復元トークンが失われたケース
session_a = {"user_id": "user-A"}
print("fail-open  :", restore_fail_open(session_a))
try:
    print("fail-closed:", restore_fail_closed(session_a))
except RestoreError as e:
    print("fail-closed:", e)

2026年10月21日にPython 3.14.7で実行すると、fail-open側はuser-Aの画面にuser-Bの氏名と郵便番号を返しました。fail-closed側は入力画面へ戻します。

$ python restore_failclosed.py
fail-open  : {'owner': 'user-B', 'name': '鈴木 一郎', 'zip': '530-0001'}
fail-closed: 復元トークンなし: 入力画面へ戻す

トークンの有無と所有者の一致を両方確かめる2段の検査が要る理由

fail-closed側は2回確かめています。1回目は復元トークンがあるか、2回目はそのトークンの下書きが今のログイン利用者のものか、です。トークンの有無だけを見ると、推測や使い回しで他人のトークンが渡されたときに防げません。

この不具合は、通常の操作ではほぼ再現しません。セッション切れ、ブラウザの戻る操作、決済画面で時間を置いた後の戻り遷移といった外れた経路でだけ起きます。テストでは、識別子を意図的に欠落させた状態での戻り遷移を必ず1本入れてください。API応答に他人のデータが混ざる型の不具合はOfferBoxの情報漏洩でも扱いました。

再設定の照合と復元処理の点検を今月中に進める事業者と後回しでよい事業者

自社で会員DBを持ち外部決済から戻る画面があるEC・寄付・予約サイト

自社で会員DBを持ち、会員数が数十万件を超え、外部決済から戻って申込を復元する画面があるなら、今月中に2点を確かめてください。1点目は、再設定と新規登録のパスワードを流出パスワードと照合しているか。2点目は、復元処理が識別子の欠落と所有者の不一致で止まるかです。前者はコードの数十行で入り、後者はテストケースの追加で確かめられます。

APIの認可とレート制限、トークン失効はAPI不正アクセス対策の実装手順で扱いました。外れた経路のテストを自社で洗い出しきれないとき、侵入経路も含めて第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、認証・再設定・決済連携の画面遷移を含めて点検できます。

認証を外部のIDaaSに任せ自社でパスワードを持たない小規模サービス

パスワードを自社で持たず、認証を外部のIDaaSに任せているなら、流出パスワードの照合を自前で組むのは過剰です。IDaaS側に流出パスワードの照合機能があるかを確かめ、あれば有効にすれば足ります。その場合も、外部決済から戻る復元処理は自社のコードなので、fail-closedの点検は省けません。

よくある質問

ふるさとチョイスの不正アクセスについて、寄附者と会員サービスを運営する担当者から出やすい質問をまとめました。

ふるさとチョイスはいつ再開しますか？

10月20日の発表は、再開時期を現時点で未定とし、安全性の確認状況を踏まえて決まり次第知らせるとしています。2026年10月21日時点で再開日の発表はなく、サイトは停止中でした。告知はトラストバンクのニュースルームで確かめてください。SNSの転載は日付が古いことがあります。

ふるさとチョイスのパスワードは今すぐ変えるべきですか？

サービスが止まっているため、今は変えられません。今やるのは、同じメールアドレスとパスワードを使っている他社サービスの変更です。メールアカウントを最初に変えてください。再開時の再設定の方法は発表されていないので、案内を装うメールのリンクからではなく、公式サイトを自分で開いて手続きします。

クレジットカードは止める必要がありますか？

10月20日の発表の流出項目に、クレジットカード情報は入っていません。本件を理由にカードを止める必要は、公表された事実からは読み取れません。明細に覚えのない請求があれば、本件とは別にカード会社へ問い合わせてください。

10月5日のAmazon Payの件で連絡が来た人は、今回とは別ですか？

別の事案です。10月5日の件は自社システムの不具合で、2025年11月13日から2026年9月7日の間にAmazon Payで寄付手続きをした利用者のうち254件が対象でした。今回は10月17日の不正アクセスで、会員情報4,454,097件が対象です。両方に当てはまる人もいる可能性があります。

自社サイトで全会員にパスワード再設定を求めるとき、何を入れればよいですか？

新しいパスワードを流出パスワードの一覧と照合し、一致したら理由を示して別の値を選ばせる処理を入れます。NIST SP 800-63B-4は単要素なら最低15文字を求めています。照合先に問い合わせできないときは、登録を保留にして素通りさせません。再設定を案内するメールには、本文中のリンクに頼らない手順も書き添えます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る

目次