skyticket不正アクセス：1,464万件流出の対象確認と本物メールの見分け方

格安航空券の比較予約サイト「skyticket（スカイチケット）」を運営する株式会社アドベンチャーは2026年10月9日、3件の不正アクセスで顧客情報が流出した、または流出したおそれがあると公表しました。最大の1件は約1,464万件で、うち約413万件には会員のログインパスワード（ハッシュ化したもの）が含まれます。本記事の前半は、届いたお知らせメールは本物か、パスワードは変えるべきか、どこに問い合わせるかという利用者の疑問への、公式発表に沿った回答です。後半では、予約完了ページがログインなしで見えた不備とパスワードの保存方式を取り上げ、予約サイトの開発者が同じ穴をふさぐ実装をPythonのコードで示します。

まとめ：skyticket不正アクセスで公表された3つの経路と利用者・事業者の対応

公表された不正アクセスは、経路の異なる3件です。管理機能の不正操作からクラウド上のデータに達した件、業務管理システムの脆弱性を突かれた件、バスの予約完了ページがログインなしで表示できた件で、発生時期も流出した項目も違います。クレジットカード番号とパスポートの画像は同社が保存しておらず、いずれの件でも流出していません。

利用者がまずやることは、skyticketのパスワード変更と、同じパスワードを使う他サービスの変更です。そのうえで、返金や補償を名目に振込や暗証番号を求める連絡には応じません。開発者が受け取る教訓は2つです。予約IDを知っていれば誰でも開ける画面は、連番を順に試すだけで丸ごと読まれます。ハッシュ化したパスワードも、保存方式が弱ければ解析で元に戻されます。

利用者が最初に確かめること：届いたメールの真偽、パスワード変更、問い合わせ窓口

10月8日19時から届いた「情報流出のお詫び」メールが本物かの見分け方

skyticketは、2026年10月8日19時ごろから順次送った通知メールについて、正式に送ったものだとするお知らせを出しています。送信元は[email protected]で、件名は次の4種類です。いずれも日本語の後ろに英語の件名が続きます。

• 【重要】不正アクセスによるお客様情報流出のお詫びとパスワード変更のお願い
• 【重要】不正アクセスによるお客様情報（銀行口座情報を含む）流出のお詫びとパスワード変更のお願い
• 【重要】不正アクセスによるお客様情報流出のお詫び
• 【重要】不正アクセスによるお客様情報（銀行口座情報を含む）流出のお詫び

件名に「パスワード変更のお願い」が付くのは、パスワードを含む情報が流出した会員です。「銀行口座情報を含む」とあれば、返金先の口座情報が対象になっています。見分ける基準は送信元と中身です。同社の通知メールには、パスワードの入力を求めるリンクは載っていません。別のアドレスから届いたものや、リンク先でパスワードを入力させるものは偽物のおそれがあるため、開かずに削除してください。手口の全体像はフィッシング詐欺の仕組みと技術的な対策で解説しています。

パスワード変更が必要な約413万件と同じパスワードを使う他サービスの扱い

同社が求めているのは、会員全員のパスワード変更です。保存していたのは元に戻しにくい形に変換したハッシュ値ですが、解析でパスワードが判明し、skyticketや同じパスワードを使う他のサービスへの不正ログインに使われるおそれがあると説明しています。変更はメール内のリンクからではなく、公式サイトか公式アプリにログインして行います。

先に変えるべきは、同じパスワードを使い回している他のサービスです。skyticket側は10月7日18時ごろ、保存済みクレジットカードでの支払いとカード情報の保存機能を止めました。マイページの予約履歴とカードの利用明細も確認し、身に覚えのない予約があれば窓口へ連絡します。9月9日には会員1名のアカウントへの不正ログインが確認されており、これが現時点で同社が認める唯一の二次被害です。

返金口座とバス予約情報が流出した人に届きうる詐欺連絡の4つの型

10月9日のお詫びとお知らせは、流出した情報ごとに起こりうる被害を書き分けています。自分の件名や予約の種類に当てはまるものを確かめてください。

• 全員：同社や金融機関、航空会社、バス運行会社を装う詐欺メール、SMS、電話、郵便物
• パスワードを含む会員：解析されたパスワードによる不正ログイン
• 返金口座を含む人：返金手続きを装い、暗証番号やネットバンキングのIDを聞き出す連絡
• バス予約の閲覧対象者：乗車便や予約番号を知った第三者による変更・キャンセル・追加料金の請求

口座番号だけで預金が引き出されるわけではない、と同社は明記しています。危ないのは、口座番号を知っていることで信じさせ、暗証番号を言わせる手口です。同社は本件で利用者に金銭の支払いを求めることはないとしています。返金や補償を理由に振込、手数料、アプリのインストールを求める連絡は、すべて応じなくてかまいません。

専用電話窓口03-5224-8859の受付時間と自分が対象かを確かめる手順

同社は10月13日、本件専用の電話窓口を開設しました。電話番号は03-5224-8859、受付は平日11時〜18時です。メールは[email protected]で24時間受け付け、順次回答するとしています。10月10日にはお問い合わせの急増でメールサーバーに障害が出て、電話もつながりにくい状態だと案内されました。

対象者には電子メールで順次連絡しており、届かない人には公式のお知らせをもって案内に代えるとされています。つまり、メールが来ていないことは対象外の証明になりません。過去にskyticketで会員登録や予約をしたことがあれば、パスワード変更と予約履歴の確認は済ませておくのが確実です。不審な連絡に書かれた電話番号ではなく、上の公式番号へかけ直してください。

公式発表で整理する3件の不正アクセス：発生時期・原因・件数・流出項目の違い

管理機能・業務管理システム・バス予約完了ページの3経路を比べた一覧表

(1)は、skyticketの一部の管理機能を不正に操作され、そこから他のサーバーとクラウド上に保管していたデータへ到達された件です。流出したのは氏名（パスポート表記を含む）、生年月日、メールアドレス、電話番号、郵便番号・住所、振込時の依頼人名義、ハッシュ化したパスワードで、パスポート番号は流出していないと確認されています。(2)は業務管理システムの脆弱性が悪用され、氏名、電話番号、返金先の口座情報（金融機関名から口座名義まで）が対象です。(3)は予約完了ページがログインなしで表示できる状態で、第三者に機械的に閲覧されました。乗車便の情報や同行者の氏名まで含まれます。件数はそれぞれの単位が違い、同社は合計値を出していません。

8月3日の閲覧開始から10月13日の電話窓口開設までを発生順に並べた時系列

1. 8月3日：バス予約完了ページの閲覧が始まる
2. 9月9日：会員1名のアカウントへの不正ログイン
3. 9月20日：業務管理システムへの不正アクセス（28日に発覚）
4. 10月1日：予約完了ページの閲覧を発見し、同日修正
5. 10月2日〜4日：管理機能を起点とした不正アクセス（5日に発覚）
6. 10月7日18時ごろ：保存済みカードでの支払いとカード保存機能を停止
7. 10月8日19時ごろ：対象者へ通知メールの送信を開始
8. 10月9日：公表、個人情報保護委員会へ報告
9. 10月13日：専用電話窓口を開設

見落とせないのは、(3)の閲覧が約2か月続いていた点です。8月3日から10月1日まで、ログイン確認の無いページが外から読まれ続けていました。(2)の発覚から(1)の発生までも4日しか空いていません。1件目を見つけた時点で、同じ会社の別の入口を点検する時間はほとんど無かったことになります。

10月14日時点で公表されていない管理機能の操作方法・ハッシュ方式・脆弱性名

公表文は原因を「管理機能を不正に操作され」「脆弱性を悪用され」と書くだけで、どの認証が破られたのか、管理機能が外部から到達できたのか、どの製品のどの脆弱性かには触れていません。パスワードのハッシュ方式やソルトの有無も未公表です。本記事はこの3点を推測で補いません。以降の技術章は、公表された事実のうち実装の形が確定している(3)の予約完了ページと、ハッシュ化パスワードの保存という一般論に絞って扱います。

予約完了ページがログインなしで見えた原因：連番の予約IDと所有者確認の欠落

予約IDを1つずつ変えて読まれる仕組みとOWASPが示す対象ごとの認可チェック

予約完了ページのURLに予約番号やIDが入っていて、サーバーが「このIDの予約を見てよい人か」を確かめずに表示すると、IDを1つずつ変えて順に要求するだけで他人の予約が読めます。この種の不備がIDOR（Insecure Direct Object Reference）です。公表文の「機械的に閲覧された」という表現は、人手でなくプログラムで大量に要求された状況と整合します。ただし、IDが連番だったかどうかは公表されていません。

OWASPのIDOR防止チートシートは、利用者がアクセスしようとする対象ごとにアクセス制御を確かめるよう求めています。推測しにくいランダムなIDへの置き換えは追加の防御にすぎず、IDが複雑でも認可の確認は省けない、という位置づけです。権限昇格を含む認可の不備全般は認可バイパスの仕組みとサーバー側で止める実装で詳しく扱っています。

会員セッションと24時間の閲覧トークンで表示を絞るPythonの判定コードと実行結果

予約完了ページには、ログインした会員と、ログインせずに予約した利用者の両方が来ます。会員の予約は本人のセッションでだけ表示し、未ログインの予約は完了メールに載せた推測できないトークンと有効期限で絞る、という分け方です。トークンはPythonのsecretsモジュールで作り、データベースにはハッシュ値だけを残します。

# 予約完了ページの閲覧可否を判定する最小例（Python 3.9以上・標準ライブラリのみ）
import hashlib, hmac, secrets, time

TOKEN_TTL = 24 * 3600  # 未ログイン予約の閲覧リンクの有効期間（秒）

def new_booking(store: dict, booking_id: str, member_id) -> str:
    """予約作成時に閲覧用トークンを発行し、DBにはハッシュだけを残す"""
    token = secrets.token_urlsafe(32)
    store[booking_id] = {"member_id": member_id,
                         "token_sha256": hashlib.sha256(token.encode()).hexdigest(),
                         "issued_at": time.time()}
    return token  # 完了メールのURLにだけ載せる

def vulnerable_view(store: dict, booking_id: str) -> bool:
    """脆弱な例：予約IDが分かれば誰でも表示できる"""
    return booking_id in store

def can_view(store: dict, booking_id: str, session_member=None, token=None) -> bool:
    b = store.get(booking_id)
    if b is None:
        return False
    if b["member_id"] is not None:  # 会員の予約は本人のセッションだけ
        return session_member == b["member_id"]
    if token is None or time.time() - b["issued_at"] > TOKEN_TTL:
        return False
    digest = hashlib.sha256(token.encode()).hexdigest()
    return hmac.compare_digest(digest, b["token_sha256"])

if __name__ == "__main__":
    db = {}
    new_booking(db, "100231", member_id="m-501")
    guest_token = new_booking(db, "100232", member_id=None)
    cases = [
        ("1 脆弱版：連番の予約IDを未ログインで指定", vulnerable_view(db, "100231")),
        ("2 本人の会員セッション", can_view(db, "100231", session_member="m-501")),
        ("3 別の会員のセッション", can_view(db, "100231", session_member="m-777")),
        ("4 未ログインで連番の予約IDだけ指定", can_view(db, "100232")),
        ("5 完了メールのURL（トークン付き）", can_view(db, "100232", token=guest_token)),
    ]
    db["100232"]["issued_at"] -= TOKEN_TTL + 1  # 25時間後を再現
    cases.append(("6 期限切れのトークン", can_view(db, "100232", token=guest_token)))
    for label, ok in cases:
        print(f"{label}: {'表示' if ok else '拒否'}")

Python 3.14.6（Windows）で実行した結果です。

1 脆弱版：連番の予約IDを未ログインで指定: 表示
2 本人の会員セッション: 表示
3 別の会員のセッション: 拒否
4 未ログインで連番の予約IDだけ指定: 拒否
5 完了メールのURL（トークン付き）: 表示
6 期限切れのトークン: 拒否

1の脆弱版は、IDが存在するかどうかしか見ていません。これが「予約完了ページがログインしなくても表示できる状態」の実装上の姿です。修正版では予約IDを知っていても、本人のセッションか完了メールのトークンが無ければ表示されません。トークンをハッシュで保存しておけば、データベースが読まれてもリンクを作り直されることはありません。期限は予約の性質で決め、乗車日まで見せたいなら乗車日の翌日を期限にする設計も取れます。

約413万件のハッシュ化パスワード：解析されにくい保存方式とscryptの実装例

ハッシュ化していても「解析でパスワードが判明」するおそれがある理由

ハッシュ値から元のパスワードを直接計算で戻すことはできません。攻撃者がやるのは逆方向です。よく使われるパスワードの候補を大量に用意し、同じ方式でハッシュ値を計算して一致するものを探します。1回の計算が速い方式ほど、1秒あたりに試せる候補は増える仕組みです。ソルト（利用者ごとの乱数）が無ければ、同じパスワードの利用者がまとめて割れます。ハッシュ化と暗号化の違いはハッシュ化とは：暗号化との違いとパスワード保管の仕組みで整理しています。

skyticketが説明しているのは「解析によりパスワードが判明」するおそれがあるという一般的な注意で、方式が弱かったとは書いていません。ただ、利用者側から見れば方式は分からない以上、全員が変更するのが正しい対応です。単純な単語や使い回しのパスワードほど先に割れます。

OWASP推奨パラメータでscryptを使う保存・照合コードとmaxmemの落とし穴

OWASPのパスワード保存チートシートは、第一候補にArgon2id（メモリ19MiB・反復2・並列1が最小構成）を挙げ、使えない場合はscrypt（N=2^17・r=8・p=1、約128MiB）を推奨しています。bcryptは旧システム向けで作業係数10以上、PBKDF2-HMAC-SHA256は60万回です。scryptは追加ライブラリなしでPython標準のhashlib.scryptから使えます。

# パスワードをscryptで保存・照合する最小例（Python 3.9以上・標準ライブラリのみ）
import hashlib, hmac, os, time

N, R, P = 2**17, 8, 1           # OWASP推奨の最小構成（約128MiBを使う）
MAXMEM = 256 * 1024 * 1024      # 既定の上限では足りないため明示する

def hash_password(password: str) -> str:
    salt = os.urandom(16)
    dk = hashlib.scrypt(password.encode(), salt=salt, n=N, r=R, p=P, maxmem=MAXMEM, dklen=32)
    return f"scrypt${N}${R}${P}${salt.hex()}${dk.hex()}"

def verify_password(password: str, stored: str) -> bool:
    _, n, r, p, salt, dk = stored.split("$")
    test = hashlib.scrypt(password.encode(), salt=bytes.fromhex(salt), n=int(n), r=int(r),
                          p=int(p), maxmem=MAXMEM, dklen=len(dk) // 2)
    return hmac.compare_digest(test.hex(), dk)

if __name__ == "__main__":
    t = time.perf_counter()
    stored = hash_password("correct horse battery staple")
    print(f"保存値の先頭: {stored[:40]}...  計算 {time.perf_counter() - t:.2f}秒")
    print("正しいパスワード:", verify_password("correct horse battery staple", stored))
    print("違うパスワード:", verify_password("password123", stored))
    try:
        hashlib.scrypt(b"x", salt=b"0" * 16, n=N, r=R, p=P)
    except ValueError as e:
        print("maxmemを省略した場合:", e)

実行結果は次のとおりです。手元のWindows環境では、1回のハッシュ計算に約1.7秒かかりました。

保存値の先頭: scrypt$131072$8$1$ef07e5a161f68ce9ed33aa...  計算 1.73秒
正しいパスワード: True
違うパスワード: False
maxmemを省略した場合: [digital envelope routines] memory limit exceeded

最後の行が落とし穴です。hashlibの説明にあるとおり、OpenSSLのメモリ上限は既定で32MiBのため、推奨値のNをそのまま渡すと失敗します。ここで上限を上げずにNを下げて通すと、保存方式が弱くなります。保存値に方式とパラメータを一緒に書いておけば、将来Argon2idへ移るときも、ログインに成功した時点で新方式へ再計算する移行が可能です。1回1秒を超える計算はログイン集中時のサーバー負荷になるため、本番ではログイン試行の回数制限と合わせて調整します。

管理機能から他のサーバーとクラウドへ広がった経路：予約サイト運営者が点検する範囲

管理機能の入口を絞る4項目：公開範囲・多要素認証・権限分離・操作ログ

(1)の件は、1つの管理機能から他のサーバーとクラウド上のデータまで届きました。どう操作されたかは未公表ですが、管理機能が侵入の起点になったときに被害を広げない設計は、予約サイトの運営者なら事前に確かめられます。優先度の高い順に4つです。

• 管理機能がインターネットから直接開けないか（社内網やIPアドレス制限、VPNの内側に置く）
• 管理者アカウントに多要素認証が掛かっているか
• 管理機能の権限が、顧客データの一括取得やクラウドの保管先まで届く範囲になっていないか
• 管理機能での検索・出力・設定変更が操作ログに残り、大量取得を検知できるか

判断は言い切れます。1つ目と2つ目が両方「いいえ」なら、他の対策より先に直すべき対象です。3つ目は、管理画面の担当業務ごとに見られる範囲を分ける話で、予約サイトの管理者機能を要件書に落とす方法は予約システムの管理者機能と管理画面の要件にまとめています。逆に、社内からしか開けず利用者が数名の管理画面に、操作ログの常時監視まで求めるのは過剰です。

個人情報保護委員会への報告と本人通知：速報3〜5日・確報30日と60日の期限

skyticketは個人情報保護委員会へ報告済みとしています。個人情報保護法26条は、一定の漏えい等が起きたときに委員会への報告と本人への通知を事業者に義務づけています。個人情報保護委員会の案内では、速報は事態を知った日から3〜5日以内、確報は30日以内、不正アクセスのように不正の目的によるおそれがある場合は60日以内です。今回のように経路が複数あると、発覚日ごとに期限の起点が分かれる点に注意が要ります。

報告の段取りは個人情報保護委員会への報告義務の実務で解説しています。自社で予約サイトや会員サイトを運営する立場なら、予約確認ページの認可、管理機能の公開範囲、パスワードの保存方式を第三者の目で確かめる脆弱性診断・セキュリティ診断で点検できます。

よくある質問

skyticket（スカイチケット）の不正アクセスについて、利用者から出やすい質問をまとめました。

skyticketから届いた情報流出のメールは本物ですか？

[email protected]から10月8日19時ごろ以降に届いた、「【重要】不正アクセスによるお客様情報流出のお詫び」で始まる件名のメールは、同社が正式に送ったものと公表されています。ただし同社のメールにパスワード入力を求めるリンクはありません。別のアドレスから届いたものや入力を求めるものは開かず、パスワード変更は公式サイトか公式アプリから直接行ってください。

自分の情報が流出したかどうかはどう確認できますか？

同社は対象者へ電子メールで順次連絡しています。届かない人には公式サイトのお知らせで案内に代えるとしているため、メールが無いことは対象外の証明になりません。確かめたいときは専用電話窓口（03-5224-8859、平日11時〜18時）か[email protected]へ問い合わせます。電話は混み合っていると案内されています。

パスワードは変更したほうがよいですか？

変更してください。同社は会員全員に変更を求めており、約413万件のハッシュ化パスワードが流出しています。解析で判明するおそれがあるため、skyticketと同じパスワードを使っている他のサービスも変更の対象です。変更はメール内のリンクではなく、公式サイトか公式アプリにログインして行います。

クレジットカードやパスポートの情報は流出しましたか？

クレジットカード番号とパスポートの画像は同社が保存しておらず、流出していません。カード情報は決済代行会社が保管しています。パスポート番号は、最大の件では流出していないと確認済みで、業務管理システムの件は流出の事実こそ未確認ながら調査が続いている段階です。不正利用を防ぐため、保存済みカードでの支払いは10月7日から止められています。

返金や補償の案内が来たら応じてよいですか？

振込や手数料、アプリのインストールを求める案内には応じないでください。同社は本件で利用者に金銭の支払いを求めることはないと明言しています。補償やお詫びの品について、10月14日時点で公式の発表はありません。口座に身に覚えのない入出金があれば取引先の金融機関へ、バス予約に覚えのない変更があれば専用窓口へ連絡します。

関連記事

• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：予約完了ページの不備を一般化した解説
• ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説：ハッシュ化したパスワードが解析される前提
• Commune不正アクセス：約30.7万人漏えいの対象確認と共通署名鍵の教訓：同じ週に公表された管理者なりすましの事例
• 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：運営者として点検する範囲の全体像
• タイムズカー情報漏洩・流出：自分が対象かの確認と補償、0120-25-8924は本物か：漏えい後に届く連絡の真偽を確かめる手順