公開 MCP サーバが標的に｜AI 開発者を狙い撃つ走査を SANS ISC が観測

2026 年 7 月 13 日、SANS Internet Storm Center（ISC）のハンドラー Manuel Humberto Santander Peláez 氏が、ある小規模 Web ホストの Apache／ModSecurity ログ 14 日分を分析し、公開された MCP サーバと AI アシスタントの資格情報を狙う体系的な走査を検出したと報告した（diary #33150）。単なる無差別スキャンではない。走査元は正規の JSON-RPC 2.0 ハンドシェイクを試み、Claude・Cursor・VSCode の設定ファイルを名指しで探索し、未認証の LLM エンドポイントとクラウドメタデータ SSRF まで狙っていた。AI 開発者が使う MCP サーバそのものが、攻撃者の偵察対象リストに正式に載ったことを示す観測だ。

MCP サーバの基礎と構築手順は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル をご覧ください。本記事はその「公開したあとに何が起きるか」を扱う。

30秒で分かるポイント

まず「自分は関係あるのか」を切り分けたい。以下のいずれかに当てはまるなら、本記事の確認コマンドを今日中に実行する価値がある。

・MCP サーバを HTTP／SSE トランスポートで 0.0.0.0 にバインドし、外部から到達できる状態にしている
・Cursor・Claude Code・VSCode の設定（.cursor/・.claude/・.vscode/）を、Web サーバのドキュメントルート配下や公開リポジトリに置いている
・OpenAI 互換 API（/v1/models）や Ollama（/api/tags）を認証なしで外部公開している
・クラウド VM 上で「URL を受け取って取得する」機能（プロキシ・プレビュー・Webhook 変換など）を動かしている

逆に、MCP をローカルの stdio トランスポートだけで使い、設定ファイルをホームディレクトリの外に出していないなら、今回の走査の直接の標的にはなりにくい。それでも設定ファイルへの平文キー保存は別経路（サプライチェーン汚染）で読まれ得るため、後半の対策は目を通しておきたい。

本記事はこのあと、①観測の時系列、②SANS ISC が実際に見た走査の中身、③狙われる設定ファイルの正体、④自分のサーバを点検する 5 つのコマンド、⑤緊急・推奨・長期の対策、⑥構成別のリスク判定、の順に進む。手を動かして今日中に確認したいなら、時系列と観測の解説は飛ばして「自システムで確認する 5 つのコマンド」から読み、200 が返った入口を対策手順で塞ぐ、という使い方でも構わない。いずれにせよ攻撃 IP の追跡は不要で、必要なのは自分の入口を閉じる作業だけだ。

時系列：SANS ISC の観測タイムライン

今回の観測は突発的なものではなく、2026 年前半を通じて「AI 開発ツールの設定ファイルと資格情報」を狙う攻撃が積み上がってきた文脈の上にある。SANS ISC の観測日を軸に、関連する主要インシデントを並べると次のようになる（AI 設定ファイル標的化の流れは当サイトの既報に基づく）。

Nx Console 事件は「AI コーディングアシスタントの設定ファイルを標的にした世界初の既知攻撃」として記録された（詳細は Nx Console 18.95.0に悪性コード混入｜VS Code開発者6000人超が認証情報窃取マルウェアに感染）。今回の SANS ISC 観測はその延長線上にあり、サプライチェーン汚染（パッケージ経由）だけでなく、直接のネットワーク走査（インフラ経由）でも AI 資格情報が狙われ始めたことを意味する。攻撃面が「開発者のマシン」から「開発者が公開したサーバ」へと広がったのが節目だ。

なお、SANS が分析したのは単一の小規模ホスト 14 日分のログである。1 台でこれだけの AI 特化偵察が観測されたということは、インターネット全体では日常的に大量の走査が走っていると考えるのが自然だ。

この半年の流れが示すのは、「AI 開発環境を狙う攻撃ツールの成熟」だ。半年前まで AI 資格情報の窃取は、悪性 npm／PyPI パッケージに紛れ込ませるサプライチェーン型が中心だった。開発者が汚染パッケージをインストールして初めて発火する、いわば「待ち」の攻撃である。今回の走査はそこに能動的なネットワーク偵察が加わったことを意味する。攻撃者はもう、開発者がミスを踏むのを待つだけでなく、公開されたサーバを自分から探しに来ている。MCP の普及で「AI に外部リソースへの手足を与えたサーバ」がインターネット上に増えたことが、この攻撃面を経済的に「割に合う」ものにした。標的の母数が増えれば、専用の走査ツールを回す価値が生まれる──今まさにその閾値を越えたと見るべきだ。

何が起きているのか：SANS ISC が観測した公開 MCP サーバ走査

SANS の観測で最も重要なのは、走査の「質」だ。無差別なポートスキャンではなく、MCP というプロトコルを理解した挙動が確認されている。

・正規の JSON-RPC 2.0 ハンドシェイク：走査元は MCP の初期化リクエストを正しい形式で送り、プロトコルバージョン 2025-03-26 を指定していた。これは MCP のリリース済み仕様バージョンで、「MCP サーバかどうか」を確かめて話しかけている証拠だ。無反応なポートに投げつけているのではない。
・49 の異なる送信元 IP：MCP ハンドシェイクだけで 49 の IP が関与した。分散した偵察であり、単一ホストの実験ではない。
・約 200 件の AI 特化偵察リクエスト：MCP・LLM・設定ファイルを狙うリクエストが合計で約 200 件観測された（全体の量としては Spring Boot Actuator 狙いの走査が最多だったが、AI 標的が独立したカテゴリとして立ち上がっている点が新しい）。

なぜ「プロトコルバージョン 2025-03-26 を指定していた」ことが重要なのか。ポートスキャナが無反応な穴に総当たりで投げているだけなら、プロトコルの中身を正しく組み立てる必要はない。ところが今回の走査は、MCP の初期化メッセージを仕様通りに作り、バージョンまで合わせてきた。これは攻撃者側に「MCP サーバを見つけたら、まずツール一覧（capabilities）を引き出し、そこから到達できるリソースを把握する」という明確な目的とツールチェーンが存在することを意味する。防御側にとっては、逆に「正規のハンドシェイク形式」がそのまま検知シグネチャになる。ModSecurity のようなアプリ層 WAF は、POST /mcp に対する JSON-RPC 本文（"method":"initialize" など）や、短時間に多数の設定ファイルパスを順に叩くアクセスパターンをルール化して警告できる。走査を「止める」前に、まず「見える化」するのが第一歩だ。

MCP がなぜ狙われるのか、その前提を一言で言えば「MCP は AI に外部の手足を与えるプロトコル」だからだ（仕組みは MCPとは何か？AIに手足を与えるプロトコルの仕組みと実践ガイド2026 を参照）。MCP サーバはファイル・DB・API・クラウドといったリソースへのゲートウェイになる。ここに無認証で到達できれば、攻撃者は「AI に許された操作」をそのまま乗っ取れる可能性がある。

走査は MCP エンドポイントだけでなく、複数の入口を同時に叩いていた。全体像を defensive に俯瞰すると次のようになる。

未認証 LLM エンドポイント：/v1/models と /api/tags

走査は 2 種類の LLM API 入口を叩いていた。

・GET /v1/models：OpenAI 互換 API のモデル一覧エンドポイント。vLLM・LM Studio・LocalAI・text-generation-webui など多くのローカル推論サーバが実装する。認証なしで応答すれば、攻撃者はそのまま /v1/chat/completions を叩いてあなたの GPU と API クレジットをタダ乗りできる。
・GET /api/tags：Ollama のインストール済みモデル一覧エンドポイント。Ollama は既定で 127.0.0.1 にバインドするが、OLLAMA_HOST=0.0.0.0 で公開している例が後を絶たない。公開 Ollama は無料の推論リソースとして悪用され、過去には GGUF 解析の脆弱性（CVE-2026-7482 など）も報告されている。

クラウドメタデータ SSRF：169.254.169.254

走査には、/fetch?url=・/fetch?uri=・/fetch?path=・/fetch?dest= といったパラメータで http://metadata.google.internal/（実体は 169.254.169.254）へアクセスさせようとする SSRF 試行が含まれていた。これは「URL を受け取ってサーバ側で取得する」機能を持つアプリ（プロキシ、リンクプレビュー、Webhook 変換、そして一部の MCP サーバのフェッチ系ツール）を悪用し、クラウド VM のメタデータサービスから一時的なサービスアカウントトークンを盗み出す典型的な手口だ。

MCP サーバは「URL を渡すと内容を取ってくる」種類のツール（Web フェッチ、スクレイピング、リンクプレビュー生成など）を実装しがちで、SSRF の温床になりやすい。AI 経由でメタデータトークンを引き出せれば、攻撃者はクラウド権限をそのまま奪える。

ここまでの 4 つ──公開 MCP サーバ、設定ファイル、未認証 LLM エンドポイント、クラウドメタデータ SSRF──は、別々の脆弱性ではなくひとつの偵察で束ねて狙われている点が今回の観測の核心だ。攻撃者から見れば、どれか 1 つでも当たれば足がかりになる。MCP サーバが無認証なら操作を乗っ取れる。設定ファイルが読めれば鍵が手に入る。LLM が丸見えなら計算資源をタダ乗りできる。SSRF が通ればクラウドごと奪える。だからこそ防御も「どれか 1 つ」ではなく、4 つすべての入口を閉じることが要る。次章の確認コマンドは、この 4 レイヤを漏れなく点検できるように並べてある。

狙われる MCP／AI 設定ファイルの位置と中身

攻撃者が名指しで探していた設定ファイルは、いずれもAI 開発ツールが認証情報を書き込む場所だ。ファイルごとに「何が入っているか」「なぜ危険か」を整理する。

特に危険なのが .claude/.credentials.json だ。macOS では Claude Code の資格情報は OS のキーチェーンに保管されるが、Linux では ~/.claude/.credentials.json に OAuth トークンが平文で置かれる。このファイルが Web から読めれば、攻撃者は API キーすら要らずにアカウント権限を握れる。走査が HEAD /.claude/.credentials.json を投げていたのは、まさにこのファイルの存在確認だ。

なぜこれらが Web から見えてしまうのか。主な原因は 3 つある。

・リポジトリごとドキュメントルートに配置：git clone したプロジェクトをそのまま /var/www 配下などで配信し、.claude/・.cursor/・.git/ まで一緒に公開してしまう。
・ドットファイルを配信するミス設定：多くの Web サーバは既定で . 始まりのファイルを配信し得る。明示的に拒否していないと /.claude/mcp.json が 200 で返る。
・MCP サーバの無認証公開：HTTP/SSE トランスポートを 0.0.0.0 で listen し、POST /mcp に誰でも到達できる。

走査が HEAD /.claude/.credentials.json のように HEAD メソッドを使っていた点にも意味がある。HEAD はレスポンス本文を返さずステータスコードとヘッダだけを返すため、攻撃者は「ファイルが存在するか（200 か 404 か）」を最小の通信量で高速に確かめられる。存在が分かったファイルだけを、後から本文取得（GET）に切り替えればよい。つまり今回の走査は、無数のホストを安く広くふるいにかけ、「当たり」だけを深掘りする効率重視の偵察だ。裏を返せば、防御側は 1 台でも .credentials.json を 200 で返した瞬間に、その後の集中攻撃を呼び込む。存在確認の段階で 404／403 を返すことが、そのまま深掘りの回避になる。

MCP の資格情報そのものを狙う攻撃としては、通信経路のハイジャックによる OAuth トークン窃取も報告されている（Claude CodeのMCP通信ハイジャックでOAuthトークンが窃取される攻撃｜検知・対応・防御の手順）。今回の「設定ファイルを直接読む」走査と合わせて、MCP 周辺のトークンは複数経路で狙われていると考えるべきだ。

自システムで確認する5つのコマンド

ここが本記事の実務パートだ。攻撃 IP を追うのではなく、自分のサーバが”うっかり応答していないか”を自分で確かめるためのコマンドを 5 つ挙げる。いずれも自分の管理下のホストに対して実行する前提の、防御目的の点検である。他人のサーバに向けて実行する行為は不正アクセスにあたり得るため、対象は必ず自分が権限を持つホストに限ること。

コマンドはすべて読み取り専用の観測で、設定を破壊的に変更しない（②の chmod 600 のみ権限を絞る安全な変更）。定期実行するなら、デプロイ後の CI や日次の cron に組み込み、http_code が想定外（設定ファイルに 200、LLM エンドポイントに 200）を返したらアラートを上げる形にしておくと、構成変更で穴が空いた瞬間に気づける。以下、5 つを順に見ていく。

① 公開している MCP サーバ・LLM ポートを洗い出す

まず自ホストで何が listen しているかを確認する。MCP や推論サーバがよく使うポート（3000/3001/8000/8080/11434 など）と、mcp を含むプロセスを見る。

# LISTEN 中のポートとプロセス（MCP / LLM でよく使う番号を抽出）
ss -tlnp | grep -E ':(3000|3001|8000|8080|8787|11434)\b'

# MCP 関連プロセスの確認
ps aux | grep -i -E 'mcp|ollama|vllm|llama' | grep -v grep

0.0.0.0:* で listen しているものは外部到達可能を意味する。127.0.0.1 に閉じていれば公開はされていない。

② AI 設定ファイルの場所と権限を確認する

Cursor・Claude Code の設定ファイルが存在するか、パーミッションが緩すぎないかを見る。

# 設定ファイルの存在とパーミッション
ls -la ~/.cursor/mcp.json ~/.claude/ ~/.vscode/mcp.json 2>/dev/null
stat -c '%A %n' ~/.cursor/* ~/.claude/.credentials.json 2>/dev/null

# 資格情報ファイルは所有者のみ読み取り（600）が望ましい
chmod 600 ~/.claude/.credentials.json 2>/dev/null

.credentials.json が -rw-r--r--（644）のように他ユーザーから読める場合は 600 に絞る。

③ 外部から設定ファイルが見えていないかテストする

別ネットワーク（スマホのテザリング等）から、自分の公開ホストに対して設定ファイルを要求してみる。200 が返ったら漏洩している。

# 期待値は 403 か 404。200 が返ったら即対処
for p in /.claude/mcp.json /.cursor/mcp.json /.vscode/mcp.json /.claude/.credentials.json; do
  echo -n "$p -> "; curl -s -o /dev/null -w '%{http_code}\n' "https://あなたのホスト$p"
done

④ 未認証 LLM エンドポイントの応答を確認する

/v1/models と /api/tags が認証なしで応答していないかを外部からテストする。

# モデル一覧が中身付きで返ってきたら「無認証で丸見え」
curl -s -o /dev/null -w '%{http_code}\n' "https://あなたのホスト/v1/models"
curl -s -o /dev/null -w '%{http_code}\n' "http://あなたのホスト:11434/api/tags"

⑤ ファイアウォールとメタデータ egress を確認する

インバウンドのファイアウォール状態と、クラウドメタデータ（169.254.169.254）への egress が塞がれているかを見る。

# インバウンドの許可状況
sudo ufw status verbose 2>/dev/null || sudo iptables -L INPUT -n --line-numbers

# メタデータへの到達可否（タイムアウトすれば egress 遮断済みで良好）
curl -s --max-time 3 -H 'Metadata-Flavor: Google' \
  http://169.254.169.254/computeMetadata/v1/ -o /dev/null -w '%{http_code}\n' || echo "unreachable (good)"

加えて、既存のアクセスログから偵察の痕跡を洗うなら、SANS が挙げたシグネチャで grep するのが早い。

# 過去ログから MCP / 設定ファイル / LLM 偵察を抽出（defensive）
grep -E 'POST /mcp|/sse|/\.claude/|/\.cursor/|/\.vscode/|/v1/models|/api/tags' \
  /var/log/nginx/access.log

対策手順（緊急・推奨・長期）：MCP サーバを認証前提に戻す

対策は緊急・推奨・長期の 3 段で考える。優先度の高い順に、確認コマンドで問題が出た箇所から潰す。

緊急（今日中）

・設定ファイルを Web から隔離：.claude/・.cursor/・.vscode/・.git/ をドキュメントルートの外へ移す。移せない場合は Web サーバでドットディレクトリを明示的に拒否する。
・平文で漏れた鍵をローテーション：確認コマンド③で 200 が返った場合、そのファイルに含まれる API キー・OAuth トークンは漏洩前提で即ローテーションする。
・無認証 MCP／LLM を非公開化：一時的にでも 127.0.0.1 バインドや IP 制限に切り替え、外部到達を止める。

Web サーバでドットファイルを拒否する最小設定は次の通り（nginx の例）。

# .claude / .cursor / .vscode / .git などドットディレクトリを一律拒否
location ~ /\.(claude|cursor|vscode|git|mcp) {
    deny all;
    return 404;
}

推奨（今週中）

・MCP サーバに認証を必須化：MCP 仕様は認可を OPTIONAL としつつ、HTTP 系トランスポートには OAuth 2.1 準拠を求めている。最低限、Bearer トークン未提示のリクエストには 401 Unauthorized を返す。
・逆プロキシ＋ IP allowlist：MCP／LLM エンドポイントを直接公開せず、リバースプロキシ経由にして接続元 IP を絞る。
・レート制限：連続したハンドシェイクや設定ファイル探索のコストを上げ、走査を非効率化する。

MCP 仕様が期待する「未認証は 401」という応答を、逆プロキシ層で担保する動きは次のイメージだ。

逆プロキシで未認証を弾き、レート制限をかける最小例（nginx）。

# 1 分あたり 30 リクエストに制限（走査の連打を抑制）
limit_req_zone $binary_remote_addr zone=mcp:10m rate=30r/m;

location /mcp {
    limit_req zone=mcp burst=10 nodelay;
    # Bearer ヘッダが無ければ 401（アプリ側でも必ず検証すること）
    if ($http_authorization = "") { return 401; }
    proxy_pass http://127.0.0.1:8080;
}

長期（恒久対策）

・クラウドメタデータの保護：AWS は IMDSv2（セッショントークン必須）を強制し、IMDSv1 を無効化する。GCP はメタデータサーバ v1 のヘッダ強制（Metadata-Flavor: Google 必須）を有効にし、アプリからメタデータ IP への egress を遮断する。これで SSRF 経由のトークン窃取を封じる。
・シークレットをファイルから追い出す：API キーを設定ファイルに直書きせず、環境変数やシークレットマネージャで注入する。設定ファイルが読まれても鍵が入っていない状態にする。
・MCP トランスポートの見直し：外部公開が不要なら stdio（ローカル）に寄せる。MCP 仕様も stdio では「資格情報を環境から取得する」ことを求めており、ネットワーク露出を根本から減らせる。トランスポート設計の落とし穴は MCP脆弱性！STDIOトランスポートの設計欠陥で20万台のサーバーがRCEの危険に——OX Securityが警告 も参考になる。
・継続的な監視とアラート：一度塞いでも、構成変更や新しいサービス追加で穴は再発する。設定ファイルへの外部アクセス（/.claude/ などへの 200 応答）、POST /mcp の急増、/v1/models・/api/tags への外部到達を監視対象にし、閾値を超えたら通知する。走査そのものは止められない前提で、「応答が変わった」ことを検知できる状態を維持する。

万一、確認コマンド③④で設定ファイルや LLM エンドポイントが外部から丸見えだった場合の初動は、順序が重要だ。①まず該当ファイルに含まれる API キー・OAuth トークンを漏洩前提でローテーション（ネットワークを切る前に、鍵の無効化を先に行う）→②設定ファイルを Web 配信から外す／エンドポイントを非公開化→③直近のアクセスログを遡り、その鍵で不審な API 利用・クラウド操作がなかったかを監査、という流れで対応する。鍵の無効化を後回しにすると、対処中にも窃取済みのトークンで悪用が続く恐れがある。Claude Code の OAuth トークンが漏れた疑いがあるなら、アカウント側でのセッション失効・再認証も併せて行う。

影響範囲マトリクスと他のAI開発ツールの露出度

「自分の構成はどのリスク帯か」を素早く判定できるよう、MCP サーバ種別 × 認証方式 × 公開範囲でリスクを整理する。

判定の軸はシンプルだ。「無認証」かつ「外部到達可能」なら高リスク、そこに「設定ファイルの Web 露出」が重なれば致命的、という順で優先度を付ければよい。表の下ほど危険度が上がり、対処の優先順位も下の行から着手する。「低」帯の stdio 構成は MCP 仕様が推奨する形そのものであり、ここに収まっているなら今回の走査に対しては実質的に無防備な入口を持たない。逆に、最下段の「設定ファイルが Web 配信下」は、認証の有無を問わず即座に鍵が漏れるため、他のどの対策よりも先に潰すべき最優先事項になる。自分の構成がどの行に該当するかを、確認コマンドの結果と突き合わせて特定するところから始めたい。

他の AI 開発ツールの露出度

走査が /.vscode/mcp.json のような汎用パスを叩いていた点は見逃せない。このパスは VS Code 系のツールが広く共有するため、Claude Code・Cursor 以外のツールも間接的に射程に入る。

本質は「AI ツールが資格情報をどこに、どの形式で保存し、それが到達可能な場所に漏れていないか」に尽きる。ツール名で安心・不安を判断するのではなく、保管場所と公開範囲を点検するのが正しい。MCP 開発者を狙う攻撃は供給網側でも進行しており（Shai-Hulud派生「Hades」がMCP開発者を標的に｜PyPI汚染とIronWorm併発の供給網ワーム総まとめ）、ネットワーク走査と合わせて多層で狙われている前提で守りたい。

誤解しやすい 3 つのポイント

まとめ：今回の SANS ISC 観測が突きつけたのは、「MCP サーバや AI 設定は、公開した瞬間に偵察対象になる」という現実だ。攻撃者はプロトコルを理解し、設定ファイルを名指しで探し、SSRF でクラウドまで狙う。だが防御側の打ち手は明確で、①設定ファイルを Web から隔離、②未認証に 401、③逆プロキシと IP 制限、④レート制限、⑤メタデータ egress 遮断──の 5 点に集約される。攻撃 IP のブロックに労力を割くより、「自分が応答してしまう入口」を一つずつ閉じる方が確実だ。まずは本記事の 5 コマンドで現状を可視化し、200 が返る箇所から潰していこう。サプライチェーン全体の防御設計は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト も併せて確認してほしい。

参照ソース

・SANS ISC Diary #33150 — Someone Is Scanning for Your MCP Servers and AI Assistant Credentials（2026-07-13、Manuel Humberto Santander Peláez）
・Model Context Protocol — Authorization 仕様（2025-03-26）
・Model Context Protocol 公式リポジトリ（modelcontextprotocol/modelcontextprotocol）
・Google Cloud — VM メタデータサーバのセキュリティ（Metadata-Flavor ヘッダ強制）
・AWS — Instance Metadata Service（IMDSv2）