楽天ブックスネットワークのPC端末への不正アクセス（配送先情報3万3,333件ほか保存、漏えいは未確認）
公表日
楽天ブックスネットワークが使う一部のパソコンに外部から不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。がありました。そのパソコンには、楽天ブックスの配送先情報3万3,333件、取引先担当者の情報2,101件、従業員の情報339件が保存されていました。同社は、これまでの調査では情報が漏れた事実は確認されていないとしています。
対象者は？
対象は次の3つです。 ・2022年5月18〜19日と2023年12月19〜21日の楽天ブックスの注文データに含まれていた配送先情報3万3,333件（氏名、郵便番号、住所、電話番号） ・取引先担当者2,101件（氏名、メールアドレス、電話番号） ・同社従業員339件（氏名、業務用メールアドレス、電話番号、生年月日） クレジットカード番号などの金融情報は含まれていません。3つを足すと3万5,773件ですが、重複があるかどうかはわからず、同社は合計件数を発表していません。
対象の顧客・取引先担当者・従業員には、同社からメールで通知されています。
いますぐできること
- 楽天ブックスネットワークや楽天グループを名乗る不審な電話、メール、SMSに注意してください。
- 心当たりのある人は、同社から通知メールが届いていないか確認してください。
何が起きたのか
2026年4月5日、楽天ブックスネットワークは、自社で使う一部のパソコンに外部の第三者が不正にアクセスしたことに気づきました。すぐにそのパソコンを社内のネットワークから切り離し、外部の専門機関と調査を始めました。8月21日にこの件を発表し、対象の人へメールで知らせるとともに、個人情報保護委員会に報告しました。
なぜ起きたのか・なぜ広がったのか
どこから、どのように侵入されたのか、原因は何かは発表されていません。数年前の配送先情報がなぜそのパソコンに保存されていたのかも発表されていません。
いまの状況2026-08-25 時点続報待ち
同社は、これまでの調査では情報が漏れた事実は確認されておらず、8月21日の時点でこの件が原因とみられる二次被害も確認されていないとしています。楽天ブックスの配送や販売に障害が出たとの発表はありません。原因や再発防止策、補償については、まだ発表されていません。
企業として考えたいこと
自社の社員のパソコンに、作業のために取り出した顧客の名簿や配送先のファイルが、何年も前の分まで残ったままになっていないでしょうか。
技術的な要約
楽天ブックスネットワーク株式会社は2026年8月21日、同社が使用する一部のPC端末に社外の第三者による不正アクセスがあったと公表した。同社は2026年4月5日に不正アクセスを検知し、対象PCをネットワークから隔離して外部専門機関と調査を開始した。対象PCには楽天ブックスの配送先情報3万3,333件、取引先担当者情報2,101件、同社従業員情報339件が保存されていた。同社は、これまでの調査では各情報が漏えいした事実は確認されておらず、8月21日時点で二次被害も確認されていないと説明している。侵入経路・原因・攻撃手法や攻撃者は公表されておらず、個人情報保護委員会への報告と対象者へのメール通知が行われた。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 不明同社が使用する一部のPC端末に対し社外の第三者による不正アクセスがあったと公表されたが、侵入経路、原因、攻撃手法は公表されていない。
- 脆弱性
- CVE 非公表不明悪用された脆弱性やCVEは公表されていない。
- 攻撃者
- 特定・主張なし
- ATT&CK
- —
影響
- 業務停止
- なし 不正アクセスによって楽天ブックスの商品配送や販売サービスに障害が発生したとの発表はない。
- データ
- おそれ上限 —確定 —件氏名住所電話メール生年月日従業員情報取引先情報対象PCに保存されていた情報の内訳：楽天ブックス配送先情報3万3,333件（氏名、郵便番号、住所、電話番号。2022年5月18〜19日および2023年12月19〜21日の注文データ）、取引先担当者2,101件（氏名、メールアドレス、電話番号）、同社従業員339件（氏名、業務用メールアドレス、電話番号、生年月日）。3区分の単純合算は3万5,773件だが、同社は合計件数を公表しておらず重複の有無も不明。同社は各情報が漏えいした事実は確認されていないと説明。クレジットカード番号などの金融情報は含まれない。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- 楽天ブックスのECサイトや楽天グループのシステム自体への不正アクセスが確認されたとは発表されていない。
時系列
- 2022-05-18対象PCに保存されていた楽天ブックス配送先情報の対象注文データ期間（2022年5月18日〜19日）。1
- 2023-12-19対象PCに保存されていた楽天ブックス配送先情報の対象注文データ期間（2023年12月19日〜21日）。1
- 2026-04-05同社が一部PC端末への不正アクセスを検知。1
- 2026-04-05対象PCをネットワークから隔離し、外部専門機関とともに調査を開始。1
- 2026-08-21
- 2026-08-21調査では各情報の漏えいは確認されず、本件に起因すると考えられる二次被害も確認されていないと説明。1
- 2026-08-24セキュリティ対策Labが、配送先情報3万3,333件の保存と漏えい未確認を報じた。1
- 2026-08-25ScanNetSecurityが、利用者33,333件の個人情報等が保存されていたと報じた。2
技術解説
公表された事実と経緯 事実
楽天ブックスネットワーク株式会社は2026年4月5日、同社が使う一部のPC端末への不正アクセスを検知しました。アクセスしたのは社外の第三者です。同社は直ちに対象PCをネットワークから隔離し、外部専門機関とともに調査を始めました。公表は2026年8月21日です。同社は個人情報保護委員会へ報告し、対象となる顧客・取引先担当者・従業員へメールで通知しました。対象PCには次の情報が保存されていました。 ・楽天ブックスの配送業務に関連する配送先情報3万3,333件：2022年5月18〜19日と2023年12月19〜21日の注文データに含まれていたもので、項目は氏名、郵便番号、住所、電話番号 ・取引先担当者情報2,101件：氏名、メールアドレス、電話番号 ・同社従業員情報339件：氏名、業務用メールアドレス、電話番号、生年月日 クレジットカード番号などの金融情報は含まれていません。同社は、楽天グループを名乗る不審な電話、メール、SMSなどにも注意するよう呼びかけています。
確認されていない事項と件数の扱い 事実
同社は、これまでの調査で各情報が漏えいした事実は確認されていないと説明しています。本件が原因とみられる二次被害も、8月21日時点では確認されていません。公表された件数は「対象PCに保存されていた件数」で、流出が確定した件数ではありません。3区分を単純に足すと3万5,773件ですが、同社は合計件数を公表しておらず、重複があるかどうかもわかっていません。 次の事項は公表されていません。 ・侵入経路、原因、攻撃手法 ・ランサムウェアやマルウェアが使われたかどうか ・攻撃者、IOC 楽天ブックスのECサイトや楽天グループのシステムそのものへの不正アクセスが確認されたとは発表されていません。商品配送や販売サービスに障害が出たとの発表もありません。警察への相談・申告の有無、配送先データがPCに保存されていた理由、保存期間のルールも、公表資料からは確認できません。
端末に残った業務データが対象範囲を決めた構造 解釈
対象の配送先情報は、2022年と2023年のそれぞれ数日間の注文データに限られています。そのため、配送対応や集計など何らかの業務のために抜き出したデータが、作業後も端末に残っていた可能性が考えられます。ただし、保存していた理由や保存期間のルールは公表されておらず、これは推測にとどまります。 一般に、基幹システムから切り出したCSVなどの作業ファイルは、システム側のアクセス制御や操作ログの管理から外れます。そのため端末1台が侵害されると、数年前のデータまで影響範囲に入ってしまいます。本件でも、ECサイト本体への侵入は確認されていません。それでも端末単体に3万件を超える配送先が残っていたことが、通知対象を広げる要因になったと読めます。端末に置くデータの最小化と、期限を決めた削除が、影響範囲を左右する論点になります。
公表のタイミングと「漏えい未確認」の読み方 解釈
検知から公表までは約4か月半かかりました。外部専門機関の調査で漏えいの有無を見極めてから通知する判断だったと考えられます。漏えいが確認されていない段階で、保存件数と項目を区分ごとに示して公表した点は、透明性の面で評価できる部分があります。一方で、その期間、対象者はなりすまし連絡への注意喚起を受けられませんでした。 また、今回確認できる出典は報道2件だけです。侵入経路や攻撃手法に加え、端末の操作ログや通信ログがどこまで残っていたかなど、「漏えいは確認されていない」と判断した根拠も明らかではありません。一般論として、ログが足りなければ「確認されない」は「無かった」と同じ意味になりません。続報で判断根拠や再発防止策が示されるかどうかが、本件の評価を左右します。
対応
- 封じ込め
- 検知後、直ちに対象PCをネットワークから隔離し、外部専門機関とともに調査を開始した。
- 公表の仕方
- 2026年8月21日に公表。対象の顧客・取引先担当者・従業員へメールで通知し、同社や楽天グループを装った不審な電話、メール、SMSなどへの注意を呼びかけた。検知（4月5日）から公表まで約4か月。
- 当局対応
- 個人情報保護委員会へ報告済み。警察への相談・申告は公表資料から確認できない。
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 基幹システムから抜き出した顧客データが、作業後も業務端末に長く残ることがある。端末1台の侵害で、過去数年分のデータまで影響範囲に入る。 | CSVなど顧客データの抜き出しを申請・承認制にして、出力ログを残す。端末上のファイルはDLPや定期スキャン（氏名・住所・電話番号のパターン検知）で見つけ、保存期限（例：作業完了から30日）を過ぎたら自動で削除するか、管理者に警告する。 |
| 検知後すぐに端末を隔離するだけでは、漏えいの有無を後から証明できないことがある。 | EDRで端末を論理的に隔離し、電源を切る前にメモリとディスクの保全イメージを取る手順をインシデント対応手順書に書いておく。プロキシ、ファイアウォール、EDRのログは最低1年保持する設計にする。 |
| 漏えいが確認されていなくても、氏名・住所・電話番号などが対象になると、なりすまし連絡（フィッシング）のリスクを対象者に伝える必要がある。 | 「漏えいのおそれ」の段階で使う通知文と問い合わせ窓口のテンプレートを用意しておく。調査が長引く場合は、途中経過を公表するか、先行して注意喚起する判断基準（例：検知から30日以内）を決めておく。 |
| 従業員の生年月日や取引先担当者の連絡先も、同じ端末に一緒に置かれることがある。顧客情報とは別の区分として影響範囲に入る。 | データ分類（顧客／取引先／従業員）ごとに、保存してよい場所（端末か、管理されたファイルサーバ・SaaSか）を定める。端末のローカル保存は、MDMやアクセス制御ポリシーで原則禁止にする。 |
| 侵入経路が公表されていない事案では、他社が教訓にできるのは端末管理と検知体制の一般論に限られる。 | 自社の業務端末について、EDRの導入率、OSとアプリのパッチ適用状況、ローカル管理者権限の有無、リモートアクセスツールの棚卸しを四半期ごとに確認し、未対応の端末を一覧にして是正する。 |
自組織などでの確認項目
- 業務端末のローカルディスクに、顧客の氏名・住所・電話番号を含むファイルが何件、何年前のものから残っているか。それを検出する仕組みはあるか。
- システムからの顧客データの出力（CSVのエクスポートなど）について、誰がいつ何件出力したかを追えるログと、出力後に削除する期限のルールはあるか。
- 端末への不正アクセスを検知したとき、隔離と同時にフォレンジック用の証拠を保全する手順があり、漏えいの有無を判断できるだけのログ（EDR・プロキシ・ファイアウォール）を保持しているか。
- 調査が長引く場合に、漏えいが確定する前でも対象者へ注意喚起する判断基準と、通知文のテンプレートを用意しているか。
未解明点
- 侵入経路、原因、攻撃手法は何か。ランサムウェアやマルウェアは使われたのか。
- 侵入日はいつで、検知までどれくらいの期間があったのか。
- 「漏えいした事実は確認されていない」と判断した根拠は何か（ログの保存状況や、外部専門機関による調査の範囲）。
- 2022年と2023年の配送先データが、なぜ対象PCに保存され続けていたのか。保存期間のルールはあったのか。
- 対象PC以外の端末やシステムに侵害が広がっていないことは、どのように確認したのか。
- 警察へ相談・申告したかどうか、また再発防止策の具体的な内容。
出典
- 1セキュリティ対策Lab（合同会社ロケットボーイズ）2026-08-24報道本文確認済
- 2ScanNetSecurity2026-08-25報道本文確認済