ネット印刷「ウエーブ」、最大17万6810件の顧客情報が流出した可能性 — 印刷入稿データも対象、15年分が1つのサービスに
| 項目 | 内容 |
|---|---|
| 発生日 | 2025年10月29日未明(不正アクセス検知) |
| 対象組織・業界 | ウエーブ(ネット印刷サービス。ウイルコホールディングス子会社) |
| 攻撃手法 | 不正アクセス(侵入経路は非公表) |
| 情報源 | Security NEXT(2026年4月13日) |
ウイルコホールディングスの子会社でネット印刷サービスを提供するウエーブは、同社のサーバが侵害された問題について調査結果を取りまとめました。システム情報が閲覧された可能性が判明し、顧客情報も影響を受けた可能性があります。
同社によると、2025年10月29日未明、同社が運営するeコマースサイトのサーバにおいて不正アクセスを検知。同日、攻撃を受けたサーバをネットワークから遮断しました。10月31日に事態を公表し、対応を進めてきました。
外部協力のもと調査を進める過程で、ウェブアップロードサービスを管理するシステムが不正アクセスされ、第三者がシステム情報を閲覧した可能性があることが判明しました。2026年4月1日時点で、外部へのデータ転送、ウェブコンテンツ、データベースなどがアクセスされた痕跡は確認されておらず、二次被害も確認されていませんが、個人情報が外部へ流出した可能性があるとしています。
対象は2010年8月20日から2025年10月30日までに同社のウェブアップロードサービスを利用した顧客で、氏名、メールアドレス、ID、印刷入稿データ、EC商材見積書など最大17万6810件にのぼります。
- 2025年10月29日未明: eコマースサイトのサーバで不正アクセスを検知
- 2025年10月29日: 攻撃を受けたサーバをネットワークから遮断
- 2025年10月31日: 事態を公表。個人情報保護委員会へ報告
- 2025年12月25日: 個人情報保護委員会へ追加報告
- 2026年3月25日: 個人情報保護委員会へ確報を報告
- 2026年4月1日: 対象顧客へメールで連絡を開始。同時点で外部へのデータ転送等の痕跡は未確認
- 2026年4月13日: 調査結果として報道
侵入経路・初期アクセスの手法は公表されていません。同社は「eコマースサイトのサーバにおいて不正アクセスを検知」とし、その後の調査で「ウェブアップロードサービスを管理するシステム」への不正アクセスが判明したと説明しています。
考えられる原因(推測): ネット印刷事業者の構成では、注文を受けるECフロントエンドと、入稿データを受け取るアップロードサービスが別システムとして並存しているのが一般的です。本件でECサーバの侵害を検知した後にアップロードサービス側の侵害が判明したという順序は、(a) 攻撃者が最初の侵入点から内部を横移動して別システムに到達した、(b) 両システムが同じ管理系(共通の認証基盤や管理端末)を共有していた、のいずれかを示唆します。初期アクセスとしては、公開Webアプリケーションの脆弱性、管理画面への認証情報の窃取・総当たり、ミドルウェアの既知脆弱性の悪用が典型です。2010年から15年分のデータが対象になっている点からは、入稿データが自動削除されずに蓄積され続ける設計だったことがうかがえます。
組織が学ぶべきこと
Section titled “組織が学ぶべきこと”1. 「入稿データ」は個人情報以上に機微な場合がある
Section titled “1. 「入稿データ」は個人情報以上に機微な場合がある”本件の対象には氏名・メールアドレスに加えて印刷入稿データが含まれます。ネット印刷の入稿データとは、名刺(氏名・役職・直通番号・メール)、DM用の宛名リスト、社内報、未発表の製品カタログ、株主向け資料といったものです。つまり顧客の顧客の個人情報や、公開前の企業情報がそのまま入っている可能性があります。「氏名とメールアドレスが漏れた」という定型の被害表現では、実際のリスクを言い表せません。入稿データを預かる事業者は、この一段深い機微性を前提に保管期間と暗号化を設計する必要があります。
2. 15年分を保持し続ける理由があるか
Section titled “2. 15年分を保持し続ける理由があるか”2010年8月から2025年10月まで、という対象期間の長さが、被害規模をそのまま決めています。もし入稿データを「納品後○年で自動削除」する運用だったなら、対象は数万件規模に収まっていたはずです。保持期間の設計は、事故が起きたときにだけ効いてくるコスト削減策です。再入稿の利便性という顧客価値との天秤ではありますが、少なくとも「なぜこの期間なのか」を説明できる状態にしておく必要があります。
3. 「痕跡は確認されていない」の読み方
Section titled “3. 「痕跡は確認されていない」の読み方”同社は2026年4月1日時点で「外部へのデータ転送、ウェブコンテンツ、データベースなどがアクセスされた痕跡は確認されていない」としています。これは調査が丁寧に行われたことを示す表現ですが、転送の痕跡が「なかったことを確認した」のか「確認できるログがなかった」のかでは意味が異なります。アウトバウンド通信のログが十分な期間・粒度で保存されていて初めて、前者と言えます。
ヤグラの視点 — 攻撃面の拡張:遮断したのはECサーバ、侵害されていたのは別のシステムだった
Section titled “ヤグラの視点 — 攻撃面の拡張:遮断したのはECサーバ、侵害されていたのは別のシステムだった”10月29日未明に検知し、同日中にサーバを遮断——初動としては速い部類です。それでも、遮断した対象と、実際に侵害されていた対象は同じではありませんでした。ウェブアップロードサービスを管理するシステムへの不正アクセスが判明したのは、その後の調査の過程です。
これは対応の失敗ではなく、攻撃面が組織の把握より広いという構造の問題です。ECサイト、アップロードサービス、その管理システム、見積機能、旧バージョンの残置環境。事業の成長に合わせて増えたシステムは、それぞれ別の時期に、別の担当者が、別の理由で立てています。インシデント時に「どこを止めればよいか」を即答できる組織は多くありません。
本件が示すのは、インシデント対応の初動の質が、平時の資産把握の精度で決まるということです。攻撃を受けたサーバを1台止めても、同じ管理系につながる別システムが残っていれば、侵害は継続し得ます。何が、どこに、どうつながっているか——これを事故の最中に調べ始めると、確報までに5カ月かかります。
侵入から検知までの時間差が被害規模を決めます。人手で全ログを監視するのは現実的でなく、AIによる24時間365日の横断ログ監視と自動封じ込め(検知から初動まで平均数分)が現実解になりつつあります。→ ヤグラ AI SOC
そのうえで、監視の前提として必要なのは「監視すべきシステムの一覧」が正しいことです。ログを集める仕組みを入れても、一覧に載っていないシステムのログは集まりません。本件のアップロードサービス管理システムのような、事業の主役ではないが顧客データを持っているシステムを漏れなく拾えているかどうか。攻撃面の棚卸しは、検知の仕組みを入れる前にやるべき作業です。
同社は2026年3月25日に個人情報保護委員会へ確報を提出し、4月1日から対象顧客へのメール連絡を開始しています。侵入経路の特定結果、および入稿データの二次利用に関する続報を注視します。
| 日時 | 内容 |
|---|---|
| 2026-08-07 | 初稿公開(2026年4月13日報道時点) |