Claude CodeのMCP通信ハイジャックでOAuthトークンが窃取される攻撃｜検知・対応・防御の手順

2026年6月、クラウドインシデント対応企業のMitigaが、AIコーディングエージェントClaude Codeを狙う新しい攻撃手法を公表した。悪性npmパッケージを入り口に、Claude Codeのローカル設定ファイル~/.claude.jsonを書き換えてMCP（Model Context Protocol）通信を攻撃者のプロキシ経由に誘導し、接続先SaaSへのOAuthトークンを平文のまま窃取するというものだ。報道はこれを「MCP通信のハイジャック」として大きく扱ったが、Anthropicはこの挙動を「設計上のもの・脆弱性報奨金の対象外」と分類している。本記事では、報道と公式見解の差分を整理したうえで、自分の環境が影響を受けるかの確認・検知・対応の手順を解説する。

AIエージェント時代のセキュリティ全体像を整理したい方は、ピラー記事AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドを先に読むと、本記事の位置づけがつかみやすい。

30秒で理解する — 事象・影響範囲・対応

まず要点だけを押さえる。今回の件は、単一のソフトウェアバグではなく、Claude Codeの信頼モデルとローカル設定ファイルの設計が組み合わさったときに成立する攻撃手法である。

・事象: 攻撃者がローカルでコード実行できる状態を起点に、~/.claude.jsonのmcpServersを攻撃者プロキシに書き換え、MCP通信を中間者（MitM）として傍受。OAuthベアラートークンを窃取する
・影響範囲: OAuth対応MCPサーバ（Atlassian Jira/Confluence等のSaaS）をClaude Codeに接続している開発環境。窃取されたトークンは長寿命・広範囲スコープ・自動更新で、永続アクセスにつながる
・前提条件: ユーザー権限のコード実行（悪性npmパッケージのpostinstallフック、信頼できないリポジトリのクローンなど）。リモートから一方的に成立する種類の攻撃ではない
・公式見解: Anthropicは「対象外（out of scope）」と分類。CVE採番なし、パッチ予定なし。報道（gbhackers等）が「ハイジャック攻撃」と強調する一方、ベンダーは「設計上の挙動」と位置づけている
・対応: パッチを待つ対応は成立しない。~/.claude.jsonの整合性監視、MCPエンドポイントのベースライン化、悪性フックの除去を「ローテーションより先に」行う

この記事は、攻撃の具体的なペイロードは扱わず、検知・除去・対応・防御のコマンドと手順のみを示す。「自分の環境は大丈夫か」を最短で判定し、侵害が疑われる場合の正しい初動までを一本で完結させることを目的にしている。

何が起きたか — Mitigaが公表したMCP通信ハイジャック

事の起点は、Mitiga Labsが公開した技術レポートと、それを報じたgbhackers.com（2026年6月）である。Mitigaは、Claude CodeがすべてのMCP通信の経路情報とOAuthトークンを保存するグローバル設定ファイル~/.claude.jsonに着目した。

このファイルはユーザー書き込み可能で、しかもOAuthトークンを平文で保存している。Mitigaは、この一点を突いて、MCP通信を攻撃者のプロキシに迂回させる中間者攻撃が成立することを実証した。中間者（MitM）プロキシには、開発者がデバッグ用途で広く使うmitmproxyのような正規ツールがそのまま転用される。つまり攻撃者は特殊なマルウェアを書く必要すらなく、設定ファイルの1行を書き換えてトラフィックの通り道に割り込むだけでよい。

ここで効いてくるのが、MCPがOAuthという「正規の認可フロー」に乗っている点だ。通常、OAuthはユーザーの明示的な同意とリダイレクトを経て安全にトークンを発行する仕組みだが、その同意とトークンの保管場所がローカルの平文ファイルに集約されていると、ローカルを取られた瞬間に認可の前提そのものが崩れる。Mitigaが「設計の弱点」と表現するのはこの構造を指している。

公表されたタイムラインは次の通りだ。2026年3月23日に手法を発見、4月1日に検証を完了、4月10日にAnthropicへ報告した。Anthropicは4月11日に受領を確認し、4月12日に「対象外（out of scope）」と回答している。

ここで報道と公式見解の差分が生まれる。gbhackersやSecurityWeekなどの報道は、これを「OAuthトークンを盗む隠密なMCPハイジャック」として深刻に扱った。一方Anthropicは「マシン上でコード実行ができる時点で多くのことが可能であり、グローバル設定ファイルがClaude Codeの権限の大半を担うのは設計上の挙動だ」として、脆弱性とは位置づけていない。本記事は両者を併記し、読者が自分でリスクを評価できる材料を提供する立場を取る。

この攻撃は、AIエージェントが抱える信頼境界の問題を具体化したものだ。LLMアプリの認証・トークンの守り方を体系的に押さえたい場合は、トークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターンも参照してほしい。また、入り口となる悪性npmパッケージの手口は、OpenAI Codexを狙うnpmサプライチェーン攻撃｜codexui-android偽パッケージの検知と対応と共通の構造を持つ。

攻撃手口の詳細 — 5ステップの攻撃チェーン

Mitigaが示した攻撃チェーンは、大きく5つの段階に分かれる。全体像を俯瞰すると、次の流れになる。

各段階を言葉で追うと、次のようになる。

・（1）配送（Delivery）: 一見正常なnpmパッケージにpostinstallライフサイクルフックを仕込む。インストール時に自動実行される、よく知られたサプライチェーン攻撃の手口だ
・（2）信頼の事前注入（Path seeding）: フックが~/.claude.jsonを編集し、プロジェクトディレクトリに"trust": trueを書き込む。これにより、本来表示されるはずの同意プロンプトがバイパスされる
・（3）設定書き換え（Repository clone）: リポジトリのクローンなどを契機に、mcpServersフィールドの正規エンドポイント（例：Atlassianのエンドポイント）を、攻撃者が用意したローカルプロキシのアドレスへ書き換える
・（4）実行（Execution）: 次にClaude CodeがMCPセッションを開始・更新すると、設定ファイルからURLを読み込み、正規サーバではなく攻撃者プロキシ（例：mitmproxy）へ接続する。OAuthフローで得られるベアラートークンが攻撃者の経路を通過する
・（5）永続化（Persistence）: フックはClaude Codeが起動するたびに再実行され、設定をリセットし続ける。つまり一度仕込まれると、ユーザーが手で直しても元に戻される

精密なトークン傍受のシーケンスは、図にすると分岐とメッセージ順が重要になるため、ここではMermaidのまま示す。

重要なのは、この通信が正常に成立する点だ。プロキシはトークンを記録したうえで正規サーバへ中継するため、Claude Codeの動作は通常どおりに見える。ユーザーが体感する異常がないまま、トークンだけが抜かれていく。

なぜ Claude Code / MCP が狙われるのか

なぜAIコーディングエージェントが、この種の攻撃の標的になるのか。背景には、MCPという仕組みが持つ「高権限・広範囲」の性質がある。MCPの基本的な仕組みはMCPサーバーとは｜仕組み・代表的なサーバー一覧・自作手順を2026年最新で解説に詳しいが、要点は「LLMエージェントに任意の外部ツール・SaaSへのアクセスを与える共通プロトコル」だということだ。

この性質が、攻撃者にとって魅力的な4つの条件を生む。

・長寿命（Persistent）: OAuthトークンは再利用のために保存され、リフレッシュトークンによって無期限に更新できる。一度盗めば長期間使える
・広範囲スコープ（Broadly scoped）: 呼び出しごとに権限を絞らず、最初に要求した権限をそのまま引き継ぐ。1つのトークンで広い操作ができてしまう
・弱い保存（Weakly stored）: ~/.claude.jsonに平文で、trustフラグなどと同じファイル権限で同居している。ファイルを読めればトークンも読める
・サーバ側で区別困難（Unattributable）: トークンはAnthropicの信頼されたEgress IPレンジから提示されるため、接続先SaaSのログ上は正規利用に見える

つまり、IDEエージェントは「任意ツール実行」と「広範なSaaS権限」という二つの信頼を一手に握る。その信頼の鍵が、ユーザー書き込み可能なファイルに平文で置かれている——ここが狙われる構造的な理由だ。プロンプトインジェクションのようにLLMの判断を操る攻撃と異なり、今回は設定ファイルという「足場」を奪うタイプの攻撃である点が特徴だ（LLMの判断を操る攻撃はプロンプトインジェクションとは？攻撃手口・実例・防御策をLLM開発者向けに徹底解説｜OWASP LLM01を参照）。

影響範囲 — 対象・前提・修正状況

報道と公式見解、Mitigaの技術情報を突き合わせると、影響範囲は次の表のように整理できる。CVE番号や「修正バージョン」が存在しない点に注意してほしい。

なぜトークンローテーションが効かないのか

今回の最も実務的に重要なポイントが、これだ。侵害を検知したときの定番対応である「トークンのローテーション（失効＋再発行）」が、単独では効かない。

理由は永続化の仕組みにある。悪性フックはClaude Codeが起動するたびに~/.claude.jsonを書き換え直す。トークンを失効させても、次にClaude Codeを起動した時点で設定が再び攻撃者プロキシを指し、新しいOAuthリフレッシュがプロキシを経由する。結果として、ローテーションは攻撃者に新しい鍵を渡すだけになりかねない。

正しい順序は明確だ。（1）悪性フックの除去 →（2）設定ファイルの洗浄 →（3）トークンのローテーション →（4）正規エンドポイントの復元検証。フックを残したまま鍵だけ替えても、攻撃チェーンは切れない。

⚡ 対応確認の手順

ここからは、自分の環境が影響を受けているかを確認する具体的な手順を示す。すべて検知・確認のための読み取り操作で、攻撃を再現するものではない。

# Claude Code のバージョン確認
claude --version

# npm 経由で入れている場合は導入元とバージョンを確認
npm ls -g @anthropic-ai/claude-code 2>/dev/null

# mcpServers のエンドポイントだけを抽出して目視確認
cat ~/.claude.json | python3 -c "import sys,json; d=json.load(sys.stdin); print(json.dumps(d.get('mcpServers',{}), indent=2, ensure_ascii=False))"

# プロジェクト単位の設定も確認（リポジトリ直下）
cat .claude/config.json 2>/dev/null

# trust フラグが立っているプロジェクトを列挙
cat ~/.claude.json | python3 -c "import sys,json; d=json.load(sys.stdin); [print(k, v.get('trust')) for k,v in d.get('projects',{}).items() if isinstance(v,dict) and v.get('trust')]"

# 自動実行フック設定の有無を確認
grep -RnE "SessionStart|postinstall|hooks" ~/.claude.json .claude/ 2>/dev/null

# ~/.claude.json の最終更新時刻を確認（直近に書き換えられていないか）
ls -l ~/.claude.json

# 設定変更の差分を git 等で追っている場合は履歴を確認
git -C "$HOME" log --oneline -- .claude.json 2>/dev/null

⚙️ 対応・修正の手順

パッチが存在しないため、ここでの「修正」はソフトウェア更新ではなく、攻撃チェーンの遮断と設定の正常化を指す。順序が決定的に重要だ。

A. 悪性フックの除去を最優先で行う

何よりも先に、~/.claude.jsonや.claude/配下に仕込まれた自動実行フックと、それを設置した悪性npmパッケージを取り除く。これを飛ばすと、後続のローテーションが無効化される。

・身に覚えのないpostinstallフックを含むパッケージをnode_modulesから特定し削除
・package.json／lockfileを精査し、不審な依存を除去
・SessionStart等の自動実行フック設定を~/.claude.jsonから削除

B. 設定ファイルを洗浄し正規状態に戻す

フックを除去したうえで、設定ファイルを正規の状態に戻す。mcpServersのエンドポイントを公式URLへ修正し、不要な"trust": trueを外す。

# 念のため現状を保全（フォレンジック用）してから編集する
cp ~/.claude.json ~/.claude.json.bak.$(date +%Y%m%d%H%M%S)

# その後、mcpServers のURLを正規エンドポイントへ修正し、
# 不審な trust:true / hooks 設定を削除する（エディタで手動 or 設定再生成）

C. トークンをローテーションする（A・Bの後で）

ここで初めてOAuthトークンの失効・再発行を行う。接続先SaaSの管理画面から該当トークン／連携を失効させ、Claude Codeで再認証する。A・Bを終える前にこれをやってはいけない。

D. 正規エンドポイントの復元を検証する

再認証後、~/.claude.jsonのmcpServersが正規URLを指し続けているかを再確認する。起動直後に再び書き換わるようなら、フックが残存している証拠なのでAに戻る。

多層防御 — 再発を防ぐ運用

単発の対応で終わらせず、継続的に検知・抑止する仕組みを置く。AIエージェント環境の多層防御の考え方は前掲のピラー記事に詳しいが、本件に直接効く施策は次の4つだ。

・MCPサーバのallowlist化: 承認済みのMCPエンドポイントをベースライン化し、~/.claude.jsonがそれ以外を指したら検知する
・設定ファイルの整合性監視: ~/.claude.jsonとプロジェクト配下のMCP設定にファイル整合性監視（FIM）をかけ、想定外の変更を即アラートする
・権限スコープの最小化: MCPサーバに与えるOAuthスコープを業務に必要な最小限に絞る。1トークンで広範囲を触れる状態を避ける
・ログ監視: 新規localhostプロキシの出現、MCP URLの変更、OAuthリフレッシュの異常な頻度、SaaS側の異常な操作パターンを監視対象にする

これらの施策には優先順位がある。最初に効果が高いのは「設定ファイルの整合性監視」だ。攻撃の成否は~/.claude.jsonの書き換えが成立するかどうかにかかっているため、このファイルの変更を即座に捉えられれば、トークンが抜かれる前にチェーンを断てる可能性が高い。次に「allowlist化」で、たとえファイルが書き換えられてもエンドポイントの逸脱として検知できる。両者は補完関係にあり、片方だけでは取りこぼしが出る。

SaaS側の監視も軽視できない。窃取されたトークンはAnthropicの正規Egress IPから提示されるため、IPやUser-Agentだけでは正規利用と区別がつかない。鍵になるのは「行動の不一致」だ。普段はビジネスアワーにしかJiraを触らない開発者のトークンが深夜に大量のページを取得している、特定のConfluenceスペースに突然アクセスが集中する、といった業務パターンからの逸脱を、ユーザー単位のベースラインと突き合わせて検出する。AIエージェント経由のアクセスは正規利用でも機械的なパターンを描きやすいため、「正規のエージェント挙動」と「窃取トークンによる探索的挙動」を分けるベースライン作りが、検知精度を左右する。

過去の類似事案 — 同じ構造の攻撃が続いている

今回の攻撃は突発的なものではなく、「AI開発ツールの信頼境界と認証情報」を狙う一連の流れの中にある。

・Codex狙いのnpmサプライチェーン攻撃: 偽パッケージcodexui-androidがOpenAI Codexの認証情報を狙った事案。入り口が悪性npmパッケージである点が今回と共通する（詳細）
・MCP STDIOトランスポートの設計欠陥: MCPの別レイヤ（STDIOトランスポート）の設計問題で多数のサーバがRCEの危険にさらされた事案。MCPという共通基盤の信頼設計が問われた点で連続している
・プロンプトインジェクション全般: LLMの判断を操る攻撃。今回は「足場（設定ファイル）を奪う」タイプだが、いずれもAIエージェントの信頼境界を突く点で根は同じだ

共通する教訓は、「AI開発ツールはローカルマシンの信頼に強く依存しており、ローカルのコード実行を許した時点で広範なSaaS権限まで連鎖的に奪われ得る」ということだ。

企業向けチェックリスト

組織でClaude Codeを導入している場合、最低限おさえるべき項目を挙げる。

・利用実態の棚卸し: 全開発者のClaude Code利用状況と、接続中のMCPサーバ・連携SaaSを把握する
・MCPサーバのallowlist化: 承認済みエンドポイントを定義し、逸脱を検知・ブロックする仕組みを置く
・設定ファイル整合性監視の導入: ~/.claude.jsonをFIMの対象に含める
・OAuthスコープの最小化と棚卸し: MCP連携トークンのスコープと有効期限を見直す
・インシデント対応プレイブックの更新: 「フック除去 → 設定洗浄 → ローテーション → 復元検証」の順序を明文化し、ローテーション先行を禁止する
・npm依存の審査: postinstallフックを持つ依存の導入審査・スキャンを開発フローに組み込む

よくある落とし穴

最後に、対応時に陥りやすい誤解を3つ挙げる。

・「Anthropic公式のツールだから安全」: 今回の攻撃はClaude Code自体のバグではなく、ローカル設定の信頼設計を突くものだ。公式ツールであることは、ローカル侵害からの防御を意味しない
・「localhostだから安全」: 攻撃者プロキシはまさにlocalhostに立つ。MitMを想定せずローカル通信を無条件に信頼すると、書き換えられたエンドポイントを見逃す
・「トークンをローテーションすれば終わり」: 本記事の核心。フックが残っていればローテーションは攻撃者に新しい鍵を渡すだけになる。順序を守ること

参照ソース（一次ソース優先）

・Mitiga Labs（一次ソース）: Claude Code MCP Token Theft: MitM Attack Explained — 攻撃チェーン・タイムライン・推奨対応の原典
・報道（起点）: Hackers Exploit Claude Code MCP Traffic to Hijack（gbhackers.com）
・報道（裏取り）: Claude Code OAuth Tokens Can Be Stolen Through Stealthy MCP Hijacking（SecurityWeek）
・MCP公式仕様: Model Context Protocol — MCPのトランスポート・認証の仕様
・Claude Code公式: anthropics/claude-code（GitHub）