skyticketで約1,464万件が流出、3つの別経路が同時期に判明 — 管理機能・業務システム・ログイン不要の予約ページを自社でも棚卸しする

skyticketで約1,464万件が流出、3つの別経路が同時期に判明 — 管理機能・業務システム・ログイン不要の予約ページを自社でも棚卸しする
Photo: Pexels (Pexels) / Omamori AI brand overlay

比較予約サイト「skyticket」を運営するアドベンチャーは2026年10月9日、同サイトのシステムが3件の不正アクセスを受け、利用者の個人情報が流出した、または流出したおそれがあると公表した。3件は経路がそれぞれ異なり、最も大きい1件では約1,464万件の氏名・生年月日・メールアドレス・電話番号・住所などが流出した。このうち約413万件には、ハッシュ化した会員のログインパスワードが含まれる。クレジットカード番号とパスポートの画像は同社が保存しておらず、流出していない。この記事では3件の経路を公表資料に沿って整理し、Webサービスを運営する企業が自社で確かめる点をまとめる。

背景

同社の発表によると、3件の内容は次のとおりである。

1件目は、同社サーバーへの不正アクセスである。10月2日から4日にかけて、skyticket の一部の管理機能が不正に操作され、そこから同社の他のサーバーと、クラウド上に保管していたデータにアクセスされた。同社は10月5日に気づいた。対象は約1,464万件で、氏名(パスポート表記を含む)、生年月日、メールアドレス、電話番号、郵便番号・住所、振込時の依頼人名義、ハッシュ化したログインパスワードが流出した。パスポート番号は流出していないことを確認済みとしている。

2件目は、業務管理システムへの不正アクセスである。9月20日に同システムの脆弱性を悪用され、同社は9月28日に気づいた。対象は重複を含めて17,780件で、ほかに件数を調査中のものがある。氏名、電話番号、返金先の口座情報(金融機関名・支店名・口座種別・口座番号・口座名義)などが流出した、または流出したおそれがある。これとは別に、9月9日に会員1名のアカウントへの不正ログインも確認している。

3件目は、バス予約サービスの予約情報の閲覧である。8月3日から10月1日まで、バスの予約完了ページがログインをしなくても表示できる状態になっており、第三者に機械的に閲覧された。対象は予約約12,000件で、予約者の氏名(カナ)、メールアドレス、電話番号、乗車便の日時・乗降地・予約番号、同行者の氏名などが含まれる。同社は10月1日に修正した。

同社は不正アクセスの経路を遮断し、10月7日18時ごろに、保存済みクレジットカードによる支払いとカード情報の保存機能を止めた。対象者にはメールで順次連絡し、個人情報保護委員会に報告している。

リスクの全体像

利用者にとっての危険は、流出した情報の種類ごとに異なる。同社は4つを挙げている。氏名や連絡先を使った詐欺メール・SMS・電話・郵便物、ハッシュ化したパスワードが解析されることによる不正ログイン、返金手続きを装って口座の暗証番号やインターネットバンキングのIDを聞き出そうとする連絡、乗車便や予約番号を知った第三者が予約の変更や追加料金を求める連絡である。同社は、本件に関して利用者に金銭の支払いを求めることは無く、連絡メールにパスワードの入力を求めるリンクは記載しないと明記している。

企業側から見て注目すべきは、1社で同じ時期に、種類の違う3つの入口が見つかった点である。

1つめは管理機能である。管理機能は社内の担当者が使うためのもので、会員情報の検索や設定変更など強い権限を持つ。ここを操作されると、今回のように他のサーバーやクラウド上のデータまで届くことがある。管理機能がどのように操作されたかは公表されていない。

2つめは業務管理システムである。返金や問い合わせの処理に使う社内向けのシステムは、利用者向けのサイトに比べて更新や点検が後回しになりやすい。一方で、口座情報のように利用者向けのサイトには出てこない情報を持っている。

3つめは、ログイン不要で見えるページである。予約完了ページのように、URL を知っていれば表示できるページは、URL に含まれる番号を順に変えるだけで他人の情報を表示できる場合がある。今回は約2か月間、気づかれないまま閲覧が続いた。

チェックリスト

  • 自社サイトの管理画面・管理機能がいくつあり、それぞれインターネットのどこからでも開ける状態になっていないか
  • 管理機能を動かすサーバーから、他のサーバーやクラウド上の保管場所へ、業務に不要な接続ができる状態になっていないか
  • 返金・問い合わせ・在庫などの社内向けシステムを、利用者向けサイトと同じ頻度で更新・点検しているか
  • 予約完了、注文確認、請求書表示など、ログインなしで個人情報が表示されるページが残っていないか
  • そのページの URL が、番号を1つずつ変えるだけで他人のものに切り替わる作りになっていないか
  • 同じ接続元から短時間に大量のページが開かれたとき、止めるか通知する設定があるか
  • クラウド上に置いた会員データの写しやバックアップに、誰がどの権限で届くかを一覧にしているか

打ち手

予約サイトや EC サイトを運営する企業は、まず入口の一覧を作る。利用者向けのページだけでなく、管理画面、社内向けの業務システム、ログインなしで開けるページの3種類を書き出す。外部の開発会社に任せている場合は、一覧の提出を求める。今回の3件は、この3種類にそれぞれ1件ずつ当たる。

管理画面は、接続元を社内の回線や VPN に限定し、ログインには多要素認証を必須にする。あわせて、管理機能を動かすサーバーが届く範囲を絞る。管理機能のサーバーからクラウド上の全データを読める設定になっていると、管理機能を1つ操作されただけで全件が流出する。業務に必要な保管場所と操作だけを許可する。

ログインなしで開けるページは、表示する情報を減らすか、ログインを必須にする。メールのリンクから開かせる必要がある場合は、URL に推測できない長い文字列を入れ、有効期限を付ける。番号を順に変えて開く動きは、接続元ごとの回数制限で止められる。

skyticket の会員は、パスワードを変更し、同じパスワードを使っている他のサービスも変更する。変更は公式サイトか公式アプリから直接行い、メールのリンクからは入力しない。マイページの予約履歴とカードの利用明細も確かめる。

あわせて読みたい

Omamori AI の結論

skyticket の件は、管理機能、社内向けの業務システム、ログイン不要のページという3つの入口が、同じ会社で同じ時期に悪用されうることを示した。Webサービスを運営する企業は、利用者向けの画面だけを点検対象にせず、この3種類を一覧にして、接続できる範囲と表示される情報を確かめておくべきである。

経営者視点で考えるべきこと

3件のうち2件は、気づくまでに8日と約2か月かかっている。脆弱性診断を公開前に1度受けただけでは、後から追加した機能や社内向けのシステムは対象から漏れる。診断の対象範囲に管理画面と業務システムが入っているかを、発注時に確認したい。また、カード番号とパスポート画像を自社で保存していなかったことで、被害の範囲は限定された。預かる情報を減らす設計は、事故が起きたときの損失を直接小さくする。

SHARE 𝕏 in f

あわせて読みたい