Claude CodeにはMCPセキュリティ問題がある——開発者たちはすでに使用中

Claude CodeはAnthropicのAIコーディングアシスタントで、開発者の間で急速に普及しているコマンドラインツールです。このツールは、AIがJira、Confluence、GitHub、データベース、社内APIと連携するための標準規格であるModel Context Protocol（MCP）を通じて外部サービスに接続します。開発者がいずれかのサービスを接続すると、Claude CodeはOAuthフローを実行し、ユーザーがスコープを承認すると、ツールはその後のすべてのリクエストに使用するベアラートークンを受け取ります。

そのトークンは、開発者のマシン上の設定ファイルにプレーンテキストで保存されています。そして研究者たちは、攻撃者がそのトークンを入手する方法を正確に実証しました。

研究者の発見

先週、 Mitiga Labsの研究者がアタックチェーンを公開しました。これは、Claude Codeを使っている開発者を抱えるすべてのセキュリティチームが懸念すべき内容です。攻撃は悪意のあるnpmパッケージから始まります——正規のユーティリティやラッパーに見せかけたものです。その中にはインストール中に無音で実行されるpost-installフックが仕込まれており、このフックが書き換えるのはたった1つのファイル、~/.claude.jsonです。

このファイルは、Claude CodeがMCPトラフィックをルーティングする方法を制御する要となる存在です。このファイルを書き換えることで、Claude Codeの認証済みリクエストを正規のサービスではなく攻撃者が管理するインフラに向けることができます。同ファイルに保存されているOAuthトークンは通信中に傍受されます。攻撃者は、開発者が接続していたあらゆるSaaSプラットフォーム（Jira、Confluence、GitHubなど、統合されていたもの）に対して有効な長期ベアラートークンを手に入れることになります。

これが特に検出困難な理由は、プロバイダー側の監査ログの見え方にあります。ログに記録されたIPアドレスはAnthropicの送信元IPレンジに解決されます。ユーザーは実在する人物です。セッションは有効です。 Mitigaが指摘しているように、そのログの行には間違った情報は何一つありません——しかし正しい情報も何一つありません。クエリを実行したのはユーザーではありません。トークンが本来の宛先に届く前に密かにリダイレクトされたトークンを使い、攻撃者が実行したのです。

Mitigaは4月10日にAnthropicへこの件を報告しました。 Anthropicは4月12日、この問題はスコープ外であると回答しました。ユーザーが同意してインストールしたパッケージを通じたコード実行を前提とする攻撃だ、という理由からです。本稿執筆時点でパッチは存在せず、アタックチェーンは現在も有効です。

これは初めてではない

Mitigaの情報開示は最も新しいものですが、Claude Codeの設定モデルがセキュリティ問題を引き起こしたのはこれが初めてではありません。

2026年2月、 Check Point Researchが2件の脆弱性に関する調査結果を公開しました。1件目のCVE-2025-59536は、リポジトリの設定ファイルに仕込まれた悪意のあるフックを通じてリモートコード実行を可能にするもので、ユーザーが信頼確認ダイアログを読む前にコードが実行されていました。2件目のCVE-2026-21852は、単一の環境変数を上書きすることでAPIキーの外部流出を可能にするもので、同意プロンプトが表示される前に認証済みトラフィックを攻撃者のインフラへリダイレクトするものでした。 信頼できないリポジトリをクローンして開くだけで、両方の脆弱性がトリガーされました。

AnthropicはCheck Pointの開示後、これらの脆弱性にパッチを適用しました。しかし、それらの脆弱性が示すパターン——セキュリティチームが受動的なメタデータとして扱っている設定ファイルが、実際にはアクティブな実行パスとして機能しているという問題——は、Mitigaの攻撃が悪用しているパターンと同じです。根本的なアーキテクチャがこの問題を生み出しているため、攻撃の仕組みは機能し続けています。

セキュリティチームが注目すべき理由

Adversary-in-the-Middle（AiTM）フィッシングについて読んだことがあれば、この手法は見覚えがあるはずです。AiTM攻撃は認証情報を直接盗むのではなく、ユーザーと正規サービスの間に割り込み、認証が成功するのを待ってから、それを証明するセッショントークンを持ち去ります。Claude CodeへのMitiga攻撃も同様の仕組みです。OAuthフローは正常に完了します。ユーザーはスコープを承認しました。トークンは有効です。ただ、トークンが本来の宛先に到達する前に、攻撃者がルーティング層に自分自身を割り込ませているのです。

AiTM攻撃との違いは、AiTMがブラウザセッションを標的にするのに対し、この攻撃は開発者ツールを標的にする点です。開発者ツールは、ほとんどのブラウザセッションよりもソースコード、社内API、クラウドインフラ、本番システムに近い位置にあります。

Claude Codeの採用は加速しています。開発者がインストールするのは、ワークフローを実際に改善してくれるからです。彼らは毎日使うツールに接続します。そのほとんどは、npm依存関係のpost-installスクリプトがローカルの設定ファイルに何をしているかを意識していません。これは意識の欠如ではなく、不合理な期待です。代わりに、セキュリティチームがその点を考える必要があります。

今すぐ実施できる3つの対策

1. 予期しない変更がないか ~/.claude.json を監視してください。このファイルはMitiga攻撃の要となるポイントです。このファイル内のMCPサーバーエンドポイントの変更——特に新しいlocalhostプロキシアドレスや見覚えのない外部エンドポイントの追加——はアラートをトリガーすべきです。ほとんどの組織では、開発者環境におけるユーザーレベルの設定ファイルを監視していません。この状況を変える必要があります。 Mitigaは具体的に推奨しています——Claude Codeの設定、MCPサーバーURL、OAuthリフレッシュ動作への変更を主要な検出レイヤーとして追跡するよう。
2. npmのpost-installフックをセキュリティ上の最重要課題として扱ってください。Mitiga攻撃は悪意のあるnpmパッケージから始まります。インストール時に任意のコードを実行するpost-installフックは、既知のサプライチェーンリスクの一類型ですが、開発者環境での強制適用は一貫していません。開発パイプラインでパッケージインストール時に何が実行されているかを監査してください。post-installスクリプトを含むパッケージが開発者のマシンに届く前にレビューを義務付けることも検討すべきです。これはClaude Code固有の推奨事項ではなく、開発スタックのすべてのツールに適用されます。ただしClaude Codeは、対策を怠った場合の結果をより現実的なものにしています。
3. Claude Code統合に接続されているOAuthトークンを監査し、ローテーションしてください。Claude CodeをJira、Confluence、GitHub、その他のSaaSプラットフォームに接続した開発者は、セッションをまたいで持続するOAuthトークンを生成しています。悪意のあるパッケージがインストールされた期間中にそれらのトークンが有効だった場合、侵害された可能性があるものとして扱うべきです。ローテーションしてください。プロバイダー側の監査ログで、Mitigaが説明する動作パターン——開発者が開始していない、AnthropicのエグレスIPからの正常に見えるリクエスト——を確認してください。なお、 悪意のあるフックがまだ存在している場合、トークンのローテーションだけでは攻撃チェーンを断ち切れません——フックは次のリフレッシュ時に設定を再度書き換え、新しいトークンを傍受します。修復にはまずフックを削除し、設定をクリーンアップすることが必要です。

率直な評価

Mitigaの開示に対するAnthropicの回答——ユーザーがパッケージのインストールに同意しているためスコープ外という判断——は、セキュリティの実務者が認識し、そしてほとんどが否定するであろうロジックに従っています。パッケージのインストールへの同意は、そのパッケージがAIツールのルーティング設定を書き換え、SaaS認証情報を傍受することへの同意ではありません。両者は同一ではなく、それを同等に扱うことはサプライチェーンセキュリティの責任をすべて開発者に押しつけ、依存関係の名前について瞬時の判断を迫ることになります。

それは合理的なセキュリティモデルではありません。

パッチが適用されたCheck Pointの脆弱性は、問題を適切な形で伝えればAnthropicが対応することを示しています。Mitigaの研究は1週間前のものです。パッチが続くかどうかは未解決の問題ですが、その問いがどのように解決されるにかかわらず、アタックチェーンは今日も機能しています。

あなたの開発者はClaude Codeを使っています。セキュリティチームにとっての問いは、このリスクに向き合うかどうかではなく、どれだけ迅速にこのリスクを考慮した検知・対応を実装できるかです。設定ファイルは小さく、監視要件は具体的で、アタックチェーンはドキュメント化されています。ベンダーのパッチを待つよりも、まずそこから始める方が得策です。

この記事はFoundry Expert Contributor Networkの一環として公開されています。
参加を希望される方はこちら。