JPCERT/CC の注意喚起（2026年10月）を読み解く：4 つの攻撃の型と、開発者が確かめること

JPCERT/CC の注意喚起 JPCERT-AT-2026-0030 は、国内で2026年9月前後に相次いでいる、不正アクセスによる個人情報などの漏えいについて、寄せられた攻撃の手口を4つの型（ケース A〜D）に分け、API 向けの6つと汎用の7つの対策を勧める文書です。ただし JPCERT/CC 自身が、把握している情報は限定的かつ断片的であり、4つの型はすべての事案で同じ手口が使われたことを示すものではない、と断っています。

この記事は、その注意喚起の全体を、書かれている順（I 概要・II 攻撃手法と痕跡・III 対策・IV 参考情報・V 情報提供等）に読み解きます。Web アプリや API を作っている開発者、小さな会社のエンジニア向けです。型ごとに詳しい記事へ案内し、最後にチェックリストを付けました。2026年10月20日に開いた資料にもとづいていて、攻撃の手順は書きません。

この記事でわかること

注意喚起 JPCERT-AT-2026-0030 が何を書いていて、どこまで言えるか（10月8日公開・9日更新。10月20日時点で、9日のあとの更新なし）
4つの型（ケース A〜D）の中身と、型ごとに読む記事
注意喚起が勧める対策（API 向けの6つ・汎用の7つ）。型ごとの対策は書かれていないこと
参考情報（IV）と、注意喚起とは別に出た関連の資料（JPCERT/CC のブログ・NICT・IPA）の違い
被害を受けたかもしれないときに、注意喚起と関連の資料が書いていること
自分のアプリで確かめるチェックリスト

注意喚起 at260030 には何が書いてある？読む前に知っておくこと（2026年10月20日時点）
II. 4 つの型（ケース A〜D）は、何が起きたものか？
III. 対策は何を勧めている？API 向けの 6 つと、汎用の 7 つ
IV. 参考情報は何？注意喚起とは別に出た、関連の資料との違い
被害を受けたかもしれないときは？V の窓口と、確かめ方
自分のアプリで、何を確かめればよい？
1. 組織で決めること（コードというより運用の話）
この記事で扱わないこと
よくある質問
1. 2026年9月前後の一連の事案は、4 つの型のどれに当たりますか？
2. 型 D の Web シェルは、どこから置かれたのですか？
まとめ
参考資料

注意喚起 at260030 には何が書いてある？読む前に知っておくこと（2026年10月20日時点）

JPCERT/CC（一般社団法人 JPCERT コーディネーションセンター）は、コンピューターセキュリティの情報を集めて、注意を呼びかける組織です。注意喚起は、その呼びかけの文書で、番号が付いています。この記事で読む注意喚起の番号は JPCERT-AT-2026-0030（URL の末尾から「at260030」と呼びます）で、題は「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」です。

日付と、更新されうること

2026年10月8日に公開され、10月9日に更新されました。ページには「最終更新: 2026-10-09」と出ています
改訂履歴は2行だけです。2026年10月20日に開いた時点で、10月9日のあとの更新は見つかりませんでした
注意喚起は「侵害原因や攻撃手法などに関する新たな情報が判明した場合、本ページを更新していきます。」と書いています。この記事は2026年10月20日に読んだ時点のものです。使う前に、注意喚起のページで最新の版を確かめてください

I. 概要：何を、なぜ出したのか

概要は、まず被害の状況を、次のように書いています。

各被害公表や報道のとおり、直近2026年9月前後で国内組織における不正アクセスによる個人情報等の漏えい被害が相次いでいます。

「相次いでいます」は JPCERT/CC の言葉です。この記事は、件数や増え方については何も言いません。注意喚起にも、被害の件数は書かれていません。続けて、断りが入ります。

複数の製品やサービスで被害が発生している中、技術的な情報の共有が不足しており、把握している情報は限定的かつ断片的であるものの、攻撃被害の拡大等の状況に鑑み、下記のとおり注意を促す次第です。

取り上げる対象について、概要は、ふだん断続的・散発的に起きているランサムウェア攻撃（データを使えなくして金銭を要求する攻撃）などの不正アクセスとは別に、大量の個人情報などの漏えいにつながっている攻撃の類型だと書いています。原文は、この類型を「特に増加している恐れのある」ものとも書いています。ただし、増えているかどうかを裏づける数字は、注意喚起にはありません。

もう1つ、開発者が見落としやすい一文があります。

一般利用者向けのアプリのほか、BI（ビジネスインテリジェンス）ツールや従業員向け管理システムなど、管理・運用側で不特定多数の利用者からのアクセスを想定していないシステムが被害に遭い、内部に保存していた情報が漏えいするケースもあります。こうしたシステムについても下記のような点検などを行う必要があります。

BI ツールは、会社のデータを集めて、グラフや表にして見るための道具です。社内向けの画面や道具も、点検の対象に入っています。

10月9日の更新では、II に2つの情報が足されました。ケース A とケース B に不審な送信元 IP アドレスを足したことと、ケース D を新しく足したことです。注意喚起は「侵害調査にご活用ください」と書いています。

この記事での約束

「JPCERT/CC は〜と書いています」は、注意喚起の本文にあることです
「この記事での整理」は、この記事が分けたり結んだりしたもので、JPCERT/CC の言葉ではありません
注意喚起の本文に「AI」という語はありません（2026年10月20日に本文を検索して、0か所でした）。AI の話は、注意喚起とは別の資料（後の節）と、AI を悪用した攻撃の記事にあります

II. 4 つの型（ケース A〜D）は、何が起きたものか？

II の題は「確認されている攻撃手法や攻撃の痕跡」です。冒頭に、次の断りがあります。

※本項の情報は、JPCERT/CCに寄せられた情報などに基づくものです。すべての事案で同一の攻撃手法が使用されていることを示すものではありません。また、今後の状況などを踏まえて情報を追加する可能性があります。

そのため、4つの型は、「9月の事案がこの型だった」という答えではなく、寄せられた手口の例として読みます。次の表の右の列は、この記事での整理です。

型	注意喚起の見出し	詳しい記事
A	さまざまなソフトウェアの既知の脆弱性を探索し攻撃試行するもの	この回の記事では扱っていない。脆弱性の知らせの読み方は脆弱性の知らせの記事で説明しています
B	API経由での不正な操作	サーバー側の認可は認証と認可の記事。(a) アプリに秘密を入れない点と (b) の NoSQL は、この回の記事では扱っていない。アプリに秘密を入れない点は環境変数と .env の記事の「公開してよい鍵と、秘密の鍵（スマホアプリも解析される）」で説明しています。NoSQL インジェクションはSQL 以外のインジェクションの記事で説明しています
C	MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）	SQL インジェクションの記事
D	公開Webサーバーからアクセス可能なアプリケーションサーバー上にWebシェル設置（10月9日に追加）	この回の記事では扱っていない

型 A：さまざまなソフトウェアの既知の脆弱性を探す

脆弱性は、ソフトウェアのセキュリティ上の弱点のことです。既知は、すでに公表されているという意味です。ケース A について、注意喚起は次のように書いています。

一連の攻撃については、一つの共通するソフトウェアの脆弱性を悪用しているのではなく、標的ごとにさまざまな既知の脆弱性有無についてスキャンし、脆弱性を探索して悪用を試行したり、脆弱性ではないものの、機器の管理不備等を悪用した攻撃（環境設定ファイルやバックアップファイルの窃取など）を試みている可能性があります。

スキャンは、外から順に調べて、弱点のある所を探すことです。ここで大事なのは、1つの共通するソフトの穴ではないと書いている点と、脆弱性ではない「管理不備」も狙われている可能性がある点です。どちらも断定ではありません。10月9日の更新で、不審な送信元 IP アドレスが追加されました（→「痕跡（IoC）の一覧：自分のログと照らすときは、注意喚起を直接見る」）。

型 A そのものを扱った記事は、この回にはありません。近い話として、修正済みの版に上げる例はReact・Next.js の脆弱性の記事に、設定の値の置き方は環境変数と .env の記事にあります。

型 B：API 経由の不正な操作

APIは、アプリとサーバーの間で情報をやり取りする窓口です。エンドポイントは、その API の入口（URL）のことです。ケース B の書き出しは、次のとおりです。

アプリの管理用APIへの不正なリクエストによって、情報の不正な書き換え等が発生しているものがあります。JPCERT/CCでは、次のような攻撃手口に関する複数の報告を受けています。

挙げられている手口は3つです。

(a) 一般公開しているスマートフォンアプリを解析し、API のエンドポイントやキーを特定する
(b) 本来画面操作では実行できない内部 API に対する攻撃。例として、ユーザー権限を変更する、不正なアカウントを作成する、NoSQL インジェクションによるブラインド探索でアカウント情報を特定する、が挙げられています。このほかの項目は、注意喚起を直接見てください
(c) 他のシステムの侵害で窃取した API キーを使用する

NoSQL インジェクションは、SQL ではない種類のデータベースに対する、インジェクション（入力を使って、意図しない命令を実行させる攻撃）の仲間です。

この型について、1つ注意があります。注意喚起は、ケース B を「ID を書き換えると他人のデータが見える」話（IDOR・BOLA）とは書いていません。認証と認可の記事も、ケース B は別の話として扱っています。一方で、NICT（情報通信研究機構）の CYNEX は、公開されている Android アプリを解析してその裏のサーバーを狙う攻撃について、点検してほしいものの1つに「APIの認可不備（IDOR/BOLA）」を挙げています。これは NICT の言葉です。NICT は、この注意喚起を名指ししていません。

認可をサーバー側で確かめる点と、API の権限・有効期限・無効化の考え方（(c) に近い話）は、認証と認可の記事にあります。(a) のアプリに秘密を入れない点と NoSQL インジェクションは、この回の記事では扱っていません。アプリに秘密を入れない点は環境変数と .env の記事の「公開してよい鍵と、秘密の鍵（スマホアプリも解析される）」で説明しています。NoSQL インジェクションはSQL 以外のインジェクションの記事で説明しています。

型 C：Metabase の SQL インジェクションの脆弱性

ケース C は、Metabase という製品の SQL インジェクションの脆弱性（CVE-2026-72898）です。CVE は、公表された脆弱性に付く通し番号です。SQL インジェクションは、入力した文字が SQL（データベースへの命令）の一部として動いてしまう問題です。

本脆弱性も、APIへの不正なリクエストを通じて悪用されるものです。JPCERT/CCでは、2026年8月14日に本脆弱性に関する注意喚起を公表しています。影響を受ける製品や対策などの詳細については、次の注意喚起をご確認ください。

この「次の注意喚起」が JPCERT-AT-2026-0023 です。at260030 は、型 C の製品や対策の詳しいことを at260023 に任せています。at260023 によると、悪用された場合、遠隔の第三者が認証なしで細工したリクエストを送り、Metabase のアプリケーションデータベースに不正な SQL を実行して、管理者権限を取る可能性があります。対象は58系から63系の、それぞれ決まった版より前で、対策は、修正を含む最新の版にすることです。

詳しい中身は、SQL インジェクションの記事の「Metabase の件」にあります。侵害されたかもしれないときの確かめは、後の節で書きます（→「被害を受けたかもしれないときは？V の窓口と、確かめ方」）。

型 D：Web シェルの設置（10月9日に追加）

ケース D は、10月9日に追加された型です。

公開Webサーバーからアクセス可能なアプリケーションサーバー上にWARファイル（.war）が設置される事案を確認しています。WARファイルに含まれるJSPファイル（.jsp）は、悪性な簡易Webシェルとして動作します。Webシェルは特定のクエリパラメーターを取得しシェルコマンドとして実行する機能を持ちます。

言葉を補います。WAR ファイルと JSP ファイルは、Java で作る Web アプリの、配布用のファイルと、ページを作るファイルです。Web シェルは、外から命令を送って、サーバーの上で実行させるための仕掛けです。クエリパラメーターは、URL の「?」のあとに付ける値のことです。

注意喚起には、どうやってそのファイルが置かれたか（入口）は書かれていません。 型 D を扱った記事は、この回にはありません。

4 つを並べて読むと

ケース A は「一つの共通するソフトウェアの脆弱性を悪用しているのではなく」と書き、ケース C は1つの製品の脆弱性です。IPA（情報処理推進機構）も、特定の製品やサービスの脆弱性を狙った攻撃とは断定されていない、と書いています。どちらが多いかは、書かれていません。両方をそのまま書いておきます。

痕跡（IoC）の一覧：自分のログと照らすときは、注意喚起を直接見る

IoC（Indicator of Compromise）は、侵害の痕跡のことで、攻撃に使われた IP アドレスなどの手がかりを指します。注意喚起の II には、ケース A〜D のそれぞれに「不審な送信元IPアドレス」が、ケース B・C には User-Agent（ブラウザーやアプリが名乗る名前の欄）の例が載っています。

この記事には、それらの値を書き写しません。 自分の組織のログと照らすときは、注意喚起のページを直接見てください。見るときの注意が2つあります。

一覧には、使われていた時期の注記があります（例: ケース A は「10月7日ごろ」、ケース B は「9月ごろ」）
ケース B と C には「調査時点では正規利用されている可能性もあります」とあります。一覧と合ったことだけで、被害と決めてはいけない、という書き方です

ログのどこをどう見るかは、注意喚起には書かれていません。IPA の文書にある見方は、後の節にまとめます。

III. 対策は何を勧めている？API 向けの 6 つと、汎用の 7 つ

III の前置きは、次のとおりです。

JPCERT/CCに報告されている攻撃手口に基づいて、次の対策の実施を推奨します。API経由のアクセスへの対策の詳細は、OWASPのガイドライン等を参考にしてください。

対策は「API経由のアクセスへの対策」と「上記の他、汎用的な対策」の2つに分かれています。どの対策がどの型（A〜D）に当たるかは、書かれていません。 ケース C だけは、II の中で at260023 を見るよう案内していますが、III の対策とは結ばれていません。そのため、この記事も「JPCERT/CC は型 D にこれを勧める」のようには書きません。

API 経由のアクセスへの対策（6つ）

次の6つは、注意喚起の文のままです。

APIへのアクセスには単位時間あたりのリクエスト件数を制限し、短時間に繰り返されるアクセスや大量実行を防止する
ログイン、パスワードリセット、SMS送信、検索処理などの負荷や悪用のリスクが高い機能には個別にレート制限や利用回数制限を設定する
非公開APIを含む各APIエンドポイントでアクセス制御を実施し、許可された利用者やHTTPメソッドからのアクセスのみを受け付ける
API利用者やAPIトークンには必要最小限の権限のみを付与する
APIトークンには適切な有効期限を設定し、長期間有効なトークンの使用を避ける
不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする

言葉を補います。

レート制限は、一定の時間に受け付ける回数に上限を付けることです。1・2 は、API 全体の上限と、悪用されやすい機能ごとの上限を分けて求めています。回数の制限の付け方はレートリミットの記事で説明しています
非公開 APIは、利用者向けの画面からは見えない、内部や管理用の API のことです。3 は、公開していないつもりの API にもアクセス制御が要る、という意味です
HTTP メソッドは、GET（取得する）や POST（送る）のような、リクエストの種類です
API トークンは、API を使ってよい人だと示す文字列（合言葉のようなもの）です。4〜6 は、権限を最小にする、期限を付ける、不要になったら無効にできるようにする、の3点です

上記の他、汎用的な対策（7つ）

こちらも、注意喚起の文のままです。

サービスの利用地域が限定される場合は、アクセス元の地域を制限する
既知の脆弱性の影響を受けるバージョンで運用している場合は、修正済みのアップデートを適用する
Webサーバー等が侵害された後の横展開対策を見直す
不正アクセス検知体制の点検と検知時の初動対応を見直す
漏えい発生時を想定した、平時からの顧客への二次被害防止等の呼びかけ（多要素認証など）
業務上必要のないサービスや機能（管理機能など）がインターネットに公開されている場合、公開を停止する
法令や契約等で定められた保存期間を過ぎたデータや利用目的を終えたデータを残さない

横展開は、侵入された先から、別のサーバーへ広がることです。初動対応は、異常を見つけた直後の最初の対応です。多要素認証は、パスワードに加えて、もう1つ別の方法でも本人を確かめる仕組みです。

この7つのうち、1・3・4・5 は、コードというより、組織の運用で決めることです（この記事での整理）。2・6・7 は、開発者が自分のアプリですぐ確かめられます。

念押し：従業員向けのシステムや BI ツールも

III の末尾でも、注意喚起は繰り返します。

繰り返しになりますが、管理・運用側で不特定多数の利用者からのアクセスを想定していないシステム（従業員向け、BIツールなど）が被害に遭うケースもあります。こうしたシステムについても上記のような点検などを推奨します。

社内向けだから点検を省く、という理由は通らない、という書き方です。

IV. 参考情報は何？注意喚起とは別に出た、関連の資料との違い

IV の参考情報に挙がっているのは、3本だけです。OWASP の資料が2本と、民間企業のブログが1本です。民間企業のブログは、この記事では取り上げません。

OWASP（オワスプ）は、Web アプリのセキュリティを高める活動をしている団体です。ここでは、注意喚起が挙げた2本を見ます。

OWASP API Security Top 10 2023

API に特有の重大なリスクを10項目に並べた一覧です。一覧のページだけを開いていて、個別のページは読んでいません。注意喚起と重なりそうな項目を並べます。右の列は、この記事での整理です。

項目	日本語にすると	注意喚起とのつながり（この記事での整理）
API1 Broken Object Level Authorization	データ単位の認可の不備	API 向けの3つ目（各エンドポイントでアクセス制御）
API4 Unrestricted Resource Consumption	資源の使い放題	API 向けの1・2つ目（リクエスト件数の制限、機能ごとのレート制限）
API5 Broken Function Level Authorization	機能単位の認可の不備	API 向けの3つ目。OWASP は、管理用の機能と通常の機能の分け方が不明確だと、管理用の機能にアクセスされうると書く。ケース B (b) と同じ方向の話
API7 Server Side Request Forgery	SSRF	注意喚起の本文には出ない。JPCERT/CC のブログの対策にある（次の小節）
API8 Security Misconfiguration	設定の不備	ケース A の「機器の管理不備」と同じ方向の話
API9 Improper Inventory Management	API の棚卸しの不備	汎用の6つ目（要らない機能の公開停止）。OWASP は、API の一覧を持つことが、廃止された版や公開されたデバッグ用の入口といった問題を減らすのにも大切、と書く

OWASP REST Security Cheat Sheet

REST（Web の API の作り方の1つ）の API を守るための手引き集です。注意喚起の対策と重なる所を、OWASP の文を日本語にして並べます。JPCERT/CC が「ここから取った」と書いているわけではありません。

アクセス制御：非公開の REST サービスは、API の入口ごとにアクセス制御をする
API キー：リクエストごとに API キーを求める。速すぎるときは 429（Too Many Requests）を返す。約束を破ったら失効させる。重要なものを API キーだけで守らない
HTTP メソッド：許す種類の許可リストを作り、合わないものは 405（Method not allowed）で断る
管理用の入口：管理用の入口をインターネットに出さない。出すなら、多要素認証のような強い認証を使う

注意喚起とは別に出た、関連の資料

次の3つは、IV の参考情報には挙がっていません（日付は2026年）。

資料	日付	注意喚起との関係
JPCERT/CC のブログ「連続不正アクセス事案の攻撃手法に関する調査」	10月15日	注意喚起の公開（10月8日）のあとに出た。ブログの側から注意喚起に触れている
NICT（CYNEX）の注意喚起「相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」」	10月13日	JPCERT/CC のブログが参考に挙げている。NICT のページは、at260030 を名指ししていない
IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」	10月9日	IPA の側が「（ご参考）」に、at260030 を挙げている

JPCERT/CC のブログ（10月15日）

ブログは、10月8日の注意喚起に続けて、複数の組織と連携し、攻撃に使用された可能性のあるインフラを調べてきたと書いています。その過程で、次のことを確認したそうです。

攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していた

攻撃元のサーバーは複数あり、日本以外の地域向けの Web サービスにも攻撃をしていた、とあります。AI の話は、注意喚起の本文にはなく、このブログのものです。ブログは、これが9月の事案のどれに当たるかを書いていません。調べた中には、「今回の攻撃とは直接関係しない別のサーバー」もあります。

ブログによると、今回確認した攻撃の特徴の1つは、Android アプリの配布ファイル（APK ファイル）を解析して、見つけた API を悪用する点です。攻撃元のサーバーには、API に SSRF などの脆弱性がないかを調べた痕跡があった、とあります。SSRF（Server-Side Request Forgery）は、サーバーに、攻撃者が指定した宛先（外からは届かない社内のサーバーなどを含む）へリクエストを送らせる攻撃です。

ブログは、アプリの中に共通の秘密鍵や API 認証の秘密情報が埋め込まれていると、取り出されて、正規のアプリを通さない API リクエストを作られる恐れがある、と説明し、次の4つを勧めています。

秘密情報の保護：API の認証に使う秘密鍵や、有効期間の長い認証情報をアプリに埋め込まない
サーバー側での認証・認可：アプリ内の署名処理や難読化だけに頼らず、サーバー側で利用者を認証し、操作の対象と内容に応じて認可する
API の不正利用対策：レート制限や異常なリクエストの監視を行い、正規のアプリ以外からのアクセスも想定する
SSRF 対策：外部の URL の内容を取得する API では、アクセス先を制限し、リダイレクト後の宛先も検証する

AI を悪用した攻撃の全体は、AI を悪用した攻撃の記事にまとめています。

NICT（CYNEX）の注意喚起（10月13日）

NICT は、公開されている Android アプリを解析して、その裏にあるサーバー（バックエンドサーバー）を攻撃する手口を「A2B 攻撃」と呼んでいます。アプリそのものに脆弱性がなくても、サーバー側の認証・認可や入力値の検証に不備があれば、漏えいにつながるおそれがある、と書いています。AI で解析や脆弱性探しが効率化される可能性にも注意が必要だ、とも書いています。

Android アプリを公開する事業者へのお願いは3つです。侵害の確認（公開している API とサーバーを洗い出し、ログを見る）、脆弱性の点検（IDOR/BOLA〔ID を書き換えると他人のデータに届く認可の不備〕、SSRF、RCE〔外から命令を実行されること〕、SQL インジェクションなどを重点的に）、暫定的な緩和策（不要な API の停止、アクセス制限、監視の強化、認証情報の無効化・再発行など）です。公開アプリが解析されることを前提に、サーバーの安全を確保することが重要だとも書いています。

IPA の注意喚起（10月9日）

IPA は、外部に公開しているアプリやサービスの侵害、アカウントの侵害が起点になっていることがうかがえる、と書いています。速やかに行う点検は、次の節にまとめます（→「被害を受けたかもしれないときは？V の窓口と、確かめ方」）。

そのあとに取り組む対策として、IPA は、外部公開範囲の見直し、認証機能の強化、権限付与の見直し、ログ取得内容と保持期間の見直しなど7つを挙げ、「不要な情報は持たない」という基本原則にも触れています。

被害を受けたかもしれないときは？V の窓口と、確かめ方

最初に、注意喚起の範囲をはっきりさせます。注意喚起の中で「確かめ方」に当たるのは、II の不審な送信元 IP アドレスと User-Agent の一覧と、「侵害調査にご活用ください」の一文だけです。ログのどこをどう見るかの説明は、注意喚起にはありません。そのため、ここでは注意喚起と、注意喚起とは別の資料に分けて、書かれていることを並べます。

注意喚起の IoC の一覧と照らすときは、前の II の小節のとおり、注意喚起を直接見てください（→「痕跡（IoC）の一覧：自分のログと照らすときは、注意喚起を直接見る」）。

IPA（10月9日）：ログとアカウントの見方

IPA は、速やかに行う点検として、次のことを挙げています。

外部公開のアプリの有無：外部に公開しているアプリやサービスに、自分たちで作って動かしているものがないか確かめる
ログ：アプリやサービスごとに、直近のログに異常が記録されていないか確かめる。異常の見分け方の例は、エラーの出力量と平時との差です。確かめる範囲は、直近1か月、その後3か月と、段階的に広げる
未適用の修正：まだ当てていない脆弱性対応のパッチ（修正）がないか確かめる
使っている外部サービスとアカウント：外部サービスを洗い出し、「作ったはずのないアカウントが存在しないか、削除・無効化されているはずのアカウントが有効化されていないか」を確かめる。異常には、ログイン失敗の量のように分かりやすいものと、ログイン元の IP アドレスや時間を平時と比べないと分からないものがある

異常なログやアカウントが見つかったら、速やかにセキュリティインシデントと判定してインシデント対応を進め、情報漏えいの可能性を考えて、専門のセキュリティベンダーに詳細な調査を頼むことを強く勧める、と書いています。インシデントは、セキュリティ上の事件・事故のことです。

Metabase を使っているとき（at260023）

型 C に当たる Metabase を使っているときは、JPCERT-AT-2026-0023 に、次のことが書かれています。

最新の版を適用する。ただし、Metabase が示すエンドポイントをインターネットから届く状態で運用していたなら、更新だけで終えず、侵害の有無を確かめることを Metabase が勧めている
侵害された可能性があるなら、ユーザーセッション・API キー・管理者アカウントなどを確かめ、接続先データベースの認証情報を変えることを Metabase が勧めている
Metabase や接続先データベースのログを見て、不審な操作やアクセスがないか確かめる

遮断する入口の名前や、ログで見る通信の並びは、at260023 を直接見てください。

V：JPCERT/CC の窓口

注意喚起の V（調査依頼、情報提供等）は、今回の事案に関連して、不審なアクセスや侵害が疑われる事象、攻撃手法、侵害原因などの具体的な情報があれば、JPCERT/CC に知らせてほしい、と書いています。インシデント対応の相談も受け付けています。

注意喚起に関する問い合わせ：JPCERT/CC サイバーセキュリティコーディネーショングループ（Email: ew-info@jpcert.or.jp）
インシデント対応の相談の連絡先：注意喚起の V に載っているフォーム（https://www.jpcert.or.jp/form/ ）
調査ベンダーなどからの相談対応：注意喚起の V に載っているページ（https://www.jpcert.or.jp/ir/consult.html ）

JPCERT/CC のブログは、攻撃の標的になっている可能性のある組織を見つけたら、その組織に連絡している、と書いています。連絡を受けたら、対応してほしいそうです。

自分のアプリで、何を確かめればよい？

次のチェックリストは、注意喚起と、別に出た関連の資料（JPCERT/CC のブログ・NICT・IPA）に書かれていることを、自分のアプリですぐ確かめられる形にしたものです。選び方と並べ方は、この記事での整理です。各行の最後の（→）は、根拠を書いた節の名前で、どの資料の話かはそこで確かめられます。

自分のアプリで確かめること（チェックリスト）

自分が作って外に出しているアプリ・サービス・API を、非公開のもの・管理用のもの・社内向けのもの（BI ツールなど）も含めて、全部書き出せるか（→「I. 概要：何を、なぜ出したのか」「念押し：従業員向けのシステムや BI ツールも」）
非公開のものも含め、API の入口ごとにアクセス制御があり、許した利用者と HTTP メソッドからのリクエストだけを受け付けているか。やり方は認証と認可の記事で（→「API 経由のアクセスへの対策（6つ）」）
画面で隠しているだけの操作（権限の変更・アカウントの作成など）を、サーバー側で認可しているか（→「型 B：API 経由の不正な操作」）
API 全体にリクエスト件数の制限があり、ログイン・パスワードリセット・SMS 送信・検索のような悪用されやすい機能には個別の制限があるか（→「API 経由のアクセスへの対策（6つ）」）
API の利用者とトークンの権限は必要最小限か。トークンに有効期限があり、長く効くものを使っていないか（→「API 経由のアクセスへの対策（6つ）」）
要らなくなったトークン、漏えいが疑われるトークンを、すぐ無効にできるか（→「API 経由のアクセスへの対策（6つ）」）
配っているアプリ（スマートフォンのアプリなど）に、API の認証に使う秘密鍵や、有効期間の長い認証情報を埋め込んでいないか。アプリの中の署名や難読化だけに頼らず、サーバー側で認証・認可しているか（→「JPCERT/CC のブログ（10月15日）」）
外部の URL の内容を取りに行く API があるなら、アクセス先を制限し、リダイレクト後の宛先も検証しているか（→「JPCERT/CC のブログ（10月15日）」）
使っているソフトウェアが、既知の脆弱性の影響を受ける版のままになっていないか。Metabase を使っているなら、at260023 が示す影響を受ける版（各系の決まった版より前）ではないか（→「上記の他、汎用的な対策（7つ）」「型 C：Metabase の SQL インジェクションの脆弱性」）。脆弱性の知らせの読み方は脆弱性の知らせの記事で説明しています
業務に要らない管理機能などが、インターネットに公開されていないか（→「上記の他、汎用的な対策（7つ）」「OWASP REST Security Cheat Sheet」）
保存期間を過ぎたデータ、利用目的を終えたデータを、残していないか（→「上記の他、汎用的な対策（7つ）」）
直近のログに異常がないか（エラーの量、平時との差）。作った覚えのないアカウントや、無効のはずなのに有効なアカウントがないか。異常があったときは、インシデントとして扱い、専門のベンダーへの依頼を考える（→「IPA（10月9日）：ログとアカウントの見方」）

組織で決めること（コードというより運用の話）

注意喚起の汎用の対策のうちの4つと、IPA が挙げる1つです。組織の運用として決めることです（この記事での整理）。

サービスの利用地域が限られているなら、アクセス元の地域を制限する（→「上記の他、汎用的な対策（7つ）」）
Web サーバーなどが侵害されたあとの、横展開の対策を見直す（→「上記の他、汎用的な対策（7つ）」）
不正アクセスを検知する体制の点検と、検知したときの初動対応を見直す（→「上記の他、汎用的な対策（7つ）」）
漏えいが起きたときに備えて、平時から顧客に、二次被害を防ぐための呼びかけ（多要素認証など）をしておく（→「上記の他、汎用的な対策（7つ）」）
ログに何を取り、どれだけの期間残すかを見直す（IPA が「そのあとに取り組む対策」に挙げている。→「IPA の注意喚起（10月9日）」）

全体の点検表は、Web 開発のセキュリティの基本にあります。

この記事で扱わないこと

攻撃元の IP アドレス、User-Agent、痕跡の文字列、攻撃の入口のパス、攻撃の手順。ログと照らすときは、注意喚起を直接見てください
注意喚起の参考情報に挙がっている民間企業のブログ
型ごとの対策。注意喚起に書かれていないので、結んでいません
9月の個別の事案の会社名、被害の件数、どの事案がどの型だったか。注意喚起に書かれていません
型 A と型 D、NoSQL インジェクション、SSRF、アプリに秘密を入れない設計の、詳しい防ぎ方。この回の記事では扱っていません。SSRF とアプリの秘密は、JPCERT/CC のブログが勧めていることを紹介するまでにしました。SSRF の守り方はSSRF の記事、アプリに秘密を入れない点は環境変数と .env の記事の「公開してよい鍵と、秘密の鍵（スマホアプリも解析される）」で説明しています
個人情報が漏れたときの、国への報告や本人への通知の手続き
NICT の詳しい PDF と、OWASP の個別のページ。この記事では読んでいません

よくある質問

2026年9月前後の一連の事案は、4 つの型のどれに当たりますか？

注意喚起には書かれていません。注意喚起は、すべての事案で同じ手口が使われたことを示すものではない、と断っています。

型 D の Web シェルは、どこから置かれたのですか？

注意喚起には書かれていません。書かれているのは、WAR ファイルが置かれる事案を確認していることと、中の JSP ファイルが簡易 Web シェルとして動くことです。入口が分からないので、この記事も推測しません。

まとめ

注意喚起 JPCERT-AT-2026-0030 は、2026年10月8日に公開、10月9日に更新された。「相次いでいます」と書き、把握している情報は限定的かつ断片的だと断っている。10月20日に開いた時点で、その後の更新は見つかっていない
4つの型は、A：既知の脆弱性の探索と管理不備、B：API 経由の不正な操作、C：Metabase の SQL インジェクションの脆弱性、D：Web シェルの設置（10月9日に追加）。すべての事案で同じ手口が使われたことを示すものではない
型 B は、ID の書き換え（IDOR・BOLA）とは書かれていない。NICT は、点検の1つに IDOR/BOLA を挙げている（NICT の言葉）
対策は、API 向けの6つと、汎用の7つ。型ごとの対策は書かれていない。従業員向けのシステムや BI ツールも点検の対象
参考情報（IV）は OWASP の2本と民間企業のブログ1本。JPCERT/CC のブログ・NICT・IPA は、注意喚起とは別に出た関連の資料
痕跡の一覧（IoC）は注意喚起にあり、時期の注記と、正規利用の可能性の注記がある。ログの見方は IPA の文書に、Metabase の確かめは at260023 にある
型ごとの記事は、B：認証と認可、C：SQL インジェクション、全体：Web 開発のセキュリティの基本。AI の話はAI を悪用した攻撃の記事、アプリに秘密を入れない点は環境変数と .env の記事、NoSQL インジェクションはSQL 以外のインジェクションの記事、SSRF はSSRF の記事、回数の制限はレートリミットの記事、脆弱性の知らせの読み方は脆弱性の知らせの記事