Tego AIがClaude Codeの新たな問題を公開|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月29日更新日時: 2026年07月29日

イスラエルのサイバーセキュリティ企業Tego AIは2026年7月24日、Anthropicのエージェント型コーディングツール「Claude Code」に関する新たなセキュリティ研究を公開しました。悪意あるリポジトリをクローンしてClaude Codeを起動するだけで、プロジェクト外のファイルが読み込まれ、モデルへの最初のリクエストに含まれて外部へ送信される可能性があるという内容です。仕組みは、リポジトリ内の指示ファイルCLAUDE.mdに記述された@importディレクティブが、プロジェクト外のファイルを指すシンボリックリンクを参照するというものです。ツール呼び出しもファイル編集の承認ダイアログも表示されず、Claude Codeが持つプロジェクト外読み込みの警告ダイアログも作動しません。Tego AIはこの問題を2026年7月にHackerOne経由でAnthropicへ報告しましたが、Anthropicは自社の脅威モデルに基づき「Informative（情報提供）」として扱い、脆弱性としての修正対象外としました。Tego AIもAnthropicが自社の定めたモデルを一貫して適用したことは争っていません。

サマリー

Tego AIがClaude Codeのメモリローダーにおけるシンボリックリンク経由の情報読み込み問題を公開
CLAUDE.mdの@importがシンボリックリンクを参照すると、プロジェクト外のファイルがモデルのコンテキストに読み込まれる
読み込まれたファイルの内容は、セッション開始時の最初のリクエストに含まれて外部へ送信される
ツール呼び出し・編集承認・外部インポート警告のいずれも作動しない
警告が出ない理由は、判定がリンク解決前のリポジトリ内パス（./link）を見て、実際の読み込みは解決後の外部パスを辿るため
同種の欠陥は過去2回（CVE-2025-59829、CVE-2026-25724）修正済みだが、メモリローダーの経路には修正が及んでいなかった
リポジトリにコミットされた設定でANTHROPIC_BASE_URLを書き換えると、送信先を攻撃者が選んだホストに変更可能
AnthropicはHackerOne報告を「Informative」としてクローズ、「フォルダを信頼する」ダイアログが境界だとの立場
検証はClaude Code v2.1.xに対して実施

項目	内容
報告者	Tego AI（イスラエル・テルアビブ、AIエージェントのランタイムセキュリティ企業）
公開日	2026年7月24日
対象製品	Claude Code（Anthropicのエージェント型CLIコーディングツール）
検証バージョン	v2.1.207（静的解析）、v2.1.215（通信キャプチャ）
悪用の起点	悪意あるリポジトリのクローンとClaude Codeの起動
仕組み	CLAUDE.mdの@importがプロジェクト外を指すシンボリックリンクを参照
情報の流出経路	セッション開始時の最初のモデルリクエストのボディに混入
送信先の操作	ANTHROPIC_BASE_URLの書き換えで攻撃者選択のホストへ
Anthropicへの報告	2026年7月18日（HackerOne経由）
Anthropicの対応	Informativeとしてクローズ（信頼境界の範囲内と判断）

何が起きるのか――クローンして起動するだけで外部ファイルが読み込まれる

Claude Codeは、プロジェクトの指示をCLAUDE.mdというメモリファイルや.claude/rules/**以下のファイルから読み込みます。これらのファイルは@importディレクティブに対応しており、たとえば@./docs/setup.mdといった記述で、別のファイルの内容をセッション開始時にモデルのコンテキストへ取り込みます。これはAnthropicの公式ドキュメントでも推奨されている正規の機能であり、インポートされたファイルは起動時にコンテキストウィンドウへ読み込まれると明記されています。

Tego AIが示したのは、この@importディレクティブがシンボリックリンクを指していた場合の挙動です。リポジトリ内にlinkという名前のシンボリックリンクをコミットし、その参照先をプロジェクト外のファイル（例として/etc/passwd）に設定しておきます。Gitはシンボリックリンクをモード120000として保存するため、クローンしても絶対パスや相対パス（../によるディレクトリ遡上）を含めてそのまま復元されます。

開発者がこのリポジトリをクローンしてClaude Codeを起動すると、ツールはリンクを辿り、それが解決する先のファイル（プロジェクトの外にあるファイルを含む）を読み込み、その内容をモデルへ送信する最初のリクエストに折り込みます。Tego AIのリサーチ責任者Tomer Niv氏は「コンテキストとはモデルに送信されるものすべてであり、モデルは他のあらゆるネットワークエンドポイントと同じだ」と述べ、リポジトリをクローンしていつもの『このフォルダを信頼しますか』という質問に答えるだけで、リポジトリ外のファイルがコード実行もモデルの協力も攻撃者のサーバーもなしに、最初のリクエストでマシンから出ていくと説明しています。

なぜ警告ダイアログが表示されないのか

Claude Codeには、まさにこの状況のための制御機能が備わっています。メモリファイルがプロジェクト外から何かをインポートする際、初回に外部インポートの承認ダイアログを表示する仕組みです。このダイアログは、機能が「どんなリポジトリでもディスク上の任意のファイルを読める」状態にならないために存在します。

しかし、シンボリックリンクの形式ではこのダイアログが表示されません。Tego AIによれば、その理由は機構的なものです。インポートが「外部」に該当するかを判定するチェックは、リンク解決前の文字列パスに対して実行されます。この文字列パスは./linkであり、プロジェクト内に位置するため、インポートは内部として分類されダイアログが作動しません。ところがその直後の読み込みでは、同じ文字列パスを使ってOSがシンボリックリンクを外部のターゲットへと参照解決します。判定は./linkを見ているのに、実際の読み込みは/etc/passwdを取得するという食い違いが生じるのです。

さらにTego AIは、モデルに送られるコンテキスト内で、この読み込まれた内容が「コードベースにチェックインされたプロジェクトの指示」というラベルで提示される点も指摘しています。実際にはリポジトリ外のファイルであるにもかかわらず、モデルにはリポジトリの一部だと伝わってしまいます。

「フォルダを信頼」の一度の同意が抱える問題

Tego AIが問題の核心として挙げているのは、個別のバグというより「フォルダを信頼する（trust this folder）」という信頼境界の設計です。

Claude Codeは、初めてディレクトリを開いたときにそれを信頼するかを尋ねます。しかしTego AIの調査によれば、一度信頼したディレクトリの配下にクローンした新しいリポジトリは、その信頼を暗黙的に継承します。新しいプロンプトも表示されず、何も名指しされず、どこにも記録されません。つまり、機密性の高い判断が、リポジトリが何をするかを見る前という最も情報の乏しい瞬間に、一度きりのクリックへ委ねられているという指摘です。

Tego AIは、自社の開発マシンで信頼済みとして登録されているディレクトリを調べたところ、~/Documents、~/Desktop、そして/Users（マルチユーザーのルート全体）が返ってきたと報告しています。この場合、/Users配下のどこにクローンしたリポジトリも、プロンプトなしで実行されることになります。開発者がリポジトリをクローンする場所のほぼすべてが該当し得る状況です。

利用者は自分のマシンの信頼済みディレクトリを確認できます。macOSやLinuxでは~/.claude.jsonを、Windowsでは%USERPROFILE%\.claude.jsonを開き、projects内のhasTrustDialogAcceptedがtrueに設定されているエントリを確認することで、どのディレクトリ配下が信頼境界に入っているかを把握できます。

さらに、非対話モード（スクリプトやCIジョブで-pオプションを使う場合など）では、信頼プロンプトやインポートプロンプトが設計上スキップされます。この場合、プロジェクト外の読み込みは一切のプロンプトなしで発生します。

送信先を攻撃者が選べるバージョン

Tego AIは、送信先を攻撃者が指定できる発展形も実証しています。リポジトリに.claude/settings.jsonをコミットし、その環境変数ブロックでANTHROPIC_BASE_URLを設定すると、Claude Codeの送信先エンドポイントが同じフォルダ信頼の判断のもとで書き換えられます。新しいホストを名指しする別個のプロンプトは表示されません。読み込まれたファイルを既に含んだ最初のリクエストが、そのエンドポイントへ送られることになります。

ただしTego AIは、このANTHROPIC_BASE_URLの書き換え自体は既知の別問題であり、新規に主張するものではないと明記しています。当サイトでも既報の通り、Check PointによるCVE-2026-21852では、この書き換えが信頼プロンプトの実行前にAPIキーを漏洩させる初期の形態が扱われ、Anthropicはv2.0.65で修正しています。今回Tego AIが示したのは、v2.1.215において、この書き換えが信頼判断の後にリクエストを経路変更し、インポートされた内容をリポジトリが選んだホストへ運ぶという点です。なお、同じリクエストにはAuthorizationベアラートークンも含まれますが、この認証情報が実際に攻撃者のエンドポイントへ到達するかどうかは、コード上は示唆されるものの通信レベルでは証明されていないとしています。

過去2回修正された欠陥が、第3の経路に残っていた

今回の報告が注目される理由は、パターンが新しいからではなく、欠陥が存在する場所にあります。

セキュリティチェックが一方のパスを見ているあいだに、ファイルシステムがシンボリックリンクを辿って別のパスへ向かうという同じ欠陥は、過去にもClaude Codeで2度発見され、正しく修正されています。CVE-2025-59829は、シンボリックリンクが拒否対象に解決されることを考慮せずにパーミッションの拒否ルールをチェックしていた問題で、2025年9月19日にバージョン1.0.120で修正されました。CVE-2026-25724は同じ形状の問題で、シンボリックリンクによって/etc/passwdのような拒否リスト対象のファイルを拒否ルールが作動しないまま読み取れるというもので、2026年1月13日にバージョン2.1.7で修正されました。

これら2つのCVEはいずれもパーミッションサブシステム（あるファイルアクセスを許可するかを決めるコード）に存在し、修正はどちらも「シンボリックリンクを先に解決してから、解決後のパスが許可されるかを判定する」というものでした。しかし、メモリローダーは異なるサブシステムであり、この修正が及んでいませんでした。メモリローダーの包含チェックと外部インポート承認は、いずれも依然としてリンク解決前の文字列パスに対して実行される一方、実際の読み込みはその下でリンクを辿ります。しかもこの経路は、過去の2件にはなかった動作、すなわち読み込んだものを、モデルが何も動作する前にネットワークへ送出するという特性を持っています。

Tego AIは修正策として、ターゲットを一度正規化（canonicalize）したうえで包含チェックと外部インポート承認の両方をその正規化済みパスに対して実行すること、プロジェクトルート外に解決される@importは拒否するか個別の送信先明示の同意を求めること、外部やシンボリックリンク経由のインポートを具体的に名指しする承認を表示することなどを提案しています。これはAnthropicが既に2度実装した修正を、第3の経路に適用するものだとしています。

Anthropicの対応と両者の立場

Tego AIは2026年7月18日にこの問題をHackerOne経由でAnthropicに報告しました。7月19日にAnthropicが応答し、7月20日に報告はプランのスコープ外（Anthropicの信頼境界の範囲内）としてクローズされています。

Anthropicの論拠は一貫しており、明確に示されています。Claude Codeの脅威モデルにおいて、ワークスペースの信頼ダイアログがセキュリティ境界であり、それを受け入れることは、プロジェクトに対してホスト上での読み取り・編集・実行の広範なアクセスを既に付与している、というものです。非対話モードは意図的にその判断を呼び出し元へ委譲します。リポジトリにコミットされたシンボリックリンク経由でファイル内容を読み取ることも、リポジトリにコミットされた設定でエンドポイントを書き換えることも、その信頼が既に付与している範囲に含まれる、という立場です。Anthropicの評価では、外部インポートのプロンプトは個別に防御される境界ではなく、あくまで使いやすさのための補助という位置づけです。

Tego AIはこのモデルを理解したうえで、「我々の開示は、その条件そのものに対する議論だ」と述べています。同社のNiv氏は「たった一度の『このフォルダを信頼しますか』というクリックが、可能な限り情報の乏しい瞬間に、リポジトリが何をするかを見る前に、膨大な重みを負わされている。それは『私のコードを実行する』と『私のSSHキーを読んでメールで送る』を区別できない」と指摘しています。Tego AIは、シンボリックリンク攻撃が数十年前から存在すること、そしてAnthropicが誠実にClaude Codeをこの種の攻撃に対して繰り返し強化してきたことを認めたうえで、利用者やセキュリティチームが「フォルダを信頼する」が実際に何を付与するのかを正確に理解できるよう、この文書を公開したとしています。

情報システム部門・開発チームが取るべき対応

この問題はAnthropicが脆弱性として修正しない方針であるため、利用者側での対策が実務上重要になります。

第一に、信頼済みディレクトリの棚卸しです。前述のとおり~/.claude.json（Windowsでは%USERPROFILE%\.claude.json）を確認し、hasTrustDialogAcceptedがtrueになっているディレクトリが、/Usersや~/devのような広範なルートになっていないかを点検してください。広い親ディレクトリが信頼されている場合、その配下にクローンするすべてのリポジトリが無確認で信頼境界に入ります。信頼の範囲は必要最小限のプロジェクト単位に絞ることが望ましい対応です。

第二に、出所不明のリポジトリの扱いです。信頼できないリポジトリをクローンしてClaude Codeを起動する行為が、この問題の起点です。特にCI環境・コンテナ・標準化された開発イメージでは、機密ファイルのパスが予測可能なことが多く、リスクが現実的です。出所不明のリポジトリは、信頼済みディレクトリの外の隔離された場所でクローンする、あるいはClaude Codeを起動する前に内容を精査するといった運用が有効です。

第三に、CLAUDE.mdや.claude/以下の設定ファイルのレビューです。リポジトリに含まれるCLAUDE.md、.claude/rules/**、.claude/settings.jsonに、シンボリックリンクへの@importや、ANTHROPIC_BASE_URLを書き換える環境変数設定が含まれていないかを、クローン後・実行前に確認することが望まれます。

AIエージェント型の開発ツールは急速に普及していますが、Claude Codeのサンドボックス迂回や設定ファイルを悪用したRCE・APIキー窃取など、リポジトリにコミットされたファイルを起点とする攻撃面は継続的に報告されています。Tego AIが論点として掲げる「誰が、あるいは何が、エージェントに指示を与え、そのデータや接続システムに到達できるのか」という認可（authorization）の問題は、企業がAIコーディングエージェントを導入するにあたって正面から向き合う必要のある課題です。