GETTIISで会員情報流出を公表｜パスワード変更と主催者側の確認点

リンクステーションは2026年10月19日、主催者向け公演登録サービスGettii-Liteへの不正アクセスにより、購入者向けサービスGETTIISの会員情報が外部へ流出したと公表しました。対象となる利用者の範囲や件数、項目ごとの影響は引き続き調査中です。流出の確認と、すべての登録情報の流出が確定したことを混同しないようにしましょう。

今回の発表で利用者が確認したいのは、パスワード変更の案内と、同じパスワードを使っている別サービスへの対応です。一方、チケットを販売する主催者やWeb運営者には、購入者への案内、外部サービスとの役割分担、復旧確認を整理する課題があります。

本記事の公表日情報は10月19日の第一報に基づき、情報確認日は日本時間10月20日です。不審なアクセスを確認した日は10月18日と説明されています。以下の事案説明は公式公表に基づき、後半の点検・運用手順は本サイトからの提案として区別します。

第一報で確認されたことと調査中のこと

公式発表によると、第三者が10月18日未明にGettii-Liteのプログラムの脆弱性を悪用したとされています。GettiiおよびGettii-ECは異なる環境で運用されており、本件の影響は確認されていないという説明です。

対象情報として氏名・連絡先などの会員情報、ハッシュ化パスワード、カード番号の一部と暗号化された名義・有効期限の情報が挙げられています。完全なカード番号とセキュリティコードは保存していないとしています。個々の利用者で対象となる項目は異なるため、全会員の全項目が漏れたとは書けません。

同社は対象サーバーの切り替えと脆弱性への対策を完了し、確認内容に基づいて対象者へ順次連絡すると案内しています。今回確認した第一報には、CVE、脆弱性の具体的な種類、攻撃者やAIの関与を確定する技術情報はありません。

リンクステーション：GETTIIS会員情報漏えいのお知らせ（第一報・2026年10月19日）

ハッシュ化されていても変更の案内を確認する

ハッシュ化されたパスワードは、平文のパスワードと同じものではありません。ただし、ハッシュ化という言葉だけでは、保存に使われた方式や設定、元のパスワードの強さまで分かりません。今回の第一報から、復元の難しさを数値で断定することはできません。

一般論としてOWASPは、パスワード保存に適した低速なハッシュ方式とソルトなどの対策を説明しています。ハッシュを取得された場合にも、候補のパスワードを計算して照合する攻撃を考慮する必要があります。これは仕組みの説明であり、GETTIISでどの方式が使われたかを示すものではありません。

OWASP：Password Storage Cheat Sheet

利用者は変更先と変更手順を分けて考える

本サイトからは、まず普段から利用している正規のサイトや公式のお知らせから最新の案内を開くことを勧めます。メールの本文だけを見て変更ページへ進むと、事案に便乗した偽の案内と区別しにくくなります。

GETTIISの第一報はパスワード変更を求め、変更手順は改めて案内するとしています。本記事では未確認の変更画面や操作手順を作らず、公式ページの追加案内を確認するようお伝えします。同じパスワードを別のサービスへ使っている場合の変更も、同社が呼びかけている対応です。

自分で対応を整理する際は、使い回しているサービスを一覧にし、特にメールなど他のアカウントの再設定に関わるものを確認します。それぞれの正規の設定画面から固有のパスワードへ変更し、利用できる追加の認証手段があれば、そのサービスの公式手順で検討してください。

便乗した連絡への対応を決めておく

流出事案の案内は、利用者に急いで行動してもらう必要があります。その一方で、急がせる文面は偽の連絡にも使われます。氏名や利用したサービス名が書かれているだけで、連絡元が本物と判断しないことを提案します。

第一報は不審なメール・SMS・電話への注意を促し、メールや電話でパスワード、カード番号、暗証番号を尋ねないと説明しています。対応が必要か迷ったときは、その連絡で示された経路だけに頼らず、公式ページから確認します。

問い合わせを受ける主催者側でも、利用者からパスワードやカード情報を聞き取る運用を作らないでください。本人確認や予約の照合に必要な情報がある場合も、サービスの正式な手続きと主催者の担当範囲を確認し、過剰な情報を集めないことが重要です。

主催者は公演の案内と個人情報の案内を分ける

ここからは、チケットサービスを利用する主催者向けの本サイトの提案です。利用者は、情報流出の影響だけでなく、購入済みのチケット、発券、当日の入場、今後の販売についても不安を持つ可能性があります。しかし、今回の第一報だけでは個々の公演の運用まで確定できません。

主催者は、自分たちの販売経路や公演がどのサービスを使っているかを確認し、チケットの取り扱いはサービス提供元の案内と契約上の担当範囲を照合します。別のシステムであるという説明だけで、自分の公演への影響を一律に結論づけないでください。

お知らせには、現在確認できること、確認中のこと、次の更新先を分けて書きます。「公演は予定どおり」といった案内も、主催者が実際に確認できた範囲で示します。個人情報に関する問い合わせを受けた場合の連絡先も決め、回答者ごとに違う説明にならないようにします。

外部サービスを使う運営者は接続と保管を棚卸しする

主催者向けの機能と購入者向けの会員情報は、利用者から見れば別の画面です。今回、どの内部経路で影響が広がったかの詳細は公開されていません。特定のデータベース共有や権限不備を原因と断定せず、自社の点検へ応用する範囲を明確にします。

本サイトでは、チケットの登録、購入、通知、問い合わせ、集計といった業務ごとに、保存する情報と外部への受け渡し先を書き出すことを勧めます。サービス本体に加え、CSVで出力した名簿、メール添付、別の管理ツールへ取り込んだデータも対象です。

どこに個人情報が残っているか分からなければ、事故時に調べる範囲や利用者へ説明する内容も決まりません。誰が何の目的で出力し、いつ削除するかを確認します。ただし、事故調査に必要な証拠まで通常の削除手順で消さないよう、保管期間の運用とインシデント対応は調整してください。

管理機能に必要な操作だけを許可する

OWASPの認可に関する資料は、最小権限、既定での拒否、必要な権限の整理と検証を推奨しています。ログインできることと、個々のデータを読む・変更する権限があることは別です。

OWASP：Authorization Cheat Sheet

自社で点検する場合の具体例

説明用の仮想例として、公演登録担当者が作品名や販売期間を編集する管理機能を考えます。業務に不要な購入者の認証情報まで取得できないか、公演や主催者の識別子を変えると別の情報へ届かないかを、許可された検証環境で確認します。これは今回の脆弱性を再現する手順ではありません。

正常な担当者の操作が成功するだけでは、権限制御の検査は終わりません。別の主催者、権限を外された担当者、未認証の利用者など、拒否すべき条件を試します。画面でボタンを隠すだけでなく、サーバー側で該当する操作を拒否することを確認します。

検査の結果は、入力、利用者の条件、対象データ、期待する許可・拒否、実際の結果として記録します。画面やAPIが増えたときにも同じ境界を守れるよう、重要な拒否条件を自動テストへ残すことを提案します。

対策の完了と被害範囲の確定は別の判断

公式発表の「対策を完了した」という説明を、調査対象や漏えい件数まで確定した意味に広げないことが必要です。侵入経路への対応と、過去に何が取得されたかの調査では、確認する資料も終了条件も異なります。

自社がサービスを運営する場合は、修正した入口、適用した環境、再現確認の結果を記録し、影響範囲の調査とは分けて管理することを提案します。ログが残っていない期間や、確認できない項目も明示します。証拠がないことを、そのまま無被害と扱わないためです。

利用者への案内も、調査が終わるまで何も出せないわけではありません。確認済みの事実と、先に取れる行動を分けると、未確定の件数を推測で埋めずに説明できます。後から情報が変わった場合に、いつどの説明を更新したか追える形にします。

問い合わせ対応で二次的な情報の蓄積を増やさない

不安を感じた利用者が、予約画面の画像やカードの写しを問い合わせへ添付する場合も考えられます。主催者やサポート担当者は、必要以上の情報を送らない案内と、誤って届いた機密情報の取り扱いを決めることを提案します。

問い合わせをそのまま複数の担当者へ転送したり、アクセス制限のない表へまとめたりすると、対応のために新たな個人情報の複製が増えます。案件の管理には識別子や必要最小限の記録を使い、原文を見られる担当者を絞ります。

外部のAIで問い合わせ文を要約する場合にも、入力できる情報、保存や再利用の条件、組織の許可を確認します。今回の事件でAIが使われたという説明ではなく、事故対応の補助ツールを使う際の一般的な確認事項です。

次に確認する情報を決めておく

GETTIISを利用する人は、公式ページの追加案内、パスワード変更の手順、対象者への個別連絡を確認してください。主催者は、利用しているサービスの範囲と公演運用への影響を提供元へ照合し、未確認の内容を確定事項として案内しないことが大切です。

第一報では、対象人数、個別項目の影響範囲、脆弱性の詳細が未確定です。本記事は10月20日に読んだ資料の整理であり、その後の調査結果を継続確認済みとするものではありません。最新の状況は記事末尾の公式発表で確認してください。

Web運営の実務では、利用者が取る行動、主催者が案内する内容、システム側が検証する範囲を分けると、事故対応の担当が明確になります。公表情報の精度を保ちながら、先にできる対策を進めることが今回の確認の要点です。