ホワイトエッセンスは2026年10月5日、同社が運営する予約サイトと基幹システムへの不正アクセスにより、約105万アカウント分の個人情報が外部に持ち出されたと公表しました。8月5日に不正アクセスを確認し、8月12日にシステムを止めてから約2か月後の確定です。本記事では2本の公式発表をもとに経過と漏えい項目を整理し、利用者が今日やる点検をまとめます。後半では、予約サイトの脆弱性が基幹システムの情報まで届いた構図を踏まえ、DBの権限を表と列で絞るSQLと、パスワードの保管方式を移し替えるPythonコードを示します。
まとめ：ホワイトエッセンスの不正アクセスで確定した事実と利用者・開発者の対応
公式発表で確定しているのは、予約サイトのプログラムにあった脆弱性を起点に基幹システムまで不正アクセスされたこと、約105万アカウント分の情報が持ち出されたことです。項目は氏名・住所・電話番号・メールアドレス・生年月日・性別・勤務先、暗号化された状態のログインIDとパスワードなどに及びます。金融機関の口座情報は預かっておらず、画像の漏えいも確認されていないとされています。
利用者がまず手を付けるのは、同じIDとパスワードを他のサービスで使っている場合の変更です。開発者の側で点検したいのは、公開している予約サイトが破られたとき、そのDB接続で基幹側のどの表まで読めてしまうかという点になります。
| 項目 | 公表されている内容 |
|---|---|
| 不正アクセス確認 | 2026年8月5日 |
| システム停止・公表 | 2026年8月12日 |
| 漏えい判明の公表 | 2026年10月5日 |
| 対象数 | 約105万アカウント |
| 侵入の起点 | 予約サイトの脆弱性 |
| 対象外 | 口座情報（預かりなし） |
| 脆弱性の種類 | 未公表 |
公表内容の時系列｜8月5日の確認から10月5日の漏えい判明までの約2か月
予約サイトと基幹システムを止めた8月12日の第1報で示された内容
ホワイトエッセンスの第1報（2026年8月12日）によると、8月5日に予約サイトと基幹システムへの不正アクセスが確認されました。外部のセキュリティ専門機関による調査で、システムの一部に第三者による不正な操作とセキュリティ上のリスクが認められ、同社はシステムを一時停止しています。
この時点では、対象システムに氏名・連絡先・予約履歴などの登録情報が含まれると示しただけで、漏えいの有無と範囲は調査中でした。デジタルフォレンジックの業者による調査、弁護士と警察への相談、侵入経路の封鎖と脆弱性の修復を進めるとしています。ページは9月10日にも更新され、予約の受付状況が案内されました。調査の進め方と費用感はフォレンジック調査とはで整理しています。
10月5日の第2報で持ち出しが確定した約105万アカウントの内訳
10月5日の第2報は、調査を続けた結果、顧客の個人情報が外部に持ち出されていたことが判明したと説明しています。対象は2026年8月5日時点で登録されていた情報で、件数は約105万アカウントです。この数には顧客のほか、加盟院関係者と本部社員などが含まれると注記されています。
確認から判明まで約2か月かかりました。持ち出しの有無は、侵入の痕跡と通信の記録を突き合わせて確かめるため、ログが残っていない期間があると時間が延びます。どのログを先に見るかは不正アクセスのログ確認・解析方法でまとめています。
原因は予約サイトのプログラムの脆弱性｜基幹システムへ広がった構図
第2報は原因を、予約サイトのプログラムに存在した脆弱性を悪用され、これを起点に基幹システムに不正アクセスされたものと説明しています。脆弱性はすでに対処を完了し、不正な通信を検知・遮断する仕組みも導入したとしています。認証方式、システム構成、権限設定の見直しと監視体制の強化は順次進めている段階です。
脆弱性の種類は示されていません。そのため本記事では、SQLインジェクションなど特定の手口に結び付けた推測はしません。読み取れるのは、外部に公開した予約サイトの入口から、基幹システムが持つ会員と職員の情報まで届いてしまったという構図です。後半の設計の話は、この構図を前提にしています。
漏えいした項目の重さ｜暗号化されたパスワードと勤務先・生年月日の悪用
「暗号化された状態」のパスワードがハッシュ化と同じとは限らない理由
公表文はログインIDとパスワードを「暗号化された状態」と書いています。ここで言う暗号化が、鍵で元に戻せる暗号化なのか、一方向のハッシュ化なのかは示されていません。鍵で戻せる方式なら鍵の保管場所が、ハッシュ化なら方式とソルトの有無が、破られにくさを決めます。
どちらであっても、持ち出された値は攻撃者の手元で時間をかけて解析できます。短いパスワードや辞書に載る語は、方式が弱ければ割り出される前提で考えたほうが安全です。暗号化とハッシュ化の違いはハッシュ化とは（暗号化との違いとパスワード保管）で解説しています。
氏名・住所・電話・生年月日・勤務先がそろう一覧で起きる二次被害
今回の項目は、メールアドレスだけの漏えいと比べて本人に届く経路が多いのが特徴です。住所があれば郵便物、電話番号があれば電話やSMS、勤務先があれば職場宛ての連絡まで偽装できます。第2報も、同社や他の事業者を装った不審なメール・電話・郵便物が届く可能性に触れています。
生年月日は、本人確認の質問やパスワードの推測に使われやすい情報です。予約の利用状況に関する情報も含まれるため、来院や予約の話題を添えた連絡は本物らしく見えます。偽の連絡で入力画面へ誘う手口の全体像はフィッシング詐欺とはを参照してください。
| 漏えい項目 | 想定される悪用 | 利用者側の防ぎ方 |
|---|---|---|
| IDとパスワード | 他サービスへの不正ログイン | 使い回し先を変更 |
| 電話番号 | なりすましの電話・SMS | 折り返しは公式番号へ |
| 住所 | 偽の郵便物・請求書 | 記載の連絡先を使わない |
| 勤務先 | 職場宛ての偽連絡 | 社内で情報を共有 |
| 生年月日 | 本人確認の突破 | 秘密の質問を見直す |
ホワイトエッセンス利用者が今日やる点検｜使い回しの解消と不審な連絡の見分け方
同じIDとパスワードを使う他サービスを変更する順番と二要素認証
第2報は、他のサービスで同じログインIDとパスワードの組み合わせを使っている場合、そちらのパスワードを変更するよう求めています。ホワイトエッセンス側はマイページ機能を停止しており、利用者による手続きは不要との案内です。再開時には改めて案内があります。
変更の順番は、パスワード再設定の受け口になるメールアカウント、決済や送金に関わるサービス、通販や予約のサービスの順が目安です。二要素認証を有効にすれば、パスワードが知られても単独では入れません。過去の流出に自分の情報が含まれていないかは、個人情報流出チェックの方法で調べ方を紹介しています。
電話・郵便物を含む不審な連絡への利用者の対応と専用窓口の受付時間
同社は、電話やメールでクレジットカード番号、暗証番号、パスワードなどを尋ねることは一切ないとしています。心当たりのない連絡は、記載されたURLを開かず、情報も入力しないことが基本です。電話で求められた場合も、その場で答えずに切り、自分で調べた公式の番号に掛け直します。
本件の専用窓口は0120-385-035で、10月5日から18日までは土日祝を含む10時から19時、19日以降は平日のみの受付です。メールの窓口も第2報に記載されています。不審なメールの文面はフィッシング対策協議会のサイトで同じ事例を探せます。
予約サイトから基幹システムへ広げない設計｜DBロールを分けて表と列で許可する
公開Webと基幹の同居が被害を広げる構図と職員アカウントの混在
予約サイトは外部に公開する以上、脆弱性が見つかる前提で設計する部品です。予約サイトのDB接続が基幹システムと同じ権限で全表を読める構成だと、入口の1件の欠陥がそのまま全件の持ち出しにつながります。今回、対象数に加盟院関係者と本部社員が含まれていたことは、顧客と職員の情報が同じ到達範囲にあったことを示しています。
守り方の基本は、予約サイトが使うDBユーザーを専用に分け、予約に要る表と列だけを許可することです。入口が破られても、読める範囲がそのDBユーザーの権限で止まります。公開サイトのソフトウェアの脆弱性から会員情報の全件とポイント交換まで悪用された事例は、infoQの不正アクセスで扱っています。職員や加盟院のアカウント表は、予約サイトの接続からは見えない場所に置く設計です。予約システムの全体設計は予約システム開発の進め方で扱っています。
PostgreSQLのGRANTで予約サイト用ロールに必要な表と列だけを許す例
PostgreSQL 18のGRANTは、表単位に加えて列単位でSELECTやUPDATEを許可できます。次は、予約サイト専用のロールに予約表の読み書きと、会員表の表示用の列だけを許す例です。表名と列名は架空のものです。
-- 予約サイト専用のロール（PostgreSQL 18系）。パスワードは \password で別途設定する
CREATE ROLE reserve_web LOGIN;
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM reserve_web;
-- 予約の参照・登録・変更だけを許す
GRANT SELECT, INSERT, UPDATE ON reservations TO reserve_web;
-- 会員表は画面に出す列だけ。生年月日・勤務先・パスワードの列は読ませない
GRANT SELECT (member_id, display_name, email) ON members TO reserve_web;
-- 本部・加盟院の職員アカウント表（staff_accounts）には何も付与しない
-- 付与された権限を列単位で確かめる
SELECT table_name, column_name, privilege_type
FROM information_schema.column_privileges
WHERE grantee = 'reserve_web'
ORDER BY table_name, column_name;列単位で許可した表にSELECT *を投げると、許可していない列があるため権限エラーになります。アプリ側のクエリは必要な列を明示する書き方にそろえておく必要があります。公式ドキュメントにあるとおり、表単位の権限を与えたまま列の権限だけを取り消しても読めてしまうため、最初から表単位で与えないことが前提です。
権限を絞ってもSQLインジェクションのような欠陥自体は残ります。入口の対策はSQLインジェクションとは（コード付きの対策）で、権限の分離は破られた後の到達範囲を狭める対策として、両方を重ねて置きます。
パスワードの保管方式を移し替える｜旧方式からscryptへログイン時に置き換える
OWASPの推奨順位とArgon2id・scryptの係数を選ぶときの目安
OWASPのPassword Storage Cheat Sheetは、パスワードを暗号化や平文ではなく、計算コストを調整できるハッシュ関数で保管するよう求めています。推奨順はArgon2id、Argon2idが使えない場合のscrypt、レガシー環境に限るbcrypt、FIPS-140準拠が必要な場合のPBKDF2です。
Argon2idの最小構成の1つはメモリ19MiB・反復2回・並列度1です。scryptはN=2^17・r=8・p=1（128MiB）から、N=2^13・r=8・p=10（8MiB）まで、同等の強さとされる5つの組み合わせが示されています。メモリを多く使う構成ほど、専用機器での総当たりが割高になります。
Python標準ライブラリだけで旧ハッシュをscryptへ移すログイン処理
すでに保存されているパスワードは平文が手元にないため、一括では変換できません。利用者がログインに成功した瞬間だけ平文が手に入るので、そこで新しい方式に置き換えます。次はPythonのhashlib.scryptだけで書いた例で、旧方式はソルトなしSHA-256を想定しています。
# 旧方式のパスワード保管を、ログイン成功時に1件ずつscryptへ移し替える（Python標準ライブラリのみ）
import base64, hashlib, hmac, os
N, R, P = 2**14, 8, 5 # OWASPの推奨構成の1つ（16MiB・r=8・p=5）
def scrypt_hash(password):
salt = os.urandom(16)
dk = hashlib.scrypt(password.encode(), salt=salt, n=N, r=R, p=P)
b = lambda x: base64.b64encode(x).decode()
return f"scrypt${N}${R}${P}${b(salt)}${b(dk)}"
def scrypt_verify(stored, password):
_, n, r, p, salt, dk = stored.split("$")
calc = hashlib.scrypt(password.encode(), salt=base64.b64decode(salt),
n=int(n), r=int(r), p=int(p))
return hmac.compare_digest(calc, base64.b64decode(dk))
def legacy_verify(stored, password):
# 移行前の照合（例：ソルトなしSHA-256）。実際は既存システムの照合処理に置き換える
return hmac.compare_digest(hashlib.sha256(password.encode()).hexdigest(), stored)
def login(user, password):
stored = user["password_hash"]
if stored.startswith("scrypt$"):
ok = scrypt_verify(stored, password)
if ok and stored.split("$")[1:4] != [str(N), str(R), str(P)]:
user["password_hash"] = scrypt_hash(password) # 係数を上げた後の追従
return ok
if not legacy_verify(stored, password):
return False
user["password_hash"] = scrypt_hash(password) # 照合できた瞬間だけ平文が手元にある
return True
user = {"id": 1, "password_hash": hashlib.sha256(b"example-pass").hexdigest()}
print(login(user, "wrong-pass"), user["password_hash"][:12])
print(login(user, "example-pass"), user["password_hash"][:20])
print(login(user, "example-pass"), login(user, "wrong-pass"))Python 3.14.6（OpenSSL 3.5.7）で実行すると、1行目はFalseで旧ハッシュのまま、2行目はTrueで値がscrypt$16384$8$5$から始まる形に置き換わり、3行目はTrue Falseになります。hashlib.scryptのmaxmemは既定で32MiBに制限されるため、N=2^17の構成を使うときはmaxmemを引き上げてください。Argon2idを使える環境なら、argon2-cffiのcheck_needs_rehashで係数の追従を同じ形で書けます。
ログインしない休眠アカウントを旧方式のまま残さない移行の締め方
ログイン時の置き換えは、ログインしない利用者の分がいつまでも旧方式で残るのが弱点です。OWASPは、長く使われていないアカウントのハッシュを削除してパスワードの再設定を求める方法と、旧ハッシュを入力として新方式に通す方法の2つを示しています。
実務では、移行開始から期限を決め、期限までにログインしなかったアカウントは保管値を消して再設定を求める運用が明快です。持ち続ける情報が減るほど、次に侵入されたときに持ち出される件数も減ります。
採用の判断と次の備え｜権限分離を優先すべき条件と報告期限・第三者点検
DB権限の分離と保管方式の見直しを優先すべき事業者の構成と条件
予約サイトや会員サイトを外部に公開している、そのDB接続で基幹側の顧客や職員の表まで読める、パスワードの保管方式を説明できる担当者がいない、の三つのうち一つでも当てはまるなら、権限の分離と保管方式の見直しを先に進めるべきです。どちらも、入口が破られたときに持ち出される範囲を小さくする対策だからです。
反対に、予約をSaaSに任せていて自社のDBに顧客情報を持たない構成なら、この2つの優先度は下がります。その場合に先に確認する対象は、SaaS側の事故が自社に波及する経路です。予約SaaSの事故で利用店舗が担う報告と通知はファインズの不正アクセスで、予約システムへの侵入と系列サイトの是正はイエローハットの個人情報流出で扱っています。
漏えい報告の速報・確報の期限と調査が長引くときの公表の分け方
個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある行為による漏えい等や、本人の数が1,000人を超える漏えい等は報告の対象です。速報は発覚から3〜5日以内、確報は30日以内、不正目的の場合は60日以内とされています。漏えいの「おそれ」の段階でも対象になります。
今回の第2報は、個人情報保護委員会へ報告したうえで対応を進めていると記していますが、報告日は書かれていません。調査が長引くときは、確定していない段階でも、止めた範囲と調査中の項目を分けて早めに出し、判明した時点で更新する形が利用者の備えにつながります。類型の見分け方は個人情報保護委員会への報告義務で解説しています。
自社の予約サイトと基幹システムを点検する順番と依頼先の選び方
点検は三つの順で進めます。最初に、外部公開している予約サイトや会員サイトのDB接続ユーザーを洗い出し、それぞれが読める表と列をinformation_schemaで一覧にします。次に、顧客と職員のアカウントが同じ表や同じ接続から読める箇所を切り分けてください。最後に、パスワードの保管方式と、旧方式のまま残っている件数を数えます。
公開Webの入口と、破られた後にどこまで読めるかを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断で、予約サイトの脆弱性とDB権限の到達範囲を含めて点検できます。
よくある質問
ホワイトエッセンスの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。
ホワイトエッセンスの不正アクセスでどの情報が漏えいしましたか？
第2報によると、2026年8月5日時点で登録されていた情報のうち、氏名・住所・電話番号・メールアドレス・生年月日・性別・勤務先、暗号化された状態のログインIDとパスワード、サービスの利用・対応に関する情報、管理番号などの全部または一部です。登録内容は人により異なるため、全員にすべての項目が当てはまるわけではありません。口座情報は預かっておらず、画像の漏えいも確認されていないとされています。
約105万アカウントには誰の情報が含まれますか？
第2報は、約105万アカウントには顧客のほか、加盟院関係者と本部社員などが含まれる全体数だと注記しています。顧客の人数だけを示した数字ではありません。連絡先を確認できた人には順次個別に連絡するとしているため、自分が対象かを確かめたい場合は専用窓口に問い合わせてください。
ホワイトエッセンスのパスワードは変更したほうがよいですか？
同社のマイページ機能は停止中で、同社サービス側での手続きは不要とされています。変更が必要なのは、同じログインIDとパスワードの組み合わせを使っている他のサービスです。使い回しがある場合は他サービス側を先に変更し、二要素認証を有効にしてください。
不審な電話や郵便物が届いたらどうすればよいですか？
同社は電話やメールでクレジットカード番号、暗証番号、パスワードを尋ねることはないとしています。心当たりのない連絡には答えず、記載のURLや電話番号も使わないでください。確かめたいときは、自分で調べた公式の窓口に連絡します。氏名や住所が正しく書かれていても、本物だと判断する根拠にはなりません。
自社の予約サイトは何から見直せばよいですか？
最初に、予約サイトが使うDB接続ユーザーが、予約に要らない表や列まで読めないかを確かめてください。顧客と職員のアカウントが同じ接続から見えるなら分けます。あわせて、パスワードの保管方式を確認し、旧方式が残っていればログイン時の置き換えと期限付きの再設定で移行します。
関連記事
- ファインズの不正アクセスと153万件の予約者情報｜予約システムを使う店舗の報告と通知の手順：予約システムの事故が利用店舗へ波及した事例
- イエローハットの個人情報流出 最大180万件：予約システムへの不正プログラムとグループ横断の是正：予約システムを狙われた事例
- オズモールの不正アクセスと最大44万件のメールアドレス｜海外からの大量アクセスを止める設計：会員ページへの大量アクセスを抑える設定
- タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計：保管データを減らして被害の上限を下げる設計
- ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説：パスワード保管方式の基礎
