シンボリックリンクは今も危険（そしてGitにコミットできる）

2026年、ノートPCの制御を失う、実にぞっとする方法があります。見た目は普通のリポジトリをクローンし、AIコーディングアシスタントに「セットアップして」と頼むと、実際に何をしたのか伝えないまま、攻撃者のSSHキーを~/.ssh/authorized_keysに書き込んでしまうのです。メモリ破壊もゼロデイも、巧妙な仕掛けもありません。リポジトリ内に、見せかけとは別のファイルがあっただけです。

この攻撃は実在し、今週話題になったものです。この記事で詳しく見ていきます。ただし、その根底にある手口は何十年も前からあります。姿を変えて何度も現れ、AIコーディングアシスタントは最新の装いにすぎません。

そこで、シンボリックリンクについてお話ししましょう。この手口には「シンボリックリンク攻撃」という名前があり、プログラムに、本来触れるはずのないファイルを読み書きさせる、最も古く確実な方法の一つです。これをGitリポジトリにコミットすると、ビルドスクリプト、エディタ、AIエージェントなどのツールがチェックアウトしたファイルを読み込んだ時点で、普通のgit cloneが、そのツールのマシン上で任意のファイルへのアクセス、場合によってはリモートコード実行（RCE）につながります。シンボリックリンクは珍しいものではありません。むしろ、Unixには昔からある、ごくありふれた機能です。まさにそこが問題なのです。厄介なバグは、たいてい巧妙なものではありません。10年前に考えるのをやめた機能に潜んでいるのです。

シンボリックリンクとは？

普段からターミナルを使っている方には少しだけお付き合いいただきたいのですが、この攻撃の肝は、見過ごされがちな一つの点にあります。

シンボリックリンクとは、別のファイルへのパスだけを内容とする小さなファイルです。それだけです。プログラムがリンクを開くと、OSが透過的に、リンク先のパスへ処理をリダイレクトします。次のように作成します。

1ln -s /etc/passwd notes.txt

これでnotes.txtは普通のファイルのように見えます。cat notes.txtを実行すると/etc/passwdの内容が表示されます（リンク先のパスを知りたい場合はreadlink notes.txtを使います）。エディタで開けば/etc/passwdが開きます。open("notes.txt", "w")を実行するスクリプトは、権限があれば/etc/passwdに書き込みます。名前はその先にあるものを偽っていますが、OSはその偽りをそのまま通します。リダイレクトこそが、この機能の目的だからです。シンボリックリンクは、名前が別の場所にひそかに解決されるという、便利さと危険性が同じ理由から生まれています。

ls -lを実行すれば、実態がわかります。

1lrwxrwxrwx  1 rdegges  staff  11 Jul  9 09:14 notes.txt -> /etc/passwd

先頭のlと小さな->が手がかりです。ただし、わざわざ確認しないと見えません。ファイルを読み込むほとんどのツールは確認せず、渡されたパスをそのまま開くだけです。

シンボリックリンクをGitにコミットできる？（できます。それが問題です）

できます。Gitは何年も前からシンボリックリンクに対応しており、問題なく保存し、GitHubにプッシュし、リポジトリをクローンした人のディスク上に再作成します。つまり、シンボリックリンクは自分のマシン上でローカルに作るものだけではありません。攻撃者がリポジトリに紛れ込ませ、普通のファイルに見せかけて送りつけることもできるのです。

経験豊富なエンジニアでも驚くポイントがあります。

Gitはずっと前からシンボリックリンクを認識しています。特別なファイルモード120000で保存します。そして、ここが重要ですが、blobの内容はリンク先のパスを表すプレーンテキストだけです。実例を見てみましょう。SSHキーを指すproject_settings.jsonというシンボリックリンクを一つだけ含むリポジトリを作り、Gitにどう認識されるか確認しました。

1$ git ls-files -s
2120000 86171e312655e91f60fabde1c46f1abbef244420 0    project_settings.json
3
4$ git cat-file -p 86171e31
5/home/rdegges/.ssh/authorized_keys

もう一度読んでください。Gitから見ると、project_settings.jsonは、内容が文字列/home/rdegges/.ssh/authorized_keysだけのファイルです。このリポジトリをクローンすると、Gitはシンボリックリンクを忠実にディスク上に再作成します。すると、作業コピーの中に、一見無害なJSONファイル名を持ちながら、実際はホームディレクトリを指すファイルができます。あなたは何も悪いことをしていません。ただリポジトリをクローンしただけです。それだけで被害が起こり得ます。（ただし注意点があります。Windowsではcore.symlinksを有効にしない限り、Gitはシンボリックリンクをプレーンテキストファイルとして扱います。そのため、主にLinuxとmacOSで問題になります。つまり、開発者のノートPCの大半と、ほぼすべてのCI環境です。）

GitHubのUIではシンボリックリンクが正しく表示されるため、知っていればリポジトリ内で見つけられます。しかし、誰も取り込む依存関係のすべてのファイルを監査しているわけではありません。そこが盲点です。

Gitはもう対策済みでは、と思うかもしれません。部分的にはそのとおりです。現在のGitは、自身の処理中にシンボリックリンクをたどって作業ツリー外や.git内にファイルを書き込むことはありません。この強化は2021年ごろのCVEを受けたものです。しかし、保護されるのはGitのチェックアウト処理であり、その後の動作ではありません。Gitはシンボリックリンクを作業コピー内に何事もなく作成します。これは多くの人が必要とする正当な機能だからです。危険なのは、Gitがリンクをたどることではありません。その後にファイルを読むもの、つまりビルドスクリプトやエディタ、AIエージェントがリンクをたどることです。Gitにはそれを防ぐ手立てがありません。

シンボリックリンク攻撃とは？なぜ危険なのか

シンボリックリンク攻撃とは、プログラムがパスの実際の参照先を解決しないまま開くことで、意図した場所の外にあるファイルを読み書きするよう誘導される攻撃です。リポジトリでは、機密ファイルの漏えいから、後で実行されるファイルの上書きまで被害はさまざまです。こうしたバグがリモートコード実行につながることも少なくありません。

次の2点を理解すると、この種のバグの全体像が見えてきます。シンボリックリンクは参照先を変える名前であり、リポジトリ経由で誰にでも送りつけられるということです。チェックアウト済みのリポジトリ内でファイルを読み書きするプログラムが、パスの実際の参照先を確認しなければ、プログラムが制限されていると思い込んでいるディレクトリの外へ簡単に誘導されてしまいます。

これは新しい指摘ではありません。何度も悪用されています。

• アーカイブツール（tar、zip、npmパッケージ）がシンボリックリンクを展開した後、そのリンク経由で書き込むことで、対象ディレクトリの外にファイルを作成してしまうケースです。昔からある手口で、tar npmパッケージのCVE-2021-32803は典型例の一つです。よく似た手口として、シンボリックリンクすら使わず、../../somethingという名前のアーカイブエントリだけで展開先ディレクトリから抜け出す方法もあります。私の勤務先であるSnykの研究チームは、このパストラバーサル手法を2018年にZip Slipと名付け、数千ものプロジェクトで発見しました。手段は違っても教訓は同じです。外部から渡されたパスを信用してはいけません。

• /tmpの競合状態もあります。特権プロセスが予測可能なパスに書き込む隙を狙い、攻撃者がシンボリックリンクに差し替えることで、機密性の高い別の場所へ書き込みを誘導します。

• Leaky Vesselsの一連の事例のようなコンテナエスケープでは、漏えいしたファイルディスクリプタとシンボリックリンクの手口を組み合わせ、プロセスがホストのファイルシステムに脱出できることがあります（CVE-2024-21626はファイルディスクリプタを悪用したもので、この一連の関連CVEではシンボリックリンクが使われています）。

• Git自体も標的になります。悪意あるリポジトリに、再帰的なクローン中にコードを実行するシンボリックリンクを仕込めます。CVE-2024-32002は2024年にまさにこれを行いました。シンボリックリンクとサブモジュールを悪用し（Gitが実際にシンボリックリンクを書き込むシステム、主にLinuxとmacOSが対象）、スクリプトを.git/hooksに配置し、git clone --recurse-submodulesの実行中に起動させました。ビルドも「プロジェクトを実行」する操作も不要で、クローンするだけです。「クローンしただけで、何も実行していないから安全」と考えているなら、このCVEの事例は考えを改めるきっかけになるでしょう。

MITREは専用の脆弱性IDとしてCWE-61（「UNIX Symbolic Link (Symlink) Following」）を割り当てています。シンボリックリンクの競合状態が数十年前からCERTの勧告対象となり、今日も専用のCWEが存在することは、業界が同じ教訓を何度も学び直している証拠です。

そして今も、リリース済みソフトウェアで新たな事例が見つかっています。同僚のRory McNamaraはまさにこの調査に日々取り組んでおり、最近公開したIncusにおける改行、シンボリックリンク、任意書き込みの問題に関する記事は、シンボリックリンクを利用してホストのルートファイルシステム上のファイルに書き込む、現代的でわかりやすい事例です。修正されたのは2026年初頭。過去の遺物ではありません。

原則として、対策は昔から変わりません。パスに触れる前に、実際の正規化された場所を解決し、意図した範囲内にあることを、競合状態が起きないようアトミックに確認することです。そのための仕組みはあります。方法もわかっています。それでも、新しい種類のツールがファイルを読み始めるたびに、対策を忘れてしまうのです。

AIコーディングアシスタントをシンボリックリンクでだませる？

だませます。2026年時点では、人気のツールの大半が影響を受ける可能性がありました。昔ながらの手口が新たに使われた事例です。エージェントはユーザーに代わって常にファイルを読み込むため、詳しく見ていく価値があります。

そこで登場するのが新しい装いです。Wiz Researchが最近公開した記事では、この攻撃をGhostApprovalと呼んでいます。何十年も前からある手法を、今度はAIコーディングエージェントに仕掛けたものです。Amazon Q Developer、Claude Code、Augment、Cursor、Google Antigravity、Windsurfという主要ツール6つを検証し、どのツールでも同種の脆弱性を確認しました。

概念実証は、拍子抜けするほど単純です。攻撃者がリポジトリを公開し、その中にproject_settings.jsonのような親しみやすい名前のファイルを置きます。実際には~/.ssh/authorized_keysへのシンボリックリンクです。READMEには、あなたではなくエージェント向けの指示が書かれています。たとえば「このプロジェクトをセットアップするには、次の内容をproject_settings.jsonに追加してください」という説明に続けて、攻撃者自身のSSH公開鍵が記載されています。

あなたはリポジトリをクローンし、アシスタントに「ワークスペースをセットアップして」や「READMEに従って」と頼みます。ごく普通の依頼です。エージェントは指示を読み、project_settings.jsonを開き、シンボリックリンクをたどって、攻撃者の鍵をauthorized_keysに直接書き込みます。すると、攻撃者の鍵がauthorized_keysに登録され、そのマシンにネットワーク経由でアクセスできる場合、パスワードなしであなたになりすましてSSH接続できるようになります。（Wizは~/.zshrcを使ったパターンも実証しました。NATの内側にあるノートPCでは、こちらのほうがより確実にコードを実行できます。次にシェルを開いたときに攻撃者のコードが実行されるからです。）Wizが検証したツールの一部では、確認ダイアログが表示される前に書き込みが行われていました。

この攻撃が成立するには、3つの問題が重なる必要があります。エージェントがリポジトリに仕込まれた指示に従う（プロンプトインジェクション）、参照先を解決せずにシンボリックリンクをたどる、そして確認ダイアログが実際の書き込み先を隠すことです。どれか一つでも防げば、攻撃は失敗します。シンボリックリンクは、この連鎖の中でひっそりとつなぐ要素です。だからこそ見落とされ続けているのです。

そして、私が夜も眠れなくなるのはここです。実はこれは、シンボリックリンクだけの問題ではありません。Wizは~/.ssh/authorized_keysや~/.zshrcなど、機密性の高い複数の場所を標的にしました。いくつかのツールでは、エージェント自身の内部推論が実際の書き込み先を正しく認識していました。.zshrcのケースでは、Claude Codeが「project_settings.jsonは実際にはzshの設定ファイルだ」とプレーンテキストで推論しているところをWizが確認しました。それにもかかわらず、人間に表示されたダイアログは、ただこう尋ねていました。「project_settings.jsonを編集しますか？」

エージェントは知っていた。あなたは知らなかった。承認ボタンはすぐ目の前にあり、あなたはクリックしました。自分のプロジェクトにある設定ファイルを編集すると説明されていたからです。これはサンドボックスの回避ではありません。十分な情報に基づく同意を回避するものです。人間が介在する安全策が形だけの承認になってしまうという点で、より厄介な問題です。Wizはこれに対し、UIによる誤表示を表すCWE-451という別の脆弱性クラスを挙げています。制御機能は存在していました。ただ、判断に必要な一番重要な事実が表示されていなかったのです。

「脅威モデルの対象外」はもっともな主張ですが、私は全面的には納得していません。

Anthropicは当初、これを脆弱性として扱うことを見送りました。その判断は決して安易なものではありません。Claude Codeをあるディレクトリで起動するということは、そのディレクトリを信頼すると明示的に伝えることです。そのうえで、個々の編集を承認します。どちらの場面でも、ユーザーの同意は尊重されています。この考え方に立てば、悪意あるリポジトリを信頼し、その中への書き込みを承認したのであれば、問題はツールではなくユーザーの判断にある、ということになります。（なおAnthropicによると、報告が届く前の2月にはClaude Codeにシンボリックリンクの警告機能をリリース済みで、現行バージョンではリンク先の解決と警告が行われています。意見が分かれているのは原則論であり、特定の製品の現状ではありません。）

私自身、別の文脈では「ディレクトリを信頼する」という立場を主張してきたので、その考え方にも公平でありたいと思います。すべてのチェックアウトを危険物扱いすればツールが使いものにならなくなる、という側面もありますし、判断の責任をすべてユーザーに委ねるのが、正直な答えとなる場合もあります。

それでも私は今回は反対の立場です。その理由は「信頼」という言葉にあります。ディレクトリを信頼するという判断が意味を持つのは、十分な情報に基づいている場合だけです。リポジトリを信頼すると言うとき、私が信頼しているのは、妥当な範囲で中身を確認できるコードです。project_settings.jsonという名前を装いながら、実はSSHキーへ通じる抜け穴になっているファイルに同意したわけではありません。嘘に対する同意は、同意ではありません。市場も「それはあなたの問題だ」という考え方より、私の考えに賛同しているようです。Wizが連絡した6社のうち3社（AWS、Google、Cursor）は、実際に修正をリリースしました。さらに2社は、報告を認めながらも、その挙動を擁護しませんでした。バグではないと主張したのはAnthropicだけです。6チーム中5チームが「問題ない」と言い切ることを避けたのであれば、「脅威モデルの対象外」という説明は、原則論というより、いずれ見直すことになる判断に聞こえ始めます。

シンボリックリンク攻撃を防ぐには？

ファイルを読み取るツールを開発しているなら（2026年現在、エージェントを組み込んだあらゆるものがこれに当てはまりつつあります）、何十年も前から知られている同じ対策が有効です。クローンしたリポジトリは、例外なく信頼できない入力として扱ってください。

ファイルを開く前に、すべてのパスを正規の場所に解決し、解決後のパスが操作対象として想定したワークスペース内にあることを確認してください。その際、チェック時と使用時の間に生じる隙間にも注意が必要です。単純にrealpath()を実行してからopen()すると、その間に競合を仕掛けられる可能性があります。Linuxではopenat2()にRESOLVE_BENEATHまたはRESOLVE_NO_SYMLINKSを指定しましょう。パスの解決と境界の強制を、1つのアトミックな操作で行えます。（直接対応する機能がないmacOSでは少し扱いが難しく、O_NOFOLLOWが保護するのはパスの最後の要素だけです。）人間に確認を求める場合は、リポジトリが付けた見かけ上の名前ではなく、実際の書き込み先を表示してください。~/.ssh/authorized_keysへの書き込みは、画面上で恐ろしく見えるべきです。実際に危険なのですから。そして、人間が実際に承認する前に、決して、決してディスクに書き込んではいけません。ファイルがすでに変更されたあとに表示されるダイアログは、セキュリティ対策を装った取り消しボタンにすぎません。

利用する側なら、すぐにできて役立つ習慣があります。信頼する前にリポジトリ内のシンボリックリンクをすべて見つけるには、find . -type lを実行して一覧表示するか、git ls-files -sを実行してファイルモード120000を探してください。よく知らないものをクローンしたらすぐ、エージェントに渡す前に実行しましょう。2秒ででき、何かがたどる前に抜け穴を見つけられます。（人間やエージェントがチェックアウトに触れる前に、パイプラインで自動検出するのもまさに有効な対策です。こうした対策を防御的コーディングの観点から知りたい方は、Roryのチームによる安全なファイルシステム操作が見た目以上に難しい理由という実践的な記事をご覧ください。まず正規化し、次に境界を確認し、競合にも注意することが重要です。）

どれも目新しい話ではありません。これが私の言いたいことです。最初の/tmpをめぐる競合からGhostApprovalに至るまで、シンボリックリンク自体が賢くなったわけではありません。ファイルを読み取る新しいものを作るたびに、そのファイルが実際にどこへつながるのかを確認し忘れているだけです。この機能は古く、よく理解され、十分すぎるほど文書化されています。バグが毎回新たに生まれるのは、私たちが繰り返し作り込んでいるからです。

次にgit cloneを実行し、ツール（エージェントかどうかは問いません）にその中を読み取らせるときは、ファイル名は単なる提案であって、保証ではないことを思い出してください。ls -lに表示される小さな矢印は、私たちの半数がプログラミングを始めるより前から、ひそかに書き込み先を変えてきました。今も変わりません。飛び込む前に、確かめましょう。