相次ぐ不正アクセスにJPCERT/CC・NCO・IPAが一斉に注意喚起

概要

• 9月前後から国内で大量の個人情報漏えいの公表が続いたことを受け、10月7日から9日の3日間で、個人情報保護委員会、JPCERT/CC、警察庁、NCO、総務省、経済産業省、IPA、金融庁が相次いで注意喚起を出した。
• 技術的に最も踏み込んだのはJPCERT/CCで、既知の脆弱性の探索、管理用APIの悪用、Metabaseの脆弱性、Webシェル設置の4類型と、侵害調査に使える送信元IPアドレスやUser-Agentを公開した。
• 共通する一つの脆弱性は見つかっておらず、各機関の求める対策は「外部公開しているものの点検」「APIとアカウントの権限の見直し」「持っているデータを減らす」「ログを見る」に集約される。

この記事では、公式発表・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。確認できなかった情報は書いていません。

何が起きたか（時系列）

発表内容の整理

JPCERT/CC（10月8日公開・9日更新）

事実（JPCERT/CCの注意喚起）

• User-Agentの例として、ケースBでは curl/7.88.1、python-requests/2.34.2、Chrome 126を名乗るMacのブラウザ文字列、ケースCでは python-requests/2.33.1、Metabase-GHSA-vwf4/2.0 を挙げている。ケースB・CのIPアドレスには「調査時点では正規利用されている可能性もあります」との注記がある。
• 被害はスマートフォンアプリなど一般向けのシステムに限らず、BIツールや従業員向け管理システムなど、不特定多数のアクセスを想定していないシステムでも起きているとしている。
• 対策として、APIの単位時間あたりのリクエスト件数の制限、ログイン・パスワードリセット・SMS送信・検索など悪用リスクの高い機能への個別の制限、非公開APIを含む各エンドポイントでのアクセス制御、APIトークンの最小権限と有効期限、漏えいが疑われるトークンの速やかな無効化を挙げる。汎用的な対策として、アクセス元の地域制限、既知の脆弱性の修正、侵害後の横展開対策の見直し、不要な管理機能の公開停止、保存期間を過ぎたデータを残さないことなどを挙げる。

国家サイバー統括室（10月9日）

事実（NCOの文書）

• 「ウェブシステムに係る脆弱性の悪用、サプライチェーンを通じた侵害、堅牢さを欠くデータ管理など」により、大量の個人情報を扱う事業者等の情報システムが侵入され、個人情報を含むデータが窃取される事案を複数確認しているとした。
• 対策の柱は3つ。(1)ウェブシステム等の適切な管理（脆弱性の管理、多要素認証やアカウント管理、ログの取得・監視などのレジリエンス）、(2)サプライチェーンを通じた侵害への対策（委託先の対策状況の把握、委託契約のセキュリティ要件、委託先への提供情報の最小化と業務終了後のデータ削除、サプライチェーン全体のリスク管理）、(3)データの適切な管理（情報資産の把握、保有情報の最小化、閲覧権限と更新権限の分離、保存データの暗号化、クラウドの保存領域やデータベースの公開設定・アクセス権限の確認、アクセスログの点検）。
• 「必要以上の権限が付与されている場合、不正アクセス時に大量の情報が一度に取得されるおそれがあります」「万が一情報漏えいが発生した場合でも、保有する情報が少なければ被害の拡大を抑えることが可能です」と書いている。
• 経営層に対し、AIの悪用を含む攻撃手法の高度化を挙げて、対策を経営課題と位置づけるよう求めた。被害組織には、技術的な情報をNCOや所管省庁、専門機関等に速やかに共有するよう求めた。

IPA（10月9日）

事実（IPAの注意喚起）

• 速やかに行うべき点検として、自組織が独自に構築・運用している外部公開アプリケーションやサービスの洗い出しと、それぞれの直近のログの確認を挙げた。異常の見分け方はエラーの出力量や平時との差異などで、直近1か月、その後3か月と段階的に範囲を広げ、今後複数回調査する可能性も踏まえて誰がどう調査できるかを把握しておくよう求めている。
• 点検で異常がなくても、外部公開アプリケーションについては公開範囲、認証（多要素認証・パスワード）、アカウントの権限、API連携などアプリケーション構成要素ごとの管理状況、ログの取得内容と保持期間を見直すよう求めた。利用している外部サービス、保有するデータ（保有の是非、保管場所、データアクセスのログ、暗号化）についても見直し項目を挙げている。
• 追記すべき情報があればページを更新するとしている。

政府の説明（10月20日）

事実（報道）

• 木原官房長官（10月20日午後の会見）：GMOサイバーセキュリティ byイエラエの調査結果を承知しているとしたうえで、「現時点で確たることを申し上げる段階にはない」と述べた。国家サイバー統括室が司令塔となり、関係省庁が集めた情報、被害企業へのヒアリング、専門機関の調査を踏まえ、AIが悪用された可能性を含めて各事案を分析している。外国主体の関与の可能性も含めてあらゆる可能性を考慮し、攻撃主体や攻撃元の実態解明に努めるとした。調査結果を公表するかは今後判断するとした（ロイター／dメニューニュース）。
• 古川デジタル大臣（10月20日の会見）：民間の機関が攻撃者によるAI利用の痕跡を確認したと発表したことを承知しているとし、国家サイバー統括室が関係省庁からの情報収集と被害企業からの直接のヒアリングを行い、専門機関の分析結果も踏まえて、AIの悪用の可能性や具体的な利用の状況、各事案の背景や相互の関連性を詳しく分析していると説明した。分析結果を活用して注意喚起を続け、企業が具体的な対策をとれるよう専門機関と連携して情報を提供するとした（テレ朝NEWS）。

その他の機関（piyologのまとめによる）

事実（piyologのまとめ）

• 個人情報保護委員会（10月7日）：注意喚起で技術的安全管理措置を示し、不要な個人データの消去を求めた。資料「WARNING」を改訂し、事例9「APIが悪用される事例」（パラメータの書き換えで他のユーザー情報を取得できた、会員IDが連番だった、アクセス回数の制限がなかったなど）を追加した。
• 警察庁（10月8日）：基本的な対策の再確認と、本人確認を行う事業者に本人確認の徹底を求めた。長官は会見で、事案の背景や相互の関連性は現時点で明らかでないとしたと報じられている。
• 総務省・経済産業省（10月9日）：所管の事業者や業界団体を通じて注意喚起。経済産業省は、被害発生時に提供された情報を事業者の同意なく公表しないとしている。
• 金融庁（10月9日）：運転免許証等の本人確認書類の画像を含む顧客情報が漏えいするインシデントが起きているとして、金融機関等に対策の点検と非対面の本人確認の徹底を求めた。

セキュリティ企業の分析

事実（マクニカ、10月7日）

• 筆者が一連の事件と似た特徴を持つと判断して集計した国内のWebシステムからの個人情報漏えいの公表は、2024年に62件、2025年に84件、2026年は10月6日時点で119件で、うち81件が7月以降だという（マクニカ）。
• 7月以降の81件のうち、公表から原因を読み取れたのは、製品・CMS・プラグイン・分析ツール等の脆弱性9件、認証情報の悪用やパスワード攻撃4件、設定・アクセス制御の不備3件で、65件（80.2%）は分類に必要な説明が不足していたという（同）。
• 事案対応やログ分析からは、特定の脆弱性だけでなくサイトやAPIの不備を広く探る動き、スマートフォンアプリから取り出したAPIキーで正規のアクセスに見える形でAPIを呼ぶケース、必要以上の情報を返すAPI・過剰な権限のAPI・会員向け機能に匿名でアクセスできる問題などが見えているとした。AIによるゼロデイ脆弱性の発見と悪用については「現時点ではそのような状況は確認されていません」としている（同）。

事実（サイバーセキュリティクラウド、10月9日）

• マクニカが公開したIPアドレス2件を起点に自社の観測（9月18日〜10月8日、ログの範囲は環境により異なる）を調べたところ、同一とみられる攻撃者が約40分間で326のIPアドレスを使い分け、1,200件を超えるアクセスを複数回行っていたという（サイバーセキュリティクラウド）。
• 観測した流れの一例は、SQLインジェクションによる認証回避の探索、事前に作ったとみられるアカウントでのログイン、ログイン後の機能での再探索、ポイント制度のあるサイトでの他人のポイント窃取の探索、一通り試すと引き上げる、というもの。応答を見ながら手を変える動きから、AIエージェントまたはそれに近い仕組みの可能性があるとしつつ、「AIの利用を直接示す痕跡を確認したものではありません」としている（同）。
• 1つのIPアドレスあたりのアクセス数が少ないため、IPアドレスごとのアクセス数やツール特有のパターンに頼る監視では見逃すおそれがあるとし、通常と異なるHTTPレスポンスコードやレスポンスサイズの偏りに注目したログ調査を勧めている（同）。

事実（GMOサイバーセキュリティ byイエラエ、10月19日）【2026-10-20追記】

• 日本企業を狙った侵害事案の攻撃元インフラを調べ、AIによる自律型ペネトレーションテストシステム「ARTEX」が使われていることを確認した。前回の記事でフォレンジックログからAIによる攻撃の可能性が高いと推定していたことを裏付ける結果だとしている（GMOサイバーセキュリティ byイエラエ）。
• 外部機関と連携した調査では、同社が観測できる範囲で、その攻撃元インフラはほぼ日本だけを標的にしていた。標的は日本企業約20社で、うち9社は同業種のサイトだった。CrowdStrikeが報告した韓国の金融機関への攻撃と合わせ、国と業種を絞ったキャンペーンごとに別の攻撃用ホストを用意しているとみている（同）。
• 同様に日本企業を狙ったAIを使う攻撃インフラを計6台見つけた。主な標的の業種は、デジタルギフト・小売り流通、教育・ギフト・印刷、ポイントギフト・マーケティング、保険・金融、EC・メディア・物流、ECに分かれていた（同）。
• 標的と確認した日本企業のうち8社は2026年9〜10月に情報漏えいを公表しており、同一の攻撃グループによる犯行で複数の被害が出ているとした。情報は法執行機関に共有した。企業名と、日本の事案で使われたAIモデルは示していない（同、ITmedia NEWS）。

考察

注意喚起を並べて読むと、どの機関も「これを塞げば止まる」という単一の脆弱性を示していない。JPCERT/CC自身が情報は「限定的かつ断片的」と書き、マクニカの集計では7月以降の公表の8割が原因を読み取れない。各社の公表が「不正アクセス」「〇〇件」で止まっていることが、他の組織が自分のシステムを点検するための手がかりを乏しくしている。その中で、JPCERT/CCがIPアドレスやUser-Agent、Webシェルの形を出したことは、ログを遡って調べる材料として意味が大きい。

もう一つ目立つのは、対策の重心が「侵入を防ぐ」から「取られる量を減らす」に寄っていることだ。NCOの「必要以上の権限が付与されている場合、不正アクセス時に大量の情報が一度に取得される」、IPAの「データ保有の是非の再検討」、個人情報保護委員会の不要データの消去は、どれも侵入された後の被害の上限を下げる話である。10月の国内事例の多くが、1つの入口から会員全件に届いていた（焼肉きんぐのほぼ全会員、GMOリサーチ＆AI「infoQ」の全件持ち出しなど）ことと合っている。

サイバーセキュリティクラウドの観測にある「ポイント制度のあるサイトで他人のポイントを狙う」動きは、infoQで会員のポイントがAmazonギフトコードに交換された件と似ている。ただし、観測された攻撃者とinfoQの事案が結びつくかはわからない。

【2026-10-20追記】GMOサイバーセキュリティ byイエラエの調査で、攻撃インフラごとに業種を分けて狙っていたことは、韓国の金融機関への攻撃でARTEXが使われた事例と同じ組み立てに見える。一方で政府は「確たることを申し上げる段階にはない」としており、どの公表事案がこの攻撃グループによるものかは、企業名が示されていない現時点では外から確かめられない。各社の公表とJPCERT/CCの4類型との対応が示されれば、自組織の点検の優先順位を決める材料になる。

関係しそうな既知の手口

事実（既知の知見）

• OWASP API Security Top 10（2023年版）は、要求したオブジェクトへの権限を確かめない「Broken Object Level Authorization」を1位に、認証の不備や過剰なデータの返却につながる欠陥も上位に挙げている。JPCERT/CCはAPI対策の詳細としてOWASPのガイドラインを参照先に挙げている（JPCERT/CC）。

考察

• ケースBは「アプリは解析される」前提の欠如：公開しているスマートフォンアプリには、通信先のAPIや、場合によってはAPIキーが入っている。サーバー側が「自社アプリから来た要求だから正しい」と扱っていると、解析した第三者がアプリを通さずに直接APIを呼び、画面ではできない操作（権限の変更や他人のデータの取得）を実行できてしまう。
• ケースDはJavaアプリケーションサーバーの管理不備でも起きうる：WARファイルが置かれたという記述から、TomcatなどのJavaアプリケーションサーバーで、外部から届く管理画面やデプロイ機能が使われた可能性がある。設置手口は公表されていないので、既知の脆弱性か、弱い管理パスワードか、別の侵入の後の設置かはわからない。

利用者・運用者がいまできること

事実（各機関の注意喚起に基づく）

• 自組織が外部に公開しているアプリケーション・サービス・APIを洗い出し、直近1か月、その後3か月と段階的にログを確認する（IPA）。JPCERT/CCが公開した送信元IPアドレスとUser-Agentを侵害調査に使う（JPCERT/CC）。
• APIには単位時間あたりのリクエスト件数の制限をかけ、非公開APIを含む各エンドポイントでアクセス制御を行う。APIトークンは最小権限・適切な有効期限にし、漏えいが疑われるものは無効化する（JPCERT/CC）。
• 業務上必要のない管理機能などのインターネットへの公開を止め、利用地域が限られるならアクセス元の地域を制限する（JPCERT/CC）。
• 利用目的を終えたデータや保存期間を過ぎたデータを残さない（JPCERT/CC、NCO）。委託先に渡した情報も、業務終了後の削除を徹底する（NCO）。
• 被害にあった場合は、技術的な情報をNCO・所管省庁・専門機関に共有する（NCO）。

考察（運用者向け）

• ログを見るときは、IPアドレスごとのアクセス数だけでなく、普段と違うレスポンスコード（401・403・404・500番台）の偏りや、同じAPIで返すデータ量の急な変化を見る。サイバーセキュリティクラウドの観測のように、多数のIPアドレスに分散した探索は、IPアドレス単位の閾値では目立たない。
• 自社が配布しているスマートフォンアプリを、自分で解析してみる。埋め込まれたAPIキーや、画面からは呼ばない内部APIのエンドポイントが見えるなら、それは攻撃者にも見えている。
• ログの保持期間を確認する。IPAが3か月まで遡るよう求めている一方、サイバーセキュリティクラウドも環境によってログの範囲が違うと書いている。いま遡れない期間は、後から侵害の有無を確かめる手段がない。

考察（利用者向け）

• 流出の公表が続いているので、同じパスワードを複数のサービスで使わない、多要素認証を有効にする、流出元を名乗るメールやSMSのリンクを開かない、という基本が最も効く。

参考リンク

1. 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT/CC、2026-10-08公開・10-09更新）
2. 不正アクセスによる漏えい等の事案を踏まえた対応について（内閣官房国家サイバー統括室、2026-10-09、PDF）
3. 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について（IPA、2026-10-09）
4. MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）に関する注意喚起（JPCERT/CC、2026-08-14）
5. 大規模な漏えい等事案を踏まえた対応について（注意喚起）（個人情報保護委員会、2026-10-07）
6. 相次ぐWEBシステムからの情報漏洩事案について（マクニカ セキュリティ研究センター、2026-10-07）
7. 国内で相次ぐ不正アクセス、AIエージェントによる攻撃の可能性 約40分間で326のIPアドレスを使い分け、1,200件超のアクセスを繰り返す（サイバーセキュリティクラウド、2026-10-09）
8. 国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた（piyolog、2026-10-11）
9. 国家サイバー統括室、「もはや情報システム部門だけの問題ではありません」と不正アクセス事案を踏まえ注意喚起（INTERNET Watch、2026-10-09）
10. 相次ぐ不正アクセスの攻撃元の多くがAIであることを確認（GMOサイバーセキュリティ byイエラエ、2026-10-19）
11. 日本企業狙う不正アクセスにAI　攻撃者が自律型侵入テスト「ARTEX」を悪用　GMOイエラエ調査（ITmedia NEWS、2026-10-20）
12. 国内サイバー攻撃でＡＩ使用の有無、現時点で確たること言えない＝官房長官（ロイター／dメニューニュース、2026-10-20）
13. 【更新中】不正アクセス一部に“中国系AI”の使用確認 ＜情報まとめ＞（テレ朝NEWS、2026-10-20更新）
14. 不正アクセスによる個人情報漏えい相次ぎ警視庁に相談相次ぐ（NHK、2026-10-21）