Integral Security Reportインテグラル セキュリティ レポート
← 一覧に戻る
2025-shirohato小売・EC最終確認 2026-10-13 20:03

白鳩ECサイト「SHIROHATO」の会員登録機能不具合による個人情報の閲覧可能状態(最大176名)

公表日

株式会社白鳩
最終報設定不備その他

白鳩のECサイト「SHIROHATO」で、2025年8月20日から11月4日までの間、楽天IDを使った新規会員登録の途中で、別の人の個人情報が画面に表示されることがありました。対象は最大176名で、クレジットカード情報とパスワードは含まれていないと発表されています。

対象者は?

2025年8月20日から11月4日までに、SHIROHATOで楽天ID連携を使って新規会員登録をした(途中でやめた人を含む)最大176名です。見られた可能性がある情報は、氏名(かな)、生年月日、性別、メールアドレス、住所、電話番号です。クレジットカード情報とパスワードは含まれていないと発表されています。

特定できた169名には、白鳩から個別にお詫びのメールが送られています。会員登録を最後まで終えなかった7名は連絡先を特定できず、公式サイトでの発表をもって報告とされています。心当たりがある場合は、白鳩の公式のお知らせを確認してください。

いますぐできること

  • 2025年8月20日〜11月4日にSHIROHATOで楽天IDを使って会員登録をしたかどうか思い出し、白鳩からのお詫びメールが届いていないか確認する
  • 住所・電話番号・メールアドレスあてに心当たりのない連絡が来たら、すぐに応じず注意する

何が起きたのか

2025年8月20日から11月4日までの間、SHIROHATOで楽天IDを使って新規会員登録をしていると、直前に同じ機能を使った別の人の個人情報が入力画面に表示されることがありました。11月2日の夜11時31分に客からの問い合わせがあり、問題が分かりました。白鳩は11月7日に第1報を出し、12月1日に調査結果と再発防止策を発表しました。

なぜ起きたのか・なぜ広がったのか

白鳩の説明では、利用者を見分けるプログラムに不備があり、何人もが同時にアクセスすると別の人の情報を呼び出してしまう作りになっていました。また、公開前のテストで、アクセスが集中したときや同時に使われたときの確認が足りず、事前に問題に気付けなかったとしています。

いまの状況2025-12-01 時点

楽天ID連携の機能は、作り直しと安全性の確認が終わるまで当面止められています。再発防止策として、開発の委託先にセキュリティ基準を守ることを徹底させ、アクセス集中時などのテストを必須にしました。さらに、情報システム部門の責任者が承認しないと公開できない運用に変えました。個人情報保護委員会とJIPDECへの最終報告は提出済みです。補償については、まだ発表されていません。

企業として考えたいこと

自社のサイトで、たくさんの人が同時に会員登録やログインをしたときに別の人の情報が表示されないことを、公開前に確かめていますか?

技術的な要約

白鳩が運営するECサイト「SHIROHATO」の新規会員登録機能(楽天ID連携)に不具合があり、登録手続き中の顧客の個人情報が、直後に同機能を利用した他の顧客の入力画面に誤表示され、閲覧可能な状態となっていた。事象の発生期間は2025年8月20日から11月4日で、11月2日午後11時31分に顧客からの問い合わせで発覚し、11月7日に第1報を公表した。対象は最大176名で、氏名(かな)、生年月日、性別、メールアドレス、住所、電話番号が漏えいした可能性があるが、クレジットカード情報とパスワードの漏えいはないとしている。12月1日の調査結果報告では、原因をセッション管理プログラムの不備と、高負荷時・同時アクセス時の検証シナリオ不足とし、再発防止策を示した。個人情報保護委員会とJIPDECへの確報提出は完了し、楽天ID連携機能は安全性確認まで当面停止している。

侵入
—
被害発生
2025-08-20
検知
2025-11-02 23:31
第1報公表
2025-11-07
最新続報
2025-12-01
侵入 → 検知
—
侵入日が非公表
検知 → 公表
5日
データ(上限)
176人
確定 —
波及先
—

攻撃の分類

侵入口
不明公表で確認
外部からの侵入ではなく、自社ECサイトの会員登録機能(楽天ID連携)のセッション管理の不備により、複数ユーザーの同時アクセス時に他者の情報が呼び出されたもの。攻撃者による侵入の有無は公表されていない。
脆弱性
CVE 非公表公表で確認
SHIROHATO 新規会員登録機能(楽天ID連携)
セッション管理(ユーザー識別処理)に関するプログラムに不備があり、複数ユーザーによる同時アクセス時に他者の情報が呼び出される設計となっていた。CVEは公表されていない。
攻撃者
特定・主張なし
ATT&CK
—

影響

業務停止
あり 「楽天ID連携」機能を停止。根本的な改修と十分な安全性テストが完了し安全性が確認されるまで当面停止する。
期間:停止期間の終了時期は公表されていない(当面の間)
データ
おそれ上限 176確定 —人
氏名生年月日性別メール住所電話
対象は最大176名。ログ調査で特定できた169名にメール通知、会員登録が完了せず連絡先特定が困難だった7名は公表をもって報告(169+7=176)。クレジットカード情報とパスワードの漏えいはないと公表。
波及先
—
金銭影響
—
サプライチェーン
システム開発委託先に対し、セキュアコーディング規約の遵守徹底とリスクレビュー体制の強化を求めた。委託先の環境侵害による事案ではない。

時系列

  1. 2025-08-20
    事象の発生期間の開始(登録手続き中の顧客の個人情報が他の顧客の入力画面に誤表示され得る状態)。2
  2. 2025-11-02 23:31
    顧客からの問い合わせがあり、事案が発覚。1
  3. 2025-11-04
    事象の発生期間の終了。2
  4. 2025-11-07
    「SHIROHATO公式サイトにおける個人情報閲覧可能状態に関するお詫びとご報告」で第1報を公表。21
  5. 2025-12-01
    調査結果と再発防止策を報告。原因はセッション管理プログラムの不備と、同時アクセス等を想定した検証シナリオの不足。21
  6. 2025-12-01
    ログ調査で特定できた169名に個別のお詫びと報告のメールを送付済み。連絡先特定困難な7名は本公表をもって報告とした。書面での連絡は電子メール通知をもって代えた。2
  7. 2025-12-01
    再発防止策として、開発委託先へのセキュアコーディング規約遵守の徹底とリスクレビュー体制の強化、異常系テスト項目の必須化、情報システム部門責任者の承認をリリース条件とする運用変更を実施。2
  8. 2025-12-01
    個人情報保護委員会およびJIPDECへの確報(最終報告)の提出が完了していると公表。楽天ID連携機能は当面停止。2
  9. 2025-12-17
    ScanNetSecurityが調査結果を報道。1

技術解説

事象の概要と経緯 事実

白鳩が運営するECサイト「SHIROHATO」の新規会員登録機能(楽天ID連携)で、システム上の不具合が起きていた。特定の条件下(同時刻帯のアクセス等)では、登録手続き中の顧客の個人情報が、直後に同じ機能を使った別の顧客の入力画面に誤って表示され、見られる状態になっていた。発生期間は2025年8月20日(水)から11月4日(火)まで。11月2日午後11時31分に顧客から問い合わせがあり、発覚した。同社は11月7日付の第1報「SHIROHATO公式サイトにおける個人情報閲覧可能状態に関するお詫びとご報告」で公表し、12月1日に調査結果と再発防止策を報告した。漏えいした可能性がある情報は、氏名(かな)、生年月日、性別、メールアドレス、住所、電話番号。クレジットカード情報とパスワードの漏えいはないとしている。対象は最大176名。このうちログ調査で特定できた169名には個別にお詫びと報告のメールを送った。会員登録が完了せず、連絡先の特定が難しかった7名には、公表をもって報告とした。当初予定していた書面での連絡は、メールでの通知完了をもって代えた。

公表された原因と再発防止策 事実

同社は原因を技術的要因と管理的要因に分けて説明している。技術的要因は、セッション管理(ユーザー識別処理)に関するプログラムの不備である。複数のユーザーが同時にアクセスすると、他者の情報が呼び出される設計になっていた。管理的要因は、リリース前の受け入れテストに、高負荷時や複数ユーザーによる同時アクセス等を想定した検証シナリオが足りなかったことである。そのため、事前に不具合を検知できない管理体制だったとしている。再発防止策は3点ある。1点目に、システム開発委託先に対し、個人情報を扱う機能の実装でセキュリティ基準(セキュアコーディング規約)を守ることを徹底させ、設計・開発工程のリスクレビュー体制を強化した。2点目に、受け入れテストでアクセス集中時等の異常系を含むテスト項目を必須にした。3点目に、情報システム部門責任者の承認をリリースの条件とする運用に変えた。停止中の「楽天ID連携」機能は、根本的な改修と十分な安全性テストが終わり、安全性が確認されるまで当面止める。個人情報保護委員会とPマーク付与機関(JIPDEC)への確報(最終報告)の提出は完了している。

不具合の構造についての解釈 解釈

公表された内容は「同時アクセス時に他者の情報が呼び出される」というもので、外部からの侵入ではなく、アプリケーション内部で利用者を取り違える種類の不具合と読み取れる。一般にこうした事象は、次のような実装で起きやすい。リクエストごとに分けるべき一時データを、複数の利用者が共有する場所に置いてしまう場合である。具体的には、アプリケーション全体で共有される変数やキャッシュ、外部ID連携の戻り処理で使う一時領域などが挙げられる。楽天ID連携のように外部の認証画面とサイトを行き来する処理では、戻ってきた利用者と登録途中のデータを正しく結び付ける必要があり、この結び付けが崩れると取り違えが起きる。ただし、白鳩は具体的な実装(どの変数・キャッシュ・処理が原因か)を公表しておらず、上記は一般的な傾向からの推定にとどまる。また、同時アクセスという条件付きの不具合は、通常の単独操作による機能テストでは再現しにくい。同社が管理的要因として検証シナリオの不足を挙げているのは、この性質と合っている。

検知と公表対応についての解釈 解釈

発生期間は2025年8月20日から11月4日までの約2か月半で、きっかけは顧客からの問い合わせだった。公表情報の範囲では、システム側の監視で気付いた形跡は示されていない。表示された他人の情報に気付き、連絡してくれる利用者がいなければ、もっと長く続いた可能性もある。一方で、対応には評価できる点がある。ログ調査で169名を特定して個別に通知し、特定できなかった7名についても人数を明示して「最大176名」として公表した。また、楽天ID連携機能を、安全性が確認されるまで止める判断をしている。数値は「最大176名」が対象の上限で、実際に他人に閲覧されたことが確定した人数は公表されていない点に注意が必要である。さらに、発覚(11月2日)から発生期間の終了(11月4日)までの約2日間の経緯、つまり機能をいつ止めたかは公表情報から読み取れない。ログで登録途中の利用者の連絡先を特定できなかった点は、影響範囲を確かめるために必要なログの設計という課題を示しているとも考えられる。

対応

封じ込め
「楽天ID連携」機能を停止し、根本的な改修と十分な安全性テストが完了して安全性が確認されるまで当面停止する。再発防止策として、開発委託先へのセキュアコーディング規約遵守の徹底とリスクレビュー体制の強化を求め、受け入れテストで異常系を含む項目を必須化し、情報システム部門責任者の承認をリリース条件とした。
公表の仕方
2025年11月7日に第1報を公表し、12月1日に調査結果と再発防止策を報告。対象者のうち169名に個別に電子メールで通知し、連絡先特定が困難な7名には公表をもって報告とした。当初予定の書面連絡は電子メール通知で代えた。
当局対応
  • 個人情報保護委員会(確報提出済み)
  • 一般財団法人日本情報経済社会推進協会(JIPDEC/Pマーク付与機関)(確報提出済み)

教訓と対策

教訓具体的な対策
同時アクセス時だけに起きる利用者の取り違えは、通常の機能テストでは見つかりにくい。受け入れテストに並行実行テストを加える。複数のテストユーザーで同時に会員登録や外部ID連携を実行し、各レスポンスに含まれる個人情報の持ち主とセッションのユーザーが一致するかを自動で検証する。負荷試験ツールで同時接続数を段階的に上げて実施する。
外部ID連携の戻り処理では、利用者と登録途中データの結び付けが崩れやすい。OAuth/OIDCのstateやnonceをサーバ側のセッションに結び付けて検証する。登録途中の一時データはセッションIDやリクエスト単位のキーで保存する。シングルトンやstatic変数、共有キャッシュに利用者データを置かないことをコーディング規約と静的解析ルールで禁止する。
他人の情報が表示されている状態に、システムではなく顧客の問い合わせで気付いた。画面やAPIで返す個人情報のレコード所有者IDと、ログイン・セッション上のユーザーIDが一致しない場合にログへ記録して警報を出す仕組みを入れる。あわせて、「他人の情報が見える」という問い合わせを窓口から即座にセキュリティ担当へ上げる手順を決めておく。
登録を途中でやめた利用者は、ログから連絡先を特定できない場合がある。アクセスログに、セッションID・表示や返却したレコードID・時刻を残す。影響範囲の調査で「誰の情報が誰に表示されたか」を後からたどれる粒度で、一定期間保存する。
開発を委託した機能では、発注側の受け入れ基準が品質の最後の砦になる。委託契約や受け入れ基準に、個人情報を扱う機能の同時実行・負荷テストとその結果の提出を明記する。発注側の責任者による承認をリリースの条件にする。

自組織などでの確認項目

  1. 自社の会員登録・ログイン・外部ID連携の機能について、複数ユーザーが同時に操作したときに他人の情報が返らないことを確かめるテストがありますか?
  2. 画面やAPIで返した個人情報の持ち主と、セッションのユーザーが一致しないことを検知する監視やログの仕組みがありますか?
  3. 開発委託先から納品を受けるとき、受け入れテストに高負荷時・同時アクセス時などの異常系の項目が含まれていますか?
  4. 登録を途中でやめた利用者についても、事故の際に影響範囲と連絡先を特定できるだけのログを保存していますか?

未解明点

  • 不具合の具体的な実装上の原因(共有変数・キャッシュ・ID連携の戻り処理など、どこで取り違えが起きたか)は公表されていない。
  • 2025年8月20日に何が変わり(機能のリリースや改修など)、事象が始まったのかは公表されていない。
  • 11月2日の発覚から11月4日の発生期間終了までの対応経緯(機能をいつ止めたか)は公表されていない。
  • 最大176名のうち、実際に他人に閲覧されたことが確定した人数は公表されていない。

出典

  1. 1
  2. 2