サイト経由型のサイバー攻撃はなぜ急増？会員情報が抜かれる仕組みを解説｜ソースネクスト・スカイチケットの公表から

不正アクセスと聞くと、会社の社内ネットワークに誰かが入り込む場面を私は思い浮かべていました。10月28日に時事通信が伝えた内容は、その想像とは違いました。外部から使えるウェブサイトやアプリのシステムを経由した攻撃が急増している、という報道です。セキュリティー大手マクニカ（横浜市）によると、情報流出やその恐れが公表された事案は今年すでに216件で、昨年1年間の2.6倍になっています。

この記事では、時事通信の報道、ソースネクストとスカイチケットの公表文、IPA（情報処理推進機構）とOWASPの資料をもとに、サイト経由型の攻撃がなぜ会員情報に届くのか、認証と認可の違い、運営側と会員側がそれぞれ確認できることを整理します。2026年10月時点の情報で、両社の調査は続いています。

• サイト経由型の攻撃は、社内ネットワークに入らず、公開されたサイトやアプリの弱点を直接突く
• 公表数は今年216件で昨年の2.6倍、10月だけで26日までに101件
• 他人の情報が見える原因の代表は、ログイン確認だけで終わり「本人のデータか」を確かめない実装
• 会員側は、パスワードの使い回しをやめ、不審な連絡に注意する

サイト経由型の攻撃は、社内ネットワークに入らずに弱点を突く

時事通信が伝えた数字：216件、2.6倍、10月だけで101件

時事通信によると、マクニカの集計では、情報流出やその恐れが公表された事案は今年すでに216件で、昨年1年間の2.6倍です。公表数は今年の夏以降に急増し、10月だけで26日までに101件に上りました。

2.6倍という数字から昨年1年間の件数を逆算すると、216÷2.6で約83件です。今年の10月26日までの101件は、昨年1年間の公表数を1か月足らずで超えた計算になります（計算は私によるもので、マクニカの公表値ではありません）。

10月だけの101件を26日で割ると、1日あたり約3.9件です。10月の26日間のうち、毎日平均で4件近い公表があった計算です。

サイト経由型の攻撃の特徴

時事通信は、サイトやアプリを通じた攻撃の特徴を、企業の内部ネットワークに侵入しなくてもシステムの弱点を直接突ける点だと伝えています。正規会員としてログインし、本来は見られない他人の情報を表示させようとするケースがあるそうです。

標的も広がっています。これまで多かったのは電子商取引（EC）サイトですが、会員向けサイトや予約サービスにも広がり、図書館の蔵書検索、観光列車の座席予約、大学の施設予約でも、情報流出やその恐れが確認されたと報じられています。

私は、会員登録だけして使わなくなったサイトをいくつも持っています。図書館の蔵書検索や予約サービスのような、お金を扱わないサイトほどそうです。攻撃される側として意識したことがなかった、というのが正直なところです。

共通ソフトの更新で直る弱点と、直らない弱点

時事通信は、サイト固有の脆弱性は共通ソフトの更新だけでは解消できない、というマクニカの瀬治山豊氏の指摘も伝えています。企業ごとに欠陥の洗い出しと修正が必要だという意見です。

ここが、これまでの脆弱性のニュースと違う点です。たとえばPHPの重大な脆弱性でパッチ適用が急がれる理由の記事で扱ったように、多くのサイトが使う共通ソフトの欠陥は、開発元が修正版を出し、各サイトが更新すれば塞がります。一方、サイトの作り込みの中にある欠陥は、そのサイトの運営者しか直せません。サイト経由型の攻撃が突くのは、主に後者です。

ソースネクストとスカイチケットで、何が起きたか

ソースネクスト：会員情報取得APIの不正利用

ソースネクストの公表文によると、同社は2026年10月13日9時ごろ、会員情報を管理するシステムへの不正アクセスを確認し、13時36分までに封じ込めを完了しました。その後の調査で、第三者が10月9日10時ごろから会員情報取得APIを不正に利用し、登録者の情報を取得したことが分かったと説明しています。

流出した可能性のある件数は22,519,960件です。対象の情報には、メールアドレス、パスワード、氏名、住所、電話番号、生年月日などが含まれます。ただし公表文は、これが可能性のある全項目であり、すべての人についてすべての項目が流出したわけではないと断っています。クレジットカード情報は対象システムに保存されておらず、流出の対象には含まれていないとのことです。

不正アクセスの開始は10月9日10時ごろ、同社が確認したのは10月13日9時ごろです。ほぼ4日間、気づかれないまま取得が続いた計算になります。

API（アプリケーション・プログラミング・インターフェース）は、サイトやアプリが裏でデータをやり取りするための窓口です。画面にはボタンが並んでいますが、裏ではAPIにデータを要求する通信が流れています。公表文は、このAPIが不正に使われたと述べるだけで、どの種類の欠陥が使われたのかは書いていません。

スカイチケット：経路の違う3件

スカイチケットを運営するアドベンチャーの公表文（2026年10月9日付）は、本件を「それぞれ異なる経路による3件の不正アクセス」と整理しています。内容は次の表のとおりです。

3件目のバス予約は、発生期間の8月3日から発覚日の10月1日まで59日間です（8月3日から9月3日が31日、9月3日から10月1日が28日）。ログインが要るはずのページが、その間ずっと開いていたことになります。

1件目のパスワードについて、公表文は、元に戻すことが困難な形（ハッシュ化）に変換して保存していたものの、解析によりパスワードが判明したため、同じパスワードを使う他のサービスへの不正ログインに悪用されるおそれがある、と説明しています。

他人の情報が見える仕組み：認証と認可の違い

認証は「誰か」を確かめ、認可は「見てよいか」を確かめる

サイトのログインには、2つの確認が重なっています。1つ目は認証で、パスワードなどを使って、ログインしようとしている人が登録者本人かどうかを確かめます。2つ目は認可で、本人と確認できた人に、そのデータを見てよい、その操作をしてよいという権限があるかを確かめます。

元IT企業の広報だった私は、開発の会議で「認可」という言葉が出るたびにうなずいていましたが、認証との違いを人に説明できるようになったのは、後から調べ直してからです。認証だけが正しく動いていると、サイトは「この人は会員です」とは言えても、「この人にこの画面を見せてよい」とは言えません。

URLの番号を差し替えると、他人の注文が見える

IPAの「安全なウェブサイトの作り方」は、認可制御の欠落の例を2つ挙げています。1つ目は、利用者IDがURLやPOSTのパラメータに埋め込まれている画面です。その値でデータベースを操作する実装だと、ログイン中の利用者が他人になりすまして操作できてしまいます。2つ目は、注文番号がURLやPOSTのパラメータで与えられる実装です。他人用に発行された注文番号を指定すると、他の利用者にしか閲覧できないはずの注文情報を見られる脆弱性が生じることがあります。

IPAが示す根本的な解決は、認証に加えて認可制御の処理を実装することです。具体的には、検索に使う利用者IDがログイン中の利用者IDと一致するかを常に確認する、利用者IDを外から与えられるパラメータではなくセッション変数から取得する、といった方法が挙げられています。

画面で隠していても、直接呼び出せば見える

OWASP（ウェブアプリケーションのセキュリティを扱う国際的な非営利団体）の「Top 10:2025」は、A01として「アクセス制御の不備」を1位に挙げています。同じ資料の攻撃例の3つ目は、アクセス制御をすべて画面側（フロントエンド）に置いたアプリケーションです。ブラウザ上のプログラムが管理者ページへの移動を止めていても、攻撃者がコマンドラインから同じURLを直接呼べば、止められません。

時事通信が伝える「サイトの弱点を探索する」という手口は、画面のボタンを押す人間ではなく、この種の直接の呼び出しを機械的に試していく動きだと私は理解しています。画面には自分のデータしか出ない作りでも、裏の窓口が他人のデータも返せる状態であれば、開発中のテストでは見つかりにくいからです。ただし、ソースネクストとスカイチケットの個別の原因が、これに当たると公表されたわけではありません。

AIが「手間に見合わない」攻撃を変えた

政府の分析と、確認できていないこと

時事通信によると、サイトごとに弱点を探すには手間やコストがかかるため、これまでは目立っていなかったものの、高性能の人工知能（AI）を使うことで探索が容易になっているとみられています。政府が10月26日に開いたサイバーセキュリティーに関する関係閣僚会議では、攻撃者がウェブシステムを網羅的に調べて侵入口を探し、個人情報を短時間で盗み出す手口が広がっているという分析が報告されました。政府関係者は、AIが使われている可能性が高いとの見方を示しています。

ここで確認できているのは「可能性が高いとの見方」までで、個々の事案でAIが使われたと確定した情報は、私が確認した公表文の中にはありません。この記事でもAIの関与は断定せず、報道の表現のまま扱います。

お金を扱わないサイトは、対策が後回しになりやすい

EGセキュアソリューションズの徳丸浩取締役は、時事通信の取材に、機密情報や金銭を扱わないサイトでは安全対策が後回しになりがちだと指摘しています。AIの進化によって、従来は手間に見合わなかった攻撃も容易になり、「攻撃と防御のパワーバランスが崩れた」という見方です。

この指摘は、先ほど私が自分の会員登録について書いたことと重なります。図書館の蔵書検索や大学の施設予約は、お金を扱わず、機密とも思われにくいサイトです。ただし会員として登録していれば、氏名やメールアドレスは保存されています。サイトの重要度が低く見えても、置かれている個人情報の価値は、サイトの性格では決まりません。

運営側が見直す点：OWASPが挙げる防ぎ方

サーバー側で毎回確かめ、公開するもの以外は拒否する

OWASPの「アクセス制御の不備」のページは、防ぎ方の最初に、アクセス制御は改ざんできないサーバー側のコードやサーバーレスのAPIで実装して初めて有効になる、と書いています。続けて、公開するリソースを除いて、原則として拒否する（deny by default）ことを求めています。

画面側だけで制限しない、許可していないものは通さない、という2点は、先に見た「画面で隠していても直接呼べば見える」という弱点への直接の答えです。

失敗を記録し、回数を制限する

同じ資料は、アクセス制御の失敗を記録し、繰り返される場合などには管理者に警告すること、そして、自動化された攻撃ツールの被害を小さくするため、APIへのアクセスに回数制限（レート制限）をかけることも挙げています。ソースネクストで不正アクセスの開始から確認までにほぼ4日かかったことを考えると、機械的な大量の呼び出しに気づく仕組みの有無が、被害の大きさを左右するのかもしれません。これは私の推測で、同社の公表文に書かれた内容ではありません。

アクセス制御をテストに入れる

OWASPは、開発者と品質保証の担当者が、アクセス制御の機能を単体テストと結合テストに含めるべきだとも書いています。画面から操作するだけの確認では、他人のIDを指定した場合の動きまでは確かめにくいからです。OWASPの資料では、今回の2025年版の集計で、テストされたアプリケーションのすべて（100%）に、何らかのアクセス制御の不備が見つかったとされています。

会員として確認したいこと｜判断基準は3つ

同じパスワードを複数のサイトで使っていないか

ソースネクストの公表文は、流出した可能性のあるメールアドレスとパスワードの組み合わせを使って、第三者が他のサービスへのログインを試みるおそれがあるため、同じ組み合わせを他のサービスでも使っている場合はそちらも変更するよう求めています。スカイチケットの公表文も、同じパスワードを使っている他のサービスの変更をお願いしています。

パスワードをサービスごとに変える、それが負担ならパスワード管理の仕組みやパスキーを使う、という方向になります。パスキーの仕組みはパスキーはなぜパスワードより安全なのかの記事で説明しています。

不審なメールやSMSには、記載のリンクから入らない

両社とも、流出した情報が悪用され、会社や金融機関を装った不審なメール、SMS、電話、郵便物が届くおそれがあると注意しています。スカイチケットは、記載されたリンクや電話番号にはアクセス・連絡せず、案内された窓口に連絡するよう求めています。

使っていない会員登録を整理する

これは公表文に書かれた内容ではなく、私の判断です。サイト経由型の攻撃は、どのサイトに弱点があるかを会員側が知る方法がありません。そのため、使っていないサイトの会員情報を残さないことが、会員側でできる数少ない備えになると考えています。退会の方法はサイトごとに違うので、退会できるかどうかは各サイトの案内で確認してください。

情報が漏れたとき、企業が誰に何を報告するのかは、個人情報が漏えいしたら企業は誰に何をいつまでに報告するのかで整理しています。

デメリットと注意点：公表された数字から言えないこと

「216件」は流出の「疑い」を含む件数

時事通信は、216件を「情報流出やその恐れが公表された事案」と書いています。実際に流出が確認された件数ではありません。また、これはマクニカの集計であり、公表されていない事案は含まれません。件数の増加は、攻撃が増えたことと、企業が公表するようになったことの両方を反映している可能性があります。この点は、報道の記載からは分けられません。

AIが使われたかどうかは、見方の段階

先に書いたとおり、AIの関与は政府関係者の「可能性が高い」という見方です。AIを使った探索が増えているとしても、会員側にできることは、AIが使われていない場合と変わりません。

ソースネクストの欠陥の種類は公表されていない

ソースネクストの公表文は、会員情報取得APIが不正に利用されたと書いていますが、認可制御の欠落だったのか、別の欠陥だったのかは書いていません。この記事の認証と認可の説明は、IPAとOWASPの資料にある一般的な仕組みであり、同社の原因を特定するものではありません。

よくある誤解

ログインが必要なサイトなら、他人の情報は見られないのですか

見られないとは限りません。ログインは認証にすぎず、他人のデータを見てよいかを確かめる認可が別に必要です。IPAは、ログイン中の利用者が他人になりすませる実装を、認可制御の欠落として例示しています。スカイチケットのバス予約のように、そもそもログインを求めていなかったページが開いていた例もあります。

パスワードを暗号のような形で保存していれば、流出しても安全ですか

安全とは言い切れません。スカイチケットの公表文は、ハッシュ化して保存していたパスワードでも、解析により判明したと説明しています。ソースネクストも、流出した可能性のある情報にパスワードを含めています。

お金を扱わないサイトなら、狙われにくいですか

時事通信の報道では、図書館の蔵書検索、観光列車の座席予約、大学の施設予約でも流出やその恐れが確認されたとされています。徳丸氏が指摘するように、お金を扱わないサイトは対策が後回しになりがちで、そこに弱点が残る可能性があります。

まとめ：サイト経由型の攻撃が会員情報に届く仕組み

サイト経由型の攻撃は、社内ネットワークに入らず、外に公開されたサイトやアプリの弱点を直接突きます。今年の公表数は216件で昨年の2.6倍、10月は26日までに101件です。急増の背景として、政府関係者はAIによる弱点探索の可能性が高いとみています。

他人の情報が見えてしまう典型的な原因は、ログインの確認（認証）だけで終わり、本人のデータかどうかの確認（認可）が抜けていることです。サイト固有の欠陥なので、共通ソフトの更新では直らず、運営側がサーバー側で毎回確かめる実装に直す必要があります。

会員側は、パスワードの使い回しをやめること、不審なメールやSMSのリンクから入らないこと、使っていない会員登録を残さないことの3点を確認できます。両社の調査は続いており、原因や被害の範囲は今後の発表で変わる可能性があります。最新の情報は各社の公式発表で確認してください。