JPCERT/CC注意喚起を読み解く — アプリ解析でAPIを直接叩く不正アクセスとMetabase SQLi
はじめに
2026年10月8日、JPCERT/CC が「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030）を公開しました。はてなブックマークでは600を超えるブックマークを集めており、関心の高さがうかがえます。
この注意喚起で目を引くのは、特定の製品の脆弱性ひとつを警告するものではない点です。複数の組織が、それぞれ異なる手口で被害を受けています。中でも、スマートフォンアプリを解析して API を直接呼び出す手口は、アプリ開発者にとって他人事ではありません。
この記事では、注意喚起に書かれた3つの攻撃パターンを整理します。そのうえで、なぜ「画面からはできない操作」が API からはできてしまうのかを説明し、開発の現場で何を見直せばよいかを考えます。
注意喚起の内容 — 3つの攻撃パターン
JPCERT/CC によると、2026年9月前後から国内組織で不正アクセスによる個人情報の漏えいが相次いでいます。被害に遭ったシステムには、一般向けの EC サイトだけでなく、BI ツールや従業員向けの管理システムのように「不特定多数の利用者からのアクセスを想定していないシステム」も含まれています。
確認されている手口は、大きく次の3つに分けられています。
ケースA：既知脆弱性の探索と悪用 攻撃者は1つの脆弱性を狙い撃ちするのではなく、標的ごとにさまざまな既知の脆弱性をスキャンしています。さらに、環境設定ファイルやバックアップファイルの窃取のように、脆弱性ではない管理上の不備も悪用されています。
ケースB：API 経由の不正操作
スマートフォンアプリを解析して API のエンドポイントとキーを特定し、本来は画面から実行できない内部 API を呼び出す手口です。ユーザー権限の変更や不正なアカウントの作成のほか、ヘッダーの有無や不正な形式の認証トークンで応答がどう変わるかを探る試行、NoSQL インジェクションでアカウント情報を探す手口が報告されています。他のシステムから盗んだ API キーが使われた例もあります。User-Agent には curl/7.88.1 や python-requests が記録されていました。
ケースC：Metabase の SQL インジェクション（CVE-2026-72898） OSS の BI ツール Metabase の脆弱性です。8月6日に公表されましたが、8月2日の時点でゼロデイとして悪用された形跡があります。認証なしで細工したリクエストを送ると、Metabase のアプリケーション DB に任意の SQL を実行でき、管理者権限を奪えます。影響を受けるのは 58.x〜63.x 系の修正前のバージョンで、Metabase Cloud は修正済みです。
技術的な背景 — なぜ「画面にない操作」が通ってしまうのか
ケースBの根本にあるのは、アクセス制御をクライアント側に頼った設計です。
アプリの画面に「権限変更」ボタンがなければ、利用者はその操作をできないように見えます。しかし、サーバー側の API が「リクエストを送ってきたユーザーにその操作が許されているか」を確かめていなければ、curl で同じリクエストを組み立てるだけで実行できてしまいます。画面は API の使い方の一例を見せているだけで、防御にはなりません。
JPCERT/CC も参考情報として挙げている OWASP API Security Top 10（2023年版）には、この問題に関わる項目が並んでいます。
- API1: Broken Object Level Authorization（BOLA） — ID を書き換えると他人のデータを取得できる
- API3: Broken Object Property Level Authorization — 返してはいけない項目までレスポンスに含まれている、または書き換えてはいけない項目（role など）を更新できる
- API5: Broken Function Level Authorization — 一般ユーザーが管理者用の機能を呼び出せる
注意喚起は手口と OWASP の項目を対応づけてはいませんが、筆者の見立てでは、ユーザー権限の変更は API3 や API5、他人のデータの取得は API1 の典型例です。
アプリの解析も、攻撃者にとって難しい作業ではありません。ネイティブアプリでも Flutter アプリでも、バイナリに埋め込んだ API のベース URL やキーは、文字列の抽出や専用の解析ツールで取り出せます。難読化は解析の手間を増やしますが、取り出されることを防ぐものではありません。アプリに埋め込んだ値は公開されているものとして扱うのが前提です。
マクニカ セキュリティ研究センターの分析も、この傾向を裏付けています。2024年1月から2026年10月6日までに公表された Web システムの漏えい事案265件を調べたところ、年別では2024年が62件、2025年が84件でしたが、2026年は10月6日までで119件にのぼり、そのうち81件（68%）が7月以降の公表でした。その81件のうち、ソフトウェア脆弱性の悪用とされたのは9件（11.1%）にとどまり、65件（80.2%）は原因の説明が不十分だったといいます。図書館の蔵書検索や大学の施設予約のような、攻撃対象になりそうにないシステムも被害に遭っています。
エンジニアへの影響 — 何を見直すべきか
アプリと API を開発している人が、まず確認したいのは次の点です。
- すべてのエンドポイントで、サーバー側の認可チェックをしているか 「画面から呼ばれない API」ほどチェックが抜けやすくなります。管理系や社内向けの API が、一般ユーザーのトークンで呼べてしまわないかを確認します。
- 更新系 API が受け付ける項目を絞っているか
リクエストボディをそのまま DB に反映する実装では、
roleやisAdminを書き換えられます。更新を許可する項目を明示的に列挙します。 - レスポンスに不要な項目を含めていないか 画面に表示しないだけで、レスポンスには生年月日や住所が含まれている、という状態は漏えいの原因になります。
- アプリに埋め込んだキーで、何ができてしまうか 埋め込みキーには最小限の権限だけを与えます。Firebase を使っている場合は、API キーではなく Security Rules と App Check で守る設計になっているかを見直す機会です。
- レート制限と異常検知
JPCERT/CC は、単位時間あたりのリクエスト数の制限に加え、ログイン・パスワードリセット・SMS 送信・検索のような悪用リスクの高い機能への個別の制限を挙げています。API トークンの有効期限を短くし、漏えいが疑われたらすぐ無効化できるようにしておくことも対策に含まれています。
python-requestsやcurlの User-Agent からの大量アクセスは、アクセスログで見つけやすい兆候です。
社内で Metabase を運用している場合は、修正版への更新が最優先です。すぐに更新できなければ、暫定策として /api/session/reset_password へのアクセスを遮断します。侵害の痕跡としては、このエンドポイントへの POST（HTTP 400）に続いて /api/user/current への GET（HTTP 200）が記録されているパターンが挙げられています。痕跡が見つかった場合は、セッション、API キー、管理者の認証情報、接続先 DB の認証情報をすべてリセットする必要があります。
「社内向けだから」「アプリからしか呼ばれないから」という理由で、公開を前提にした防御を省いてよいことにはなりません。注意喚起にある「不要なサービス・機能の公開停止」と「保存期限を超えたデータの削除」は地味な対策ですが、漏えいしたときの被害を確実に小さくできます。
まとめ
- JPCERT/CC が、2026年9月前後から続く国内の不正アクセスについて注意喚起を出した
- 手口は「既知脆弱性の探索」「アプリ解析による API の直接操作」「Metabase SQLi（CVE-2026-72898）」の3つ
- API の不正操作は、サーバー側の認可チェックが抜けていることが根本原因。画面にボタンがないことは防御にならない
- アプリに埋め込んだキーや URL は取り出される前提で設計し、権限を最小限にする
漏えいの公表件数は2026年7月以降に急増しています。自社の API が OWASP API Top 10 の上位項目に当てはまらないか、一度点検しておく価値があります。