リンツ不正アクセス：314万件の対象確認とパスワード強制リセット後の対処

チョコレートブランド「リンツ」の日本法人であるリンツ＆シュプルングリージャパンは2026年10月23日、オンラインショップと公式アプリの会員情報3,147,469件が第三者に取得されたと公表しました。会員情報の管理を委託していたフューチャーショップのサーバーで、ソフトウェアの脆弱性が悪用されたものです。本記事の前半は、自分は対象か、パスワードやアプリのポイントはどうなるのか、届いた連絡は本物かという会員の疑問に、公式発表の文言で答えます。後半では会員サイトの開発者向けに、ハッシュ化したパスワードが漏れたときに何が起きるかと、保存方式の見直しをPythonのコードで示します。

まとめ：リンツ不正アクセスで漏えいした314万件の会員情報と会員がまずすること

漏えいしたのは、オンラインショップと公式アプリで共通の会員情報です。氏名、住所、電話番号、メールアドレス、生年月日に加え、ハッシュ化されたログインパスワードも含まれます。クレジットカード情報は、オンラインショップが保存しない仕組みのため対象外とされています。

会員がまず押さえることは3つです。ログインパスワードは10月26日に強制リセット済みで、オンラインショップの再開時に再設定が要ります。同じパスワードを他のサービスでも使っているなら、そちらは今すぐ変えてください。そして、リンツを名乗るメールやSMS、電話でパスワードやカード番号を聞かれても答えないことです。開発者が受け取る教訓は、パスワードの保存方式を漏えいする前提で選び直すことにあります。

会員が最初に確かめること：対象の範囲、パスワード再設定、届く連絡の真偽と窓口

2026年10月18日0時16分の時点で会員だった人が対象になる範囲と漏れた項目

リンツの会員情報の漏えいに関するお知らせによると、対象はオンラインショップと公式アプリに登録している会員です。情報が取得された10月18日0時16分の時点で退会済みの会員は含まれません。店舗だけで買い物をしていて、オンラインショップにもアプリにも登録していない人は、発表上の対象に当たりません。

漏れた項目は、会員ID、氏名、フリガナ、メールアドレス、住所、電話番号、生年月日、性別、メールマガジンの受信設定、登録店舗の情報、ハッシュ化したログインパスワード、会員登録日時、最終ログイン日時などです。対象の会員には、登録メールアドレス宛てに10月27日から順次連絡するとしています。10月26日15時の時点で、漏えいした情報の悪用は確認されていないとのことです。

強制リセットされたパスワードの再設定と、同じパスワードを使う他サービスの変更

リンツは10月26日、対象会員のログインパスワードをシステム側で強制リセットしました。オンラインショップの再開時に再設定が必要で、手順は後日ページで案内するとしています。今の時点で、会員がリンツのサイトで行える操作はありません。

会員が今すぐできるのは、リンツと同じパスワードを使っている他のサービスの変更です。ハッシュ化されたパスワードはそのままでは読めませんが、短い・ありふれたパスワードは解析で割り出されるおそれがあります（理由は後半で説明します）。メールアドレスと組み合わせて別のサービスへのログインに試される前に、使い回しをやめるのが確実な備えです。考え方はパスワード管理のベストプラクティスで整理しています。

公式アプリを削除しないほうがよい理由と、店舗でのポイント付与・利用の扱い

公式アプリは10月26日からアプリストアでの公開が止まり、新規のダウンロードができません。パスワードのリセット後も、ログイン状態のままのアプリでは店舗でのポイント付与と利用を続けられると案内されています。一方で、アプリを削除すると、オンラインショップの再開まで再インストールも再ログインもできなくなります。ポイントを店舗で使う予定があるなら、アプリは残しておくほうが無難です。

停止中は、新規の会員登録、新規のログイン、会員情報の確認・変更、ポイント履歴や購入履歴の閲覧などのマイページ機能が使えません。オンラインショップは10月21日16時から一時停止しており、再開時期は未定です。停止前に受け付けた注文は予定どおり届けるとしています。

リンツを名乗るメール・SMS・電話の見分け方と会員専用ダイヤルの受付時間

リンツは、漏えいした情報を悪用し、リンツやオンラインショップを装った不審なメール、SMS、電話、郵便物が届くおそれがあると注意を呼びかけています。リンツがメールや電話でパスワードやクレジットカード情報を尋ねることはありません。氏名と住所、生年月日を正しく言い当てる連絡でも、それだけで本物とは判断できない状況です。

確かめるときは、届いた連絡のリンクや番号を使わず、正規のドメイン（www.lindt.jp）から入るか、会員専用ダイヤルにかけ直します。番号は0120-713-065、受付は9時〜21時（土日祝を含む）です。メールの窓口は privacy-incident-jp＠lindt.jp（＠は半角）です。偽の連絡の典型的な型はフィッシング詐欺の仕組みと実装者向けの対策で解説しています。

公式発表で整理する経緯：10月17日の侵入から10月27日の個別連絡までの時系列

リンツとフューチャーショップの2つの発表を突き合わせた発生順の一覧

リンツの発表と、委託先のフューチャーショップの第一報を並べると、経緯は次のとおりです。フューチャーショップの発表は店舗名を伏せていますが、件数3,147,469件と日時はリンツの発表と一致します。

1. 10月17日23時02分：フューチャーショップのサーバーで、ソフトウェアの脆弱性を悪用した不正アクセスが始まる
2. 10月18日0時16分：1店舗分の会員情報が取得される
3. 10月19日15時30分頃：システム監視で不審なアクセスを確認し、同日リンツに報告、脆弱性対策を実施
4. 10月21日16時：リンツがオンラインショップを一時停止
5. 10月23日：両社が公表、会員専用ダイヤルを11時に開設
6. 10月26日：パスワードを強制リセット、公式アプリのストア公開を停止
7. 10月27日：対象会員へのメール連絡を順次開始

侵入から情報の取得までは約1時間14分、判明までは約40時間です。両社は個人情報保護委員会へ連名で報告し、フューチャーショップは警察への相談と外部の専門機関による調査を進めるとしています。

同じ週にフューチャーショップが公表した3つの事象を混同しないための整理

フューチャーショップは10月25日に長時間メンテナンスと不正アクセス事案の説明を出し、同時期の3つの事象が別のものだと説明しています。1つ目が、PHPの重大な脆弱性への対策として10月21日21時36分から22日23時35分まで行ったメンテナンスです。futureshop本体はPHPを使っておらず、対象はPHPが動くオプションのサーバーとされています。

2つ目は、10月21日10時14分頃に検知した、関連サービスの脆弱性を突いた不正アクセスです。4台のサーバーを止め、ログ調査では個人情報の漏えいは確認されていないとしています。3つ目が、10月19日に判明した1店舗の会員情報の漏えいで、これがリンツの事案です。報道やSNSではこれらがまとめて語られがちですが、発表上はPHPの脆弱性がリンツの件の原因だとはされていません。

10月28日時点で公表されていない脆弱性の種類・ハッシュ方式・他店舗への波及

リンツの件で悪用されたソフトウェアと脆弱性の種類は、再発防止と二次被害防止のためとして非公表です。パスワードのハッシュ化にどの方式を使っていたかも書かれていません。他の店舗については、同様の手法で不正アクセスされた痕跡は確認されておらず、悪用された脆弱性への対策は全ての管理画面サーバーに施したとしています。本記事はこれらを推測で補いません。EC基盤の側で起きた侵害の先例はショップサーブ情報漏えいの最終報で整理しています。

ハッシュ化パスワードの漏えいで何が起きるか：オフライン解析と使い回しの連鎖

ハッシュ化されていても弱いパスワードが辞書照合で割り出される仕組み

ハッシュ化は、パスワードを元に戻せない値に変換して保存する方法です（暗号化との違いはハッシュ化とはで解説しています）。元に戻せない代わりに、攻撃者は候補のパスワードを同じ方式で変換し、漏れた値と一致するかを手元で試し続けます。サイトへのログイン試行と違い、回数制限もロックもかかりません。

OWASPのパスワード保存チートシートは、最新の方式と適切な設定なら強いパスワードの解読は事実上できないとする一方、GPUと安価なクラウドで攻撃側の計算コストは下がっていると指摘します。過去の漏えいデータにあるパスワードや辞書の単語から順に試されるため、短い・ありふれたパスワードほど先に割り出されます。どの程度持ちこたえるかを大きく左右するのは、保存に使った方式と設定です。

割り出されたパスワードが他のサービスへのログインに使われる流れと会員の備え

割り出されたパスワードは、同じメールアドレスで登録された別のサービスへのログインに試されます。リンツのパスワードはリセット済みでも、同じ組み合わせを通販サイトやメールサービスで使っていれば、そちらが入口になります。生年月日や電話番号も漏れているため、それらを含むパスワードは推測もされやすい状態です。

会員の備えは、使い回していたサービスのパスワード変更と、使えるサービスでの多要素認証やパスキーの設定です。パスキーはサーバー側に照合用の秘密を持たないため、今回のような漏えいで割り出される対象になりません（仕組みはパスキー認証とはを参照）。

会員サイトの開発者が見直す保存と登録：OWASPとNISTの基準に沿う実装例

OWASP推奨のArgon2id・scrypt・bcrypt・PBKDF2設定比較

OWASPのチートシートは、第一候補をArgon2idとし、使えない場合の代替を示しています。2026年10月時点の推奨パラメータを、方式ごとの比較表に示したものが次の表です。

bcryptの入力に設けられているのは、72バイトまでという長さの制限です。MD5やSHA-1のような高速なハッシュで保存している既存システムは、次回ログイン時に新しい方式で保存し直し、長く使われていない会員は旧ハッシュを消して再設定を求める移行が勧められています。方式と設定値をハッシュ値と一緒に記録しておくと、次の移行も段階的に進められます。

Python標準ライブラリのscryptで会員ごとのソルト付きハッシュを保存・照合する

追加のライブラリを入れずに済む例として、Pythonのhashlibのscryptを、OWASPの推奨値で使います。N=2^17・r=8では128MiBのメモリを使うため、既定の上限を引き上げる必要があります。

# OWASPの推奨値（scrypt N=2^17, r=8, p=1）でパスワードを保存・照合する（標準ライブラリのみ）
import base64
import hashlib
import hmac
import os

N, R, P = 2**17, 8, 1
MAXMEM = 256 * 1024 * 1024  # 128 MiB を使うので上限を引き上げる


def b64(b):
    return base64.b64encode(b).decode().rstrip("=")


def unb64(s):
    return base64.b64decode(s + "=" * (-len(s) % 4))


def hash_password(password):
    salt = os.urandom(16)  # 会員ごとに別のソルト
    dk = hashlib.scrypt(password.encode(), salt=salt, n=N, r=R, p=P,
                        maxmem=MAXMEM, dklen=32)
    return "$scrypt$ln=17,r=8,p=1$" + b64(salt) + "$" + b64(dk)


def verify_password(password, stored):
    _, _, _, salt_s, dk_s = stored.split("$")
    expected = unb64(dk_s)
    dk = hashlib.scrypt(password.encode(), salt=unb64(salt_s), n=N, r=R, p=P,
                        maxmem=MAXMEM, dklen=len(expected))
    return hmac.compare_digest(dk, expected)


stored = hash_password("Kx9!vR2q-mT7#wLp")
print(stored)
print(verify_password("Kx9!vR2q-mT7#wLp", stored))
print(verify_password("password123", stored))

Python 3.14.7（Windows）で実行すると、1行目に「$scrypt$ln=17,r=8,p=1$」で始まる保存用の文字列、続いて正しいパスワードでTrue、誤ったパスワードでFalseが出ました。保存と2回の照合を合わせた実行時間は約2秒で、1回の計算が1秒に満たない重さです。この重さが攻撃者の試行1回ごとにも課されます。ログインが集中するサイトでは、サーバーのメモリと応答時間を見ながら値を決めてください。

登録時の漏えい済みパスワード拒否：Pwned Passwords照合コードと実行結果

NIST SP 800-63B-4の3.1.1.2は、新しいパスワードを既知の漏えい済みパスワードの一覧と照合し、定期変更は求めない一方で、侵害の証拠があれば変更を強制するよう定めています。照合先にはHave I Been PwnedのPwned Passwordsが使えます。SHA-1の先頭5文字だけを送り、返ってきた候補の中から手元で一致を探す方式のため、パスワードそのものは外に出ません。APIキーは不要です。

# パスワードが過去の漏えいデータに含まれるかを、全文を送らずに確かめる（Python 3.9以上・標準ライブラリのみ）
import hashlib
import urllib.request


def pwned_count(password):
    sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    req = urllib.request.Request(
        "https://api.pwnedpasswords.com/range/" + prefix,
        headers={"User-Agent": "password-check-sample", "Add-Padding": "true"},
    )
    with urllib.request.urlopen(req, timeout=10) as res:
        for line in res.read().decode("utf-8").splitlines():
            s, count = line.split(":")
            if s == suffix:
                return int(count)  # パディング行は件数0なので「見つからない」と同じ扱い
    return 0


for pw in ["password123", "chocolate1", "Kx9!vR2q-mT7#wLp"]:
    print(pw, pwned_count(pw))

2026年10月28日に実行すると、password123は2,266,543回、chocolate1は567,912回、漏えいデータに現れていました。ランダムに作った16文字は0回です。登録や再設定の画面でこの照合を通し、件数が1以上なら別のパスワードを求めれば、解析で真っ先に割り出される候補を会員に選ばせずに済みます。Add-Paddingヘッダは応答の件数を揃えて通信量から推測されるのを防ぐもので、付け足される行は件数0なので読み捨てます。

強制リセットとアプリのログイン維持を両立させるための資格情報の分け方

リンツはパスワードを強制リセットしつつ、ログイン中のアプリでは店舗のポイント機能を残しました。これは、パスワードと、ログイン後に端末へ渡すトークンを別の資格情報として管理していれば取れる対応です。パスワードを無効にしても、発行済みのトークンは別に生かすか失効させるかを選べます。

選ぶ基準は、トークン自体が漏れたかどうかです。トークンをデータベースに平文で置いていると、パスワードと一緒に盗まれれば失効させるしかありません。トークンもハッシュ化して保存し、端末にだけ元の値を持たせる作りなら、データベースの漏えいだけでは使えません。トークンの失効とレート制限の実装はAPI不正アクセス対策の実装手順にまとめています。初期パスワードの扱いが問題になった別の事案はJoshinの不正アクセスで解説しています。

ECを外部のプラットフォームに預ける事業者が当事者になったときの報告と点検

委託先と連名で行う個人情報保護委員会への報告と速報・確報の期限

今回、会員情報を持っていたのは委託先のサーバーですが、会員から見た責任者は委託元のリンツです。個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある行為による個人データの漏えい等は、件数にかかわらず報告の対象です。速報は発覚から概ね3〜5日以内、確報は原則30日以内で、不正の目的によるものは60日以内とされています。

リンツとフューチャーショップは連名で報告しています。委託先の事故でも、委託元が自社の会員にいつ何を知らせるかを決める立場にある点は変わりません。報告の4類型と速報の書き方は個人情報保護委員会への報告義務と速報・確報の実務で解説しています。出店企業の側から見た旧EC基盤のデータの扱いはPFUダイレクト本店の情報漏洩が参考になります。

外部の脆弱性診断を入れるべき条件と自社で確かめれば足りる範囲

点検の順番は、パスワードの保存方式と設定値の確認、高速なハッシュが残る会員の洗い出し、登録時の漏えい済みパスワード照合の有無、ログイン用トークンの保存形式、会員情報を一括で読み出せる管理画面と担当者の確認です。ECの基盤を外部に預けている場合は、委託先がどの方式で保存しているかと、脆弱性の公表から対策までの期限を契約で確かめる項目に加えます。

外部の点検を入れるべきなのは、会員数が数十万件を超えるサイト、独自に作った会員機能やアプリのAPIを持つサイト、保存方式を自社で説明できないサイトです。会員数が数千人規模で、パスワードの保存を実績のあるEC基盤に任せ、自社で会員機能を作っていないなら、上の項目を委託先に問い合わせるところから始めて構いません。保存方式とAPI、管理画面の認証をまとめて確かめたい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

リンツの不正アクセスについて、会員と開発者から出やすい質問をまとめました。

退会した会員の情報も漏えいの対象ですか？

情報が取得された2026年10月18日0時16分の時点で退会済みだった会員は、対象に含まれないとされています。その時点で会員だった人は、その後に退会しても対象です。対象の会員には登録メールアドレス宛てに10月27日から順次連絡が届きます。連絡のリンクは開かず、会員専用ダイヤルか正規のサイトで確かめてください。

クレジットカードは止めたほうがよいですか？

発表では、漏えいした情報にクレジットカード情報などの支払い情報は含まれません。オンラインショップはカード情報を保存しない仕組みで、決済は決済代行会社が処理しています。カードの再発行には触れられていません。リンツを名乗ってカード番号を聞く連絡が来た場合は、それ自体が偽物の可能性が高いと考えてください。

パスワードはいつ、どうやって再設定しますか？

パスワードは10月26日にシステム側で強制リセットされ、オンラインショップの再開時に再設定が必要です。再設定の方法は後日、お知らせのページで案内するとされています。それまでに必要なのは、リンツと同じパスワードを使っている他のサービスの変更です。

貯めたポイントは使えますか？

ログイン状態のままの公式アプリでは、店舗でのポイント付与と利用を続けられると案内されています。アプリを削除すると、オンラインショップの再開まで再インストールも再ログインもできません。ポイント履歴や購入履歴の閲覧は、停止中は使えないマイページ機能に含まれます。

futureshopを使う他のネットショップの会員も影響を受けますか？

フューチャーショップは、対象店舗以外のデータに同様の手法で不正アクセスされた痕跡は確認されていないとしています。10月21日に検知した関連サービスへの不正アクセスも、ログ調査では個人情報の漏えいは確認されていない段階です。外部の専門機関による調査の結果は利用店舗に案内するとしているため、続報を確認してください。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：会員サイトのトークン失効と回数制限を実装するときに
• ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説：ハッシュ化の基本と保存方式の考え方
• ショップサーブ情報漏えいの最終報：Eストアー約2,335万人・7,858店の対象確認とお詫びメールの見分け方：EC基盤の側で起きた侵害の先例
• Joshin（ジョーシン）不正アクセス：最大600万件の対象とサブスク初期パスワードの対処：パスワードの扱いが焦点になった会員情報の事案
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：自社が当事者になったときの報告手順