佐川急便「お荷物問い合わせサービス」への不正アクセス。Webで見えるのは60日なのに流出可能性は約100日分、止めたのは9サービス、パスワードとカード情報は対象外。公表された被害範囲の境界から、攻撃者が取った権限と届かなかった領域を逆算する。
2026年9月30日、佐川急便は「お荷物問い合わせサービス」への第三者による不正アクセスを確認したと公表しました。
翌10月1日の続報では、個人情報が外部に流出した可能性があることを明らかにしています。
対象として公表されたのは、大きく三つです。
荷物については、9月30日からさかのぼって約100日間の累計データが対象です。
一方、クレジットカード情報とパスワードは含まれていないとしています。
そしてもう一つ気になるのが、佐川急便が止めたサービスの数です。
停止したのは「お荷物問い合わせサービス」だけではありません。
そのAPI、飛脚宅配便受付、飛脚往復便受付、商品回収返金サービス、受取先変更など、計9つのWebサービスを停止しました。
しかし、集荷や配達そのものは続いています。
ここで、一見すると少し不思議なことがあります。
9サービスも止めたのに、流出した可能性があるのは一部のデータです。
もし9サービスが同じように危険だったのであれば、もっと多くの情報が対象になっていてもおかしくありません。
逆に、漏れたのが一部のデータだけなら、なぜ9サービスも止める必要があったのでしょうか。
今回の事案を考えるうえで、私はこの矛盾のように見える部分が一番面白いと思っています。
9サービスを止めたという事実から、
「9サービスすべてが侵害された」
とは言えません。
サービス停止は、実際の侵害範囲より広く取ることがあります。
一つのサービスで侵害を確認した。
しかし、そのサービスが他のサービスとどこまで基盤を共有しているのか、短時間では分からない。
同じ認証基盤なのか。
同じWeb基盤なのか。
共通APIを使っているのか。
同じアプリケーションサーバーなのか。
同じDB接続基盤なのか。
そこが分からなければ、影響の可能性があるサービスをまとめて止めるのは自然です。
つまり9サービスという数字は、
実際に侵害されたサービスの数ではなく、影響を否定できなかった範囲
だった可能性があります。
一方、実際に攻撃者が読めるデータの範囲は、別の仕組みで決まります。
それが権限です。
例えば9つのサービスが、同じ認証基盤やWeb基盤を使っていたとします。
それでも、各サービスが同じデータを自由に読めるとは限りません。
構成としては、
9つのWebサービス
↓
共通の認証・Web・API基盤
↓
サービスごとのアプリケーション権限
↓
参照できるテーブルやAPI
という形もあり得ます。
入口や共通基盤で問題が見つかれば、9サービスをまとめて止める必要があります。
しかし、その侵入から使えた権限が、あるアプリケーション用のDBユーザーやAPI権限に限定されていれば、読めるデータも限定されます。
例えば、その権限から見えたのが、
だった。
一方で、
には届かなかった。
そういう構造なら、
9サービスを止めたことと、一部のデータだけが流出対象になったことは矛盾しません。
むしろ両方を一緒に見ることで、
共通していた部分と、分離されていた部分
が見えてきます。
今回の公表から想像できるのは、
表側のサービスや一部の基盤は共通していた。
しかし、その先のデータアクセス権限までは完全に共通ではなかった。
という構造です。
一つのサービスで侵害が確認されたため、同じ基盤を使う可能性がある9サービスを停止した。
一方、調査してみると、実際に侵害された権限から参照できたのは一部のデータだった。
もしそうなら、佐川急便が発表した二つの数字は意味が違います。
9サービスは、影響を否定できなかった範囲。
3系統のデータは、実際に到達できた可能性がある範囲。
ここを混同すると、
「9サービス全部が侵害された」
あるいは逆に、
「一部のデータしか漏れていないなら9サービス停止は過剰だった」
という読み方になります。
しかし、インシデント対応ではこの二つは別です。
停止は広く。
確認された被害範囲は狭く。
ということは普通にあります。
さらに気になるのが、配送情報の期間です。
佐川急便の「お荷物問い合わせサービス」で、利用者が確認できる荷物情報は発送日から60日間です。
法人向けの荷物情報照会でも、表示対象は発送日から60日間と案内されています。
ところが今回、流出した可能性がある荷物情報は約100日分でした。
ここで「40日長い」ことだけを見る必要はないと思います。
もっと気になるのは、
なぜ100日より前の配送履歴が対象として出てきていないのか。
という点です。
物流会社が配送履歴を100日ですべて消しているとは考えにくいでしょう。
会計、事故対応、問い合わせ、監査などを考えれば、より古い情報はどこかに残っているはずです。
もし侵害された権限から、長期保管された過去の配送履歴まで自由に参照できたのであれば、流出可能範囲が約100日で止まる理由は弱くなります。
もちろん、現時点の調査で確認できた範囲が100日だけという可能性もあります。
攻撃者が古いデータを取らなかっただけかもしれません。
ただ、もう一つ考えられるのは、
侵害されたアプリケーション権限から見えていたのが、オンライン側に置かれた約100日分までだった
という形です。
その先は、
別のデータベース。
別のアカウント。
別の保管基盤。
別のネットワーク。
だったのかもしれません。
だとすれば、「約100日」という数字もまた、
被害件数の説明ではなく、
権限が届いた範囲の境界
として読むことができます。
スマートクラブについて流出した可能性があるとされたのは、
氏名、住所、電話番号、メールアドレス、会員IDです。
しかし、パスワードは含まれていません。
クレジットカード情報も対象外です。
ここも重要です。
プロフィール情報に届いたからといって、認証基盤まで取られたとは限りません。
顧客プロフィールと認証情報が別のデータベースだったのかもしれません。
認証自体を別基盤で処理していた可能性もあります。
クレジットカードについても、決済系が別システムや決済事業者側に分離されていれば、配送系や会員系のアプリケーションを侵害されてもカード情報には届きません。
つまり今回の公表を見るときは、
「何が漏れたか」
だけではなく、
何が漏れなかったか
を見る必要があります。
漏れなかった情報は、権限分離がどこにあったかを考える手掛かりになります。
今回の公表を整理すると、三つの境界が見えます。
まず横方向。
9サービス。
同じ侵害経路や共通基盤の影響を否定できず、停止した範囲。
次にデータ方向。
配送情報、運賃契約顧客、スマートクラブ情報。
実際に侵害された権限から参照できた可能性がある範囲。
そして時間方向。
約100日。
配送データをどこまでさかのぼって参照できたかという範囲です。
この三つを並べると、
9サービス全部が同じデータベースを自由に読めた、
という単純な構造ではなかった可能性が見えてきます。
むしろ、
入口や一部基盤は共有していたが、データへの権限は分離されていた。
そう考えると今回の公表内容は説明しやすくなります。
ここも重要です。
今回の被害範囲だけを見て、
データベース管理者相当の権限を奪われた、
と考える必要はありません。
Webアプリケーションは通常、自分が必要とするデータへアクセスするためのDBユーザーやAPI権限を持っています。
その権限が限定されていれば、アプリケーションを侵害されても、攻撃者が読める範囲はその権限内にとどまります。
例えば、
配送情報は読める。
契約顧客情報も読める。
スマートクラブのプロフィールも読める。
しかし、
パスワードは読めない。
カード情報も読めない。
長期保管の配送履歴にも届かない。
そういう構成なら、今回の公表とかなり整合します。
つまり今回のポイントは、
侵入されたかどうかだけではありません。
侵入されたあと、その権限でどこまで行けたのか。
です。
そしてもう一つ。
佐川急便は9つのWebサービスを停止しましたが、集荷・配達そのものは続いています。
これも境界を考える手掛かりになります。
もし配送基幹全体まで同じ侵害範囲に含まれていたのであれば、さらに広い停止が必要だった可能性があります。
しかし実際には、外部向けWebサービス群を止めながら、物流そのものは動いています。
もちろん、業務継続上の判断で動かしていた可能性もあるため、これだけでシステム分離を断定することはできません。
それでも、
止めた9サービスと、止めなかった配送基幹の間に何があったのか
は、次の続報で知りたいところです。
公開DNS、証明書、HTTP応答などから佐川急便関連の公開面を確認すると、今回の調査では174件のホスト名候補が見つかりました。
主要な一般向けWebではAkamaiを経由する構成も複数確認できます。
一方で、その周辺には、
EDI系。
外部接続系。
取引先向け。
BCP系。
検証・ステージング系。
など、用途の異なる公開面もあります。
ただし、これらのどこかが今回の侵入口だったことを示す証拠はありません。
外形だけから侵入口を決めることはできません。
今回私が気になるのは、どの製品のどの脆弱性だったかより、
入口から取られた権限が、その先のどこまで届いたのか
です。
次の報告で確認したいのは、脆弱性の製品名だけではありません。
むしろ知りたいのは、
9サービスで何を共有していたのか。
認証なのか。
Web基盤なのか。
APIなのか。
アプリケーションサーバーなのか。
DB接続基盤なのか。
そして、
どこから先は分離されていたのか。
サービスごとにDBユーザーが違ったのか。
テーブル単位で権限が分かれていたのか。
API単位だったのか。
長期保管データは別基盤だったのか。
認証情報や決済情報は別システムだったのか。
さらに、
何をきっかけに9月30日に不正アクセスを確認したのか。
大量ダウンロードだったのか。
DBアクセスの異常だったのか。
不審なAPIアクセスだったのか。
外部通報だったのか。
ここも重要です。
9サービスを止めたのに、一部データしか漏れていない
この二つは矛盾ではありません。
むしろ、そこに今回のシステムの形が見えている可能性があります。
共通基盤があったから、広く止めた。
しかし権限が分離されていたから、読めたデータは一部にとどまった。
そして配送履歴は約100日で切れた。
パスワードとカード情報には届かなかった。
もしそうであれば、今回の事案は、
「侵入を防げなかった」
という話だけではありません。
侵入された後に、どこで権限が切れていたのか。
そこまで見るべき事案だと思います。
次の答え合わせで知りたいのは、
どこから入ったのか。
だけではありません。
9サービスで何を共有し、どこから権限を分けていたのか。
そして、
その分離が実際にどこまで被害を止めたのか。
そこです。
Aikido Community Japan
公開日: 2026/10/2
最終更新: 2026/10/2
セキュリティの最新情報をお届けします。