会員システムへの不正アクセスが相次ぐ――公表された事案の共通点と、JPCERT/CCが示した手口、いま確認す⁠る⁠こ⁠と

2026年9月から10月にかけて、会員やアプリの利用者向けのシステムへの不正アクセスと、それによる個人情報の漏えいが、相次いで公表されています。1000万件を超えるものもあります。JPCERT/CCは、10月8日に、国内の組織への不正アクセスについて注意喚起を出し、10月23日にも内容を更新しました（JPCERT-AT-2026-003⁠0⁠）⁠。

この記事は、利用者向けのシステムを運営している事業者と、その担当者向けに、公表された事案、JPCERT/CCが示した手口、いま確認すべきことを整理したものです。出典は、各記述のそばに示しています。公表の段階では、原因が調査中の事案が多く、事案ごとの原因を、手口に当てはめて断定することはできません。この記事でも、そのような当てはめはしません。情報は、日本時間2026年10月25日の時点のもの⁠で⁠す⁠。

要点

• 今回の事案の多くは、会員管理システムやアプリのアカウントサービスへの不正アクセスで、件数は約90万件から、1000万件を超えるものまであり⁠ま⁠す⁠。
• 漏えいが公表された項目は、氏名、メールアドレス、電話番号が中心です。多くの事案で、ログインパスワードやクレジットカード番号は、含まれていないとされています。ただし、これらの情報は、フィッシングやなりすましに悪用される可能性があり⁠ま⁠す⁠。
• 公表の時点で、原因が特定されていない事案が多くあります。私が確認した範囲では、共通の原因や、同じ攻撃者によるものだという公式の発表は、見つかりませんで⁠し⁠た⁠。
• JPCERT/CCは、確認されている手口を5つ示しています。既知の脆弱性の探索、API経由の不正操作、Metabaseの脆弱性、Webシェルの設置、AIペネトレーション基盤の悪用⁠で⁠す⁠。
• JPCERT/CCは、一般の利用者向けのアプリだけでなく、BIツールや従業員向けの管理システムも、点検の対象にするよう求めてい⁠ま⁠す⁠。

公表された主⁠な⁠事⁠案

各社の公表と、報道にもとづく整理です。件数は、公表された数字をそのまま書いています。原因の欄は、公表されている範囲⁠で⁠す⁠。

件数は、記録の件数です。重複を除いた人数とは限りま⁠せ⁠ん⁠。

共通して言え⁠る⁠こ⁠と

次の3点は、私見⁠で⁠す⁠。

• 対象は、会員、アプリ、予約など、利用者が直接使うシステムです。多くの個人情報が、1つのシステムに集まっているため、1回の侵入で、件数が大きくなり⁠ま⁠す⁠。
• 検知や公表は、早い事案が多くあります。例えば、焼肉きんぐは、不正アクセスの確認の3日後に公表しています。一方で、原因や侵入経路は、公表の時点で、分かっていないことが多いのが実情⁠で⁠す⁠。
• 漏えいしたのが氏名、メールアドレス、電話番号であっても、フィッシングやなりすましには、十分に使えます。パスワードが含まれないことは、被害が小さいことを意味しま⁠せ⁠ん⁠。

JPCERT/CCが示した5つ⁠の⁠手⁠口

JPCERT/CCの注意喚起は、確認されている攻撃を、次の5つに整理しています。この注意喚起は、上の個別の事案と結びつけてはいま⁠せ⁠ん⁠。

• ケースA（既知の脆弱性の探索）：標的ごとに、さまざまなソフトウェアの既知の脆弱性をスキャンして、悪用を試みます。脆弱性ではなく、機器の管理不備を突く攻撃もあり、環境設定ファイルやバックアップファイルの窃取が、例に挙げられて⁠い⁠ま⁠す
• ケースB（API経由の不正操作）：一般に公開しているスマートフォンアプリを解析して、APIのエンドポイントやキーを特定し、画面操作では実行できない内部のAPIを狙います。ユーザー権限の変更、不正なアカウントの作成、NoSQLインジェクションによるアカウント情報の特定などが、挙げられています。ほかのシステムから窃取したAPIキーが使われることもあ⁠り⁠ま⁠す
• ケースC（Metabase）：SQLインジェクションの脆弱性（CVE-2026-72898）が、APIへの不正なリクエストで悪用されています。JPCERT/CCは、8月14日に、この脆弱性について、別の注意喚起を出して⁠い⁠ま⁠す
• ケースD（Webシェルの設置）：公開Webサーバーからアクセスできるアプリケーションサーバーに、悪意のあるJSPを含むWARファイルが置かれた事例があ⁠り⁠ま⁠す
• ケースE（AIペネトレーション基盤の悪用、10月23日に追加）：Cairn、CyberStrikeAI、ARTEXなどが悪用され、インターネットに公開されたWebアプリケーションや、WSUSサーバーが狙われて⁠い⁠ま⁠す

JPCERT/CCは、不審な送信元のIPアドレスの一覧も、ページに載せています。自組織のログに、これらのIPアドレスからのアクセスがないかを確認するよう、勧めています。ただし、一部は正規の利用の可能性があり、Tor出口ノードや、レジデンシャルプロキシ経由のアクセスも確認されているため、IPアドレスだけで判断せず、ほかの指標と組み合わせるよう、注意してい⁠ま⁠す⁠。

いま確認す⁠る⁠こ⁠と

JPCERT/CCが示した対策を軸に、確認の順序にしま⁠し⁠た⁠。

今日の⁠う⁠ち⁠に

1. 利用者向けのシステム（会員、アプリ、予約、ポイント）を一覧にします。それぞれが、誰の、どんな個人情報を、何件、持っているかも書⁠き⁠ま⁠す
2. 一般の利用者に使われるはずのないAPI、管理機能、BIツール、従業員向けのシステムが、インターネットに公開されていないか確認します。JPCERT/CCは、業務上不要なサービスや管理機能が公開されている場合は、公開を止めるよう求めて⁠い⁠ま⁠す
3. 使っているミドルウェアや製品に、既知の脆弱性がないか確認します。例えば、Metabaseを使っている場合は、JPCERT/CCの注意喚起を確認⁠し⁠ま⁠す

今週の⁠う⁠ち⁠に

4. APIに、リクエスト件数の制限をかけます。ログイン、パスワードのリセット、SMSの送信、検索など、悪用のリスクが高い機能には、個別に回数の制限を設けます（JPCERT/⁠C⁠C⁠）
5. 非公開のAPIを含む、すべてのエンドポイントで、アクセス制御を行います。APIの利用者とトークンには、必要最小限の権限だけを与えます。トークンには有効期限を設け、漏えいが疑われるトークンは、すぐに無効にできるように⁠し⁠ま⁠す
6. JPCERT/CCの一覧のIPアドレスについて、自組織のログを確認します。見つかった場合は、それだけで判断せず、ほかのログとあわせて調⁠べ⁠ま⁠す
7. 不正なアクセスを検知する体制と、検知したときの初動の手順を、点検します。大量のアカウント情報の取得や、短時間の繰り返しアクセスに、気づける状態かを確認⁠し⁠ま⁠す

今月の⁠う⁠ち⁠に

8. 保存期間を過ぎたデータや、利用目的を終えたデータを、消します（JPCERT/CC）。持っていない情報は、漏れ⁠ま⁠せ⁠ん
9. 漏えいが起きたときに、利用者へ二次被害の防止を呼びかける準備をします。多要素認証の利用や、なりすましメールへの注意の案内を、すぐに出せるようにしておきます（JPCERT/⁠C⁠C⁠）
10. 開発会社や委託先との役割を、確認します。誰が、どのシステムの更新、ログの監視、初動を担当するかを、決めておきます。例えば、焼肉きんぐは、開発会社や関係会社と連携して、対策を強化するとしています（ビジネス+⁠I⁠T⁠）

利用者の側ででき⁠る⁠こ⁠と

11. 今回の事案で、メールアドレスや電話番号が漏れた可能性がある場合は、各社を装ったメール、SMS、電話に注意します。会社が、メールやSMSで、パスワードやカード情報を尋ねることはない、とタイムズカーは案内しています（タイムズ⁠カ⁠ー⁠）
12. パスワードを使い回している場合は、変更します。多要素認証が使えるサービスでは、有効に⁠し⁠ま⁠す

未確⁠認⁠の⁠点

• 各事案の原因は、公表の時点で、特定されていないものが多くあります。この記事は、原因を推測してい⁠ま⁠せ⁠ん
• タイムズカーの原因は、第3報のページに記載がなく、確認できていません。第3報には、2週間程度をめどに、改めて案内するとあ⁠り⁠ま⁠す
• ローソンアプリ予約の件数は、報道ごとに異なり、確定した数字を確認できてい⁠ま⁠せ⁠ん
• GMOリサーチ&AIの原因（ソフトウェアの脆弱性）は、報道にもとづく情報です。同社の発表の原文は、確認できてい⁠ま⁠せ⁠ん
• バーガーキングは、報道（Impress Watch）にもとづきます。同社の発表の原文は、確認できてい⁠ま⁠せ⁠ん

関⁠連⁠記⁠事

• GitLabの深刻な欠陥は、2件ある――10月12日の修正版では足りない理由と、確認すること：自社で運用しているGitLabの欠陥。更新の確認と、侵害⁠の⁠確⁠認
• 不正アクセスが相次ぐ今、経営者が先に決めておくこと――ゼロトラストとAI時代のセキュリティ対策：経営者が、先に決めてお⁠く⁠こ⁠と
• アメリカでサイバーセキュリティの資格を取る道筋――段階ごとの試験と、受験料・学習費用（2026年10月時点）：資格を取って、この種の事案に備えたい人向けの、アメリカでの道筋。段階ごとの試験と、受験料・学⁠習⁠費⁠用

会員システムやAPIの点検、公開範囲の棚卸しでお困りの方は、下記よりお問い合わせくだ⁠さ⁠い⁠。