家電量販店のJoshin（ジョーシン、2026年4月に上新電機から社名変更）は2026年10月26日、不正アクセスにより会員情報が最大約600万件漏えいした可能性があると第2報で公表しました。対象は会員情報データベース、「ジョーシンのサブスク」、リフォーム写真アップロードシステムの3つです。サブスクではログインIDと初期パスワード、リフォームでは免許証やマイナンバーカードの画像まで項目に入っています。本記事の前半は、公式の第1報・第2報から対象と経緯を整理し、利用者がいま行う対処をまとめました。後半は開発者と会員サービスの担当者に向けて、初期パスワードを復元できる形で残さない実装と、写真投稿先に残った本人確認書類の棚卸しをコード付きで示します。
まとめ：Joshin不正アクセスで公表された3システムの範囲と利用者がいま行うこと
漏えいの可能性があるのは、3つのシステムに入っていた情報です。件数は可能性のある総数で、漏えいが確定した数ではありません。クレジットカード情報は、決済情報の非保持化によりもともと保持していないとされています。
| システム | 最大件数 | 主な項目 |
|---|---|---|
| 会員情報データベース | 約600万件 | 氏名・住所・電話番号・会員番号 |
| ジョーシンのサブスク | 約23万件 | ログインID・初期パスワード・手書きサイン等 |
| リフォーム写真アップロード | 約800件 | 免許証画像・マイナンバーカード画像・口座番号等 |
利用者が先に行うのは2つです。サブスクを使っている人は、初期パスワードのまま使っていないかを確かめ、同じパスワードを使い回しているサービスも変えます。全員に共通するのは、Joshinを名乗るメール・SMS・電話のリンクや番号を使わないことです。問い合わせは第2報に載っているお客様相談窓口（06-6631-1323・9時30分〜18時30分）へ自分からかけます。
公式第1報・第2報で確かめるJoshin不正アクセスの経緯と3システムの件数
10月16日の異常検知からサーバー遮断、10月26日の第2報までの経緯
公表は3回あります。日付と中身を並べると、何が分かっていて何が分かっていないかが見えます。
| 日付 | 出来事 |
|---|---|
| 2026年10月16日（金） | ネットワークの異常を検知し、該当サーバーを遮断 |
| 2026年10月17日（土） | 公式サイトで初報。一部サービスの提供不可を公表 |
| 2026年10月19日（月） | 同じ内容を東京証券取引所へ開示 |
| 2026年10月26日（月） | 第2報。3システムの最大件数と項目を公表 |
10月17日の初報と10月19日の適時開示の段階では、情報流出の有無は確認中で、個人情報保護委員会へ第一報を入れたとだけ書かれていました。第2報で初めて、異常を検知して調べたところネットワークの一部に不正アクセスの形跡があったこと、警察にも相談・報告したことが示されています。侵入の手口と原因は、10月27日時点で公表されていません。
会員DB最大約600万件・サブスク約23万件・リフォーム約800件の項目の違い
3つのシステムは、漏れた可能性のある情報の性質がまったく違います。
会員情報データベースは件数が最も多い一方、項目は氏名・住所・電話番号・会員番号の4つです。ジョーシンのサブスクは約23万件で、会員番号と電話番号に加えて手書きサインのデータ、ログインIDと初期パスワード、請求履歴、契約番号とデバイスID、有効化コードが並びます。ログインに使える情報が含まれる点で、会員DBより直接の悪用につながりやすい系統です。
リフォーム写真アップロードシステムは約800件と少ないものの、免許証画像2件、マイナンバーカード画像1件、口座番号5件が入っていました。このほか、リフォーム施工中の工事写真のデータも対象です。この8件の該当者には、Joshinが個別に連絡しているとされています。
クレジットカード情報が対象外の理由と「件数は確定値でない」の読み方
第2報は、決済情報の非保持化に対応しているため、クレジットカード情報は持っていないと2回書いています。持っていない情報は漏れようがありません。ただし、偽のメールやサイトでカード番号を入力すれば別の被害になる点は変わりません。
件数について、第2報は「漏洩した可能性のある総件数であり、個人情報漏えいが確定した件数ではありません」と注記しています。3システムの件数を足した約623万件という数字も報道に出ていますが、同じ人が会員とサブスクの両方に入っている場合の重複は公表されていません。実際の人数はこれより少ない可能性があります。
ジョーシンを装う連絡と初期パスワードについて利用者が確かめる手順
サブスク利用者が初期パスワードと使い回したパスワードを変える順番
ジョーシンのサブスクを使っている人は、まず初期パスワードのまま使っていないかを確かめます。10月27日に公式サイトのトップを見ると、ジョーシンのサブスクには「メンテナンス中」と表示されていました。サブスク側でいますぐ変更できない場合も、先に手を付けられる箇所があります。
- サブスクと同じパスワードを使っている他のサービスを書き出す
- メールやネットバンキングなど、乗っ取られると被害が大きいものから変える
- サブスクが再開したら、初期パスワードと違う新しい値に変える
漏れたIDとパスワードの組は、他のサービスへのパスワードリスト攻撃に使われます。サブスクのアカウントそのものより、同じ組で入れる別のサービスのほうが先に狙われることがあるため、順番は使い回し先が先です。
免許証・マイナンバーカード画像の対象者が個別連絡の後に警戒する連絡
リフォーム写真アップロードシステムの8件は、個別連絡の対象です。個別連絡が来た人は、本人確認書類の画像を使った身に覚えのない契約や申込みに注意します。携帯電話の契約、クレジットカードの申込み、ローンの審査通知などが届いたら、その事業者の公式窓口へ自分から確かめます。
口座番号が対象の人は、金融機関を名乗る連絡にも警戒します。口座番号だけでは引き出せませんが、本人確認書類と組み合わせて「口座の確認」を装う電話やメールの材料になります。マイナンバーカードの画像が表面か裏面かは、公表されていません。
ジョーシンを名乗るメール・SMS・電話を受けたときの確認先と相談窓口
第2報は、Joshinを装った不審なメール・SMS・電話が行われる可能性があると呼びかけています。会員番号や住所、電話番号が知られている前提で連絡が来るため、自分の情報が正しく書かれていることは本物の証拠になりません。
確かめるときは、届いた連絡に書かれたURLや電話番号を使いません。第2報に載っている窓口は、Joshinお客様相談窓口の電話（06-6631-1323・9時30分〜18時30分）とメールの2つです。送信元を詐称するメールの見分け方はフィッシングの手口と見分け方で整理しています。
サブスクの初期パスワードが漏えい項目に入った構造と開発側の直し方
初期パスワードを復元できる形で保存する設計が漏えい時に招く被害の範囲
第2報は、サブスクの漏えい項目に「ログインID 初期パスワード」を挙げました。保存の形式が平文か、暗号化か、ハッシュ値かは公表されていません。ただ、初期パスワードを項目として数えたということは、少なくとも初期パスワードに関わる値がシステム内に残っていたことを示しています。
初期パスワードを契約時に発行し、紙やメールで渡したあとも元の値をDBに持ち続ける設計は、申込み・問い合わせ対応では便利です。利用者が忘れたときに店舗で読み上げられるからです。その反面、利用者が変更しなかったアカウントは、DBが読まれた時点でそのままログインされる状態になります。
OWASPのPassword Storage Cheat Sheetは、パスワードは暗号化でも平文でもなく、一方向のハッシュで保存するよう求めています。暗号化は鍵があれば元に戻せるため、DBと鍵が同時に読まれれば平文と同じです。NIST SP 800-63Bも、パスワードはソルト付きでハッシュ化し、ソルトは32ビット以上とすること、漏えいの証拠があれば変更させることを定めています。初期パスワードも、この扱いの例外にしません。
初期パスワードをscryptでハッシュ化し期限と変更必須を付けるPython実装
初期パスワードは、本人に1回渡したら元の値を捨てます。DBに残すのはハッシュ値と、変更が済んだかどうかの印、有効期限の3つです。次のコードは標準ライブラリだけで、その流れを書いたものです。
import hashlib
import hmac
import secrets
import sqlite3
from datetime import datetime, timedelta, timezone
# OWASP Password Storage Cheat Sheet の scrypt 最小構成（N=2^17, r=8, p=1）
N, R, P = 2**17, 8, 1
MAXMEM = 256 * 1024 * 1024
TTL = timedelta(days=7) # 初期パスワードの有効期限
def hash_pw(pw, salt=None):
salt = salt or secrets.token_bytes(16)
dk = hashlib.scrypt(pw.encode(), salt=salt, n=N, r=R, p=P, maxmem=MAXMEM)
return salt, dk
def setup(db):
db.execute("""CREATE TABLE IF NOT EXISTS account (
login_id TEXT PRIMARY KEY, salt BLOB, pw_hash BLOB,
must_change INTEGER, initial_expires TEXT)""")
def issue_initial(db, login_id):
pw = secrets.token_urlsafe(12) # 本人に1回だけ渡す。DBには残さない
salt, dk = hash_pw(pw)
exp = (datetime.now(timezone.utc) + TTL).isoformat()
db.execute("INSERT OR REPLACE INTO account VALUES (?,?,?,1,?)",
(login_id, salt, dk, exp))
return pw
def login(db, login_id, pw):
row = db.execute("SELECT salt, pw_hash, must_change, initial_expires "
"FROM account WHERE login_id=?", (login_id,)).fetchone()
if not row:
return "NG"
salt, dk, must_change, exp = row
if not hmac.compare_digest(hash_pw(pw, salt)[1], dk):
return "NG"
if must_change:
if datetime.fromisoformat(exp) < datetime.now(timezone.utc):
return "EXPIRED" # 期限切れの初期パスワードではログインさせない
return "CHANGE_REQUIRED" # 変更画面以外へは進ませない
return "OK"
def change(db, login_id, new_pw):
salt, dk = hash_pw(new_pw)
db.execute("UPDATE account SET salt=?, pw_hash=?, must_change=0, "
"initial_expires=NULL WHERE login_id=?", (salt, dk, login_id))
if __name__ == "__main__":
db = sqlite3.connect(":memory:")
setup(db)
first = issue_initial(db, "sub-000123")
print("初期PWでログイン:", login(db, "sub-000123", first))
change(db, "sub-000123", secrets.token_urlsafe(16) + "Zz")
print("変更後に初期PWでログイン:", login(db, "sub-000123", first))
stored = db.execute("SELECT pw_hash FROM account").fetchone()[0]
print("DBに残る値:", stored.hex()[:16] + "...", "(平文は残らない)")python initial_pw.pyで実行すると、初期パスワードでのログインはCHANGE_REQUIREDになり、変更後に同じ初期パスワードを入れるとNGが返ります。本記事ではPython 3.14.7でこの2つの結果と、DBにハッシュ値だけが残ることを確かめました。期限切れの分岐は実行していません。
scryptのパラメータN=2^17, r=8, p=1はOWASPが示す最小構成で、1回の計算に約128MiBのメモリを使います。Pythonのhashlibのscryptは、メモリ上限maxmemの既定がOpenSSL 1.1.0の32MiBと説明されており、この構成でのエラーを避けるには、上限の拡張が必要です。ソルトは16バイト以上を勧めているため、コードではsecrets.token_bytes(16)で作っています。ログインの多いサービスでは、同時に計算する数とサーバーのメモリを見て、OWASPの表にあるN=2^16, p=2などの組み合わせに下げます。窓口で初期パスワードを読み上げる運用は、この設計では実施できません。代わりに再発行の手順を用意し、本人確認のうえで新しい初期パスワードを出し直します。
手書きサインや契約番号を会員番号と同じ場所に置かない保管の分け方
サブスクの項目には、電話番号と組になった手書きサインのデータ、契約番号、デバイスID、有効化コードが並んでいます。契約の証跡、機器の管理、ログインの情報が、1つのシステムの中で同じ会員番号に結び付いていたと読めます。
役割の違う情報は、保存先と読める権限を分けます。手書きサインのような契約の証跡は、締結後に参照する場面が限られるため、日常の会員管理とは別の保管先に移し、読み出しを記録します。認証情報は認証の仕組みの中だけに置き、契約管理の画面からは見えないようにする設計です。分けておけば、1つのサーバーが読まれても全項目がそろって漏れることを防げます。APIや管理画面の入口の固め方はAPI不正アクセス対策の実装手順にまとめました。
リフォーム写真アップロードに本人確認書類が残る問題と保管期限の棚卸し
工事写真の投稿先に免許証画像と口座番号が入り込む運用上の経路
リフォーム写真アップロードシステムは、名前のとおり施工中の工事写真を集める仕組みです。そこに免許証画像2件、マイナンバーカード画像1件、口座番号5件が入っていました。どういう経緯で入ったのかは公表されていません。
写真を投稿できる場所があると、本来は別の手続きで受け取るはずの書類も同じ場所に送られやすくなります。本人確認や返金口座のやり取りを、写真と一緒に済ませてしまう運用が典型です。投稿先は工事写真を前提に作られているため、本人確認書類を扱う保管期限や閲覧権限が設定されていないことがあります。本人確認書類が閲覧できる状態になっていた別の事例はハノワの情報漏洩と本人確認書類の範囲で、パスワードと本人確認書類の両方が対象になった事例はLili不正アクセスの平文パスワードと縮小画像で扱いました。
保管期限を過ぎた画像と書類を一覧にするPythonの棚卸しスクリプト
まず手を付けるのは、投稿先に何がどれだけ残っているかの一覧です。次のスクリプトは、指定したフォルダの下から、更新日が保管期限を過ぎた画像とPDFを探して並べます。
import sys
import time
from pathlib import Path
# 施工完了から何日たった写真・書類を棚卸しの対象にするか
KEEP_DAYS = 90
EXTS = {".jpg", ".jpeg", ".png", ".heic", ".pdf"}
def stale_files(root, keep_days=KEEP_DAYS):
limit = time.time() - keep_days * 86400
for p in Path(root).rglob("*"):
if p.is_file() and p.suffix.lower() in EXTS and p.stat().st_mtime < limit:
yield p
if __name__ == "__main__":
root = sys.argv[1]
files = sorted(stale_files(root))
for p in files:
day = time.strftime("%Y-%m-%d", time.localtime(p.stat().st_mtime))
print(day, p.stat().st_size, p)
print(len(files), "件が保管期限を過ぎています")python stale_uploads.py uploadsのように投稿先のフォルダを渡すと、日付・サイズ・パスの一覧と件数が出ます。本記事では、一時フォルダに180日前の画像、新しい画像、古いテキストファイルを1つずつ置いて実行し、古い画像1件だけが返ることを確かめました。90日は説明用の値です。工事の保証期間や契約で決めた保存期間に合わせて置き換えてください。
一覧が出たら、いきなり消さずに中身を確かめます。工事写真の中に本人確認書類や通帳の写しが混ざっていないかを見て、混ざっていたものは本来の手続きの保管先へ移すか、不要なら削除します。オブジェクトストレージに置いている場合は、更新日ではなくライフサイクルの設定で期限を付けるほうが漏れがありません。
対策を見送ってよい事業者の条件と、先に外部点検を受けるべき箇所
初期パスワードの作り直しが要るのは、自社で会員のログインを管理し、店舗や電話で初期パスワードを発行している事業者です。ログインを外部の認証サービスに任せ、パスワードを自社のDBに一切持たない事業者には、上のコードは過剰です。その場合は、認証サービス側で漏えい済みパスワードの拒否と多要素認証が有効になっているかを先に確かめます。
写真や書類を受け付ける窓口を持たない事業者は、棚卸しスクリプトも要りません。逆に、工事・修理・設置のように顧客から写真を集める業務がある事業者は、規模が小さくても先に棚卸しを行います。件数が少なくても、本人確認書類が1件でも漏れれば個人情報保護委員会への報告の対象になりうるからです。自社の会員基盤や投稿先がどこまで読める状態にあるかを外部の目で点検するなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
Joshin（ジョーシン）の不正アクセスについて、会員とサブスク利用者から出やすい質問をまとめました。
上新電機とJoshinは同じ会社ですか？
同じ会社です。上新電機は2026年4月1日に社名を株式会社Joshinに変えました。公式サイトのトップには、旧社名が書かれたジョーシンカードやギフトカード、長期保証の保証書も有効期限内はそのまま使えると案内されています。今回の不正アクセスを公表したのは、社名変更後の株式会社Joshin（東証プライム・証券コード8173）です。
Joshinの不正アクセスで自分が対象かはどう確かめればよいですか？
10月27日時点で、会員情報データベースとサブスクの利用者に個別連絡をするという記載は第2報にありません。個別連絡があると明記されているのは、免許証画像やマイナンバーカード画像、口座番号が入っていたリフォーム写真システムの8件だけです。会員やサブスク利用者は、自分の情報が対象に入っている前提で不審な連絡に注意し、気になる点はお客様相談窓口（06-6631-1323）へ確かめます。
クレジットカード番号は漏れましたか？
漏れていないとされています。第2報によると、Joshinは決済情報の非保持化に対応しており、クレジットカード情報をそもそも保持していません。ただし、Joshinを装うメールやSMSのリンク先でカード番号を入力すると別の被害になります。入力してしまった場合は、すぐにカード会社へ連絡して利用停止を頼んでください。
止まっているサービスはどれですか？
第2報は「一部のサービスをご提供できない状態」と書くだけで、サービス名を挙げていません。10月27日に公式サイトのトップを確認した時点では、ジョーシンのサブスクに「メンテナンス中」と表示されていました。他のサービスの状況は公式に個別の記載が無いため、修理や配送の予定がある人はお客様相談窓口へ確かめるのが確実です。
Joshinの不正アクセスの原因はランサムウェアですか？
10月27日時点で、原因や侵入の手口、ランサムウェアかどうかは公表されていません。第2報で分かっているのは、10月16日に異常を検知して不正アクセスの形跡を確認し、該当サーバーを遮断したこと、個人情報保護委員会と警察に相談・報告したことです。サーバーを切り離す初動の考え方はランサムウェアの初動対応、報告の考え方は個人情報保護委員会の案内で確かめられます。
関連記事
- パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装：漏れたIDとパスワードが他のサービスで使われる仕組み
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：会員基盤への侵入口を塞ぐ対策
- Lili不正アクセス：パスワード平文流出の可能性と本人確認書類の縮小画像、偽Cloudflare画面への対応：パスワードと本人確認書類の両方が対象になった事例
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい発生時の報告の期限と中身
- 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：漏えいの防ぎ方と発生時の対応
