GhostApproval・SymJack解説｜AIコーディング支援6種のsymlink承認ハイジャック

GhostApproval（ゴーストアプルーバル）は、Wizが2026年7月8日に公表した、AIコーディング支援6種に共通する「信頼境界の欠陥」です。同じ穴を先に突いたAdversa AIの研究は SymJack（シムジャック）と名付けられ、2026年5月26日に公開されています。ひとことで言えば——AIエージェントの承認ダイアログに表示されるファイル名と、OSのカーネルが実際に書き込む先が、symlink（シンボリックリンク）によってすり替わる。あなたが承認したのは無害に見えるproject_settings.jsonなのに、書き込まれるのは~/.ssh/authorized_keysだった、という事故が成立します。

この記事の主題は3つです。1つ目は、なぜ「承認したはずのファイル」と「実際に書かれるファイル」がズレるのか——symlinkとフルパス表示という、Unix時代からある古い仕様がAIエージェントの承認フローと噛み合った瞬間に何が起きるのか。2つ目は、6種それぞれのベンダーがどう反応したか。修正したツール、係争中のツール、公表時点で未修正だったツール——そしてAnthropic（Claude Code）が当初「脅威モデルの範囲外」と分類した経緯を、煽らず一次ソースに沿って正確に。3つ目は、あなたが自分の環境で今すぐ実行できる、読み取り専用の確認コマンドです。攻撃の再現手順は載せません。防御側が仕込まれたsymlinkを検出し、被害の有無を確かめるための手順に絞ります。

まずは、当サイト（AI Heartland）が実際に手を動かして確かめた「防御側の検出」の様子から。信頼できないリポジトリに仕込まれた偽装symlinkを、1行のコマンドで炙り出したところです。

なお、サプライチェーン攻撃全体の手法・防御ツールを体系的に押さえたい場合は、ピラー記事サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを先に読むと、本件の位置づけが掴みやすくなります。本記事はその中でも「AIコーディングエージェント固有の、承認フローを騙す新しい攻撃面」に絞って掘り下げます。

GhostApproval・SymJackとは — AIコーディング支援のsymlink承認ハイジャック

GhostApprovalとSymJackは、名前こそ違え、AIコーディングエージェントが持つ「承認（approval）」という安全機構そのものを無力化する攻撃です。まずは全体像を、独立した2つの研究として正確に区別します。

SymJack（Adversa AI・2026年5月26日公表、翌27日更新）は、この一連の問題を最初に公にした研究です。Adversaは「the approval prompt is lying to you（承認プロンプトはあなたに嘘をついている）」という刺激的な題で、複数のAIコーディングCLIに対して攻撃が成立することを示しました。GhostApproval（Wiz・2026年7月8日公表）は、それを別チームが独立に再発見・体系化し、対象を6種のAIコーディング支援として整理したものです。両者は独立した報告であり、対象ツールの一覧は重なりつつも一致しません。この「複数チームが独立に同じ穴を掘り当てた」という事実自体が、これが特定製品のバグではなくカテゴリ全体に及ぶ構造的な欠陥であることを物語っています。

Wizはこの欠陥を、2つの弱点タイプの組み合わせとして説明しています。ひとつは symlink following（CWE-61・シンボリックリンクの追跡）——エージェントがファイルを開くときに、そのファイルがsymlinkだった場合、リンク先の実体を追ってしまうこと。もうひとつは 情報表示の不備（CWE-451・重要情報のUI上の誤表現）——承認ダイアログが、解決後の実際の書き込み先ではなく、リポジトリ内の見かけ上のパスを表示してしまうこと。NVDはCursorの同種の欠陥（CVE-2026-50549）を CWE-59（ファイルアクセス前のリンク解決の不備） として分類しています。呼び名や整理は研究・機関によって多少異なりますが、指している現象は同じです。

技術的な要点を3行でまとめると、こうなります。

・悪意あるリポジトリに、無害な名前（project_settings.json・README内で参照されるファイルなど）でsymlinkを仕込む。その実体は~/.ssh/authorized_keysや各エージェントの設定ファイルを指す。
・ユーザー（またはエージェント）が「そのファイルを編集する」操作を承認する。ダイアログにはリポジトリ内の見かけ上のパスが表示される。
・カーネルはsymlinkを解決し、ワークスペース外の実体へ書き込む。SSH公開鍵の注入やエージェント設定の乗っ取りにつながり、最終的にリモートアクセスや任意コード実行（RCE）に至り得る。

時系列 — SymJack（2026年5月）からGhostApproval（7月）公開まで

この問題は一度に表面化したわけではありません。非公開でのベンダー報告、独立した2チームによる公表、CVEの採番、修正版の展開——複数の出来事が数か月にわたって折り重なっています。以下は、公開情報として日付が確認できるものを軸に、Wizが開示記録として示した経緯を補って整理したタイムラインです。

まず押さえておきたいのは、公表そのものはAdversa（SymJack）が先だったという点です。Adversaが5月26日に問題を公にし、その後6月にAmazon Q（CVE-2026-12958）とCursor（CVE-2026-50549）のCVEが相次いで採番・公開され、7月8日にWizがGhostApprovalとして6種を横断的に整理しました。研究の呼び名は違っても、指している欠陥のクラスは共通しています。

Wizが公開した開示記録によれば、非公開でのベンダー報告は2026年2月に始まりました。Wizはこの時期にAnthropicをはじめ複数のベンダーへ順次報告し、各社の反応を記録しています。Anthropicがこの時点で報告を「Claude Codeの脅威モデルの範囲外」と分類した、というのがこの時系列の山場です。ただし後述するように、これは単純な「否認」として片づけられる話ではありません。

何が起きたのか — symlinkが承認ダイアログをすり抜ける仕組み

なぜ「承認したファイル」と「実際に書かれるファイル」がズレるのか。ここは攻撃の核心ですが、防御に必要な範囲——どこで表示と実体が食い違うのか——に絞って説明します。攻撃を再現するための具体的な仕込み手順は記載しません。

鍵はsymlink（シンボリックリンク）です。symlinkは「別のファイルのパス名を格納した、小さな道標ファイル」です。project_settings.jsonという名前のsymlinkが、その中身として/Users/you/.ssh/authorized_keysという文字列を持っていれば、多くのプログラムはproject_settings.jsonを開いた瞬間、道標をたどってauthorized_keysの実体を読み書きします。これはUnix由来の正常な仕様であって、バグではありません。問題は、AIエージェントの承認ダイアログが、この「道標をたどった先」ではなく「道標そのものの名前」を表示してしまうことにあります。

Adversaが示した典型的な筋書きはこうです。悪意あるリポジトリのREADMEや指示が、エージェントに「このリポジトリ内のファイルをコピー／編集して」と依頼する。エージェントは一見無害なファイル操作としてユーザーに承認を求める（Adversaの例では「動画ファイルのコピー」のように、まったく警戒されない操作）。ユーザーが承認すると、カーネルはsymlinkを解決し、エージェント自身の設定ファイルを上書きする。次回エージェントを起動したとき、書き換えられた設定によって悪意あるMCPサーバーが起動し、ユーザー権限で任意コードを実行する——という流れです。

書き込み先の候補は、攻撃者にとって「刺されば大きい」場所ばかりです。

ここで重要なのは、この攻撃が「プロンプトインジェクション」単体では完結しないという点です。多くのエージェントは、ファイル書き込みの前に人間の承認を挟むよう設計されています。GhostApproval/SymJackが巧妙なのは、その承認という関門を、嘘の表示によって無害化するところにあります。つまり守るべき砦は健在に見えるのに、砦の門番が別の書類を見せられて判子を押してしまう。Adversaが「承認プロンプトはあなたに嘘をついている」と表現したのは、この構図を指しています。

ベンダー対応と影響範囲マトリクス — GhostApprovalに各社はどう答えたか

ここが本記事で最も慎重に書くべき箇所です。「誰が修正し、誰が係争中で、誰が公表時点で未修正だったか」を、一次ソースに沿って、煽らずに整理します。前提として、ステータスは時点情報です。GhostApprovalの各社対応はWiz公表の2026年7月8日時点、SymJackの各社対応はAdversa公表の2026年5月26日時点のものであり、その後変化している可能性があります。

まず、Wizが挙げたGhostApprovalの6種を、修正版バージョンとともにマトリクスにまとめます。これが「6種それぞれどこで直ったか」の一覧です。

CVEとして正式に採番され、NVDで裏が取れているのは Amazon QのCVE-2026-12958 です。NVDの記述は明快で、「Language Servers for AWSのsymlink検証の欠如により、ワークスペースの信頼境界外への任意ファイル書き込みが起こり得る。バージョン1.69.0以上へ更新することで解消する」とされています。CVSSは4.0で8.5（HIGH）、3.1で7.8（HIGH）。攻撃元区分はローカル（AV:L）で、ユーザーの関与（UI）を要する——まさに「ユーザーが承認する」ことを前提にした攻撃であることが、スコアのベクトルからも読み取れます。AWSはセキュリティ速報2026-047として公表し、言語サーバはネットワークでブロックされていない限り自動更新される、と案内しています。

Anthropic（Claude Code）の経緯を正確に

この記事のなかで、いちばん誤読されやすいのがAnthropicの対応です。「否認した」という一語で片づけると不正確になるため、Wizの報告に沿って経緯を分解します。

Wizによれば、Anthropicは当初この報告を「Claude Codeの脅威モデルの範囲外（outside our current threat model）」と分類しました。その論拠は、①ユーザーはClaude Codeをディレクトリで起動する際、そのディレクトリを信頼すると事前に確認している、②その上で承認プロンプトを明示的に承認している——つまり「信頼の確認」と「明示的な承認」という2つの判断をユーザー自身が下している以上、悪意あるsymlinkを含むディレクトリでの承認は脅威モデルの外だ、という整理です。

一方で、Wizは重要な補足も伝えています。Anthropicは、symlinkに関する警告を、この報告を受け取るより前の2026年2月5日にv2.1.32へ、社内レビューに基づく予防的なセキュリティハードニングとして既に投入していた、と説明しているのです。つまりAnthropic側の立場は「報告を受けて慌てて直した」ではなく「関連する強化はもともと進めていた」というものです。研究者側（Adversa）は、この一連の変化を「承認フローが静かにハードニングされ、symlink解決後のパスを表示するようになった」と特徴づけています。Anthropicの主張（予防的・報告以前）と、研究者の見え方（静かなハードニング）の両方を併記するのが、この件の公平な描き方です。

Anthropicだけを取り上げると不公平になるので、「明示的な承認は意図された動作だ」という論拠は、複数のベンダーに共通していた点も添えます。Adversaの5月時点の記録では、Google（Gemini CLI／Antigravity CLI）は「単一ユーザーの自己攻撃であり、明示的な承認は意図された動作」として却下、OpenAI（Codex CLI）も同様に「明示的な承認は意図された動作」として却下し、委託先のトリアージでは「理論的」と評価された、とされています。「ユーザーが承認したのだから範囲外」という反応は、Anthropicに固有のものではなく、この攻撃クラスに対する業界共通の初期反応だったわけです。そしてそれこそが、GhostApproval/SymJackが問いかけている核心——その「承認」自体が嘘の表示によって騙されているのに、承認を免罪符にしてよいのか——を浮き彫りにします。

SymJack（Adversa）が挙げた追加のツール

Wizの6種とは別に、Adversaのsymjack研究は別の顔ぶれを対象にしていました。両者の対象は重なりつつも一致しないため、混同を避けて別表にまとめます（Adversa公表の2026-05-26時点）。

こうして2つの表を並べると、Claude Code・Cursor・Antigravityが両研究に共通して登場する一方、Amazon Q・Augment・WindsurfはWiz側にのみ、Copilot CLI・Codex CLI・Grok BuildはAdversa側にのみ登場することが見て取れます。独立した2チームが、部分的に重なる別々のツール群で同じ欠陥を実証した——この事実が、問題がカテゴリ全体に及ぶことの何よりの証拠です。

なお、Cursorのsymlink関連の欠陥であるCVE-2026-50549は、当サイトの別記事Cursor IDE脆弱性DuneSlide解説｜CVE-2026-50548/50549でゼロクリックRCEで、Cato Networksが公表したCursor固有の文脈（DuneSlide）とあわせて詳述しています。本記事は「6種横断のsymlink承認ハイジャック」に軸足を置くため、Cursorはマトリクスの1行として位置づけ、CVEの深掘りは重複を避けてそちらに譲ります。

対策手順 — 緊急・推奨・長期の3段階

対策は「今すぐやること」「腰を据えてやること」「設計として抱えるべきこと」の3段階に分けると整理しやすくなります。攻撃の再現手順ではなく、防御と緩和のみを扱います。

「AIエージェントの暴走コマンドを実行前に止める」という発想自体は、承認フロー以外のガードレールでも実装が進んでいます。そうした「実行前ブロック」の考え方は、当サイトのサプライチェーン／エージェント安全性の記事群とあわせて読むと、多層防御の全体像が掴めます。

自システムでの確認方法 — symlinkを検出する読み取り専用コマンド

ここが当サイトの本領です。以下はすべて読み取り専用で、ファイルを書き換えたり攻撃を再現したりしません。信頼できないリポジトリを開く前、あるいは「もしかして踏んだかも」と不安なときに、自分の環境で実行して確かめるためのコマンドです。編集部がmacOS（Darwin）で実際に実行し、出力を確認しています。

① リポジトリ内のsymlinkをすべて洗い出す（最も基本）

信頼できないリポジトリのルートで、まずこれを実行します。無害な名前のファイルがsymlinkだったら、それだけで警戒の対象です。

# カレント配下のsymlinkを、リンク先つきで一覧表示（読み取りのみ）
find . -type l -ls

編集部が仕込みを模したテスト用ディレクトリで実行すると、project_settings.json の実体が .ssh/authorized_keys を指すsymlinkであることが一目で分かりました。設定ファイルやドキュメントの名前をしているのに l（symlink）で始まる行があれば、中身を確認すべきサインです。

② 各symlinkが「どこを指しているか」を解決して表示する

一覧だけでなく、リンク先の実体パスまで並べて確認します。

# 各symlinkの「見かけの名前 → 実際の指し先」を表示
find . -type l -exec sh -c 'for p; do printf "%s -> %s\n" "$p" "$(readlink "$p")"; done' _ {} +

③ ワークスペースの外を指すsymlinkだけを警告する（最重要）

GhostApproval/SymJackの本質は「ワークスペース外への書き込み」です。そこで、リンク先がカレントディレクトリの外に出るものだけを炙り出します。~/.ssh や ~/.zshrc、/etc などを指すsymlinkがここに出たら、明確な危険信号です。

# リンク先がリポジトリ（カレント）の外を指すsymlinkだけを ⚠ 表示
find . -type l | while read -r l; do
  target=$(readlink -f "$l" 2>/dev/null)
  repo=$(pwd)
  case "$target" in
    "$repo"/*) : ;;                       # リポジトリ内 → 問題なし
    *) echo "⚠ ESCAPES WORKSPACE: $l -> $target" ;;  # 外を指す → 要確認
  esac
done

編集部の環境では、/etc/hosts を指すsymlink（mcp.json）を仕込んだところ、⚠ ESCAPES WORKSPACE: ./mcp.json -> /private/etc/hosts と正しく警告が出ました。冒頭のターミナル画像は、この出力を撮ったものです。macOSでは readlink -f が使えます（古い環境で使えない場合は python3 -c "import os,sys;print(os.path.realpath(sys.argv[1]))" "$l" で代替できます）。

④ 「刺さると痛い」ファイルに身に覚えのない追記がないか監査する

万一すでに踏んでいた場合に備え、攻撃者が狙う代表的な書き込み先を点検します。いずれも表示するだけの読み取り専用です。

# SSH公開鍵に身に覚えのない鍵が注入されていないか
cat ~/.ssh/authorized_keys 2>/dev/null

# シェル起動時に走る設定に不審なコマンドが混じっていないか
tail -n 20 ~/.zshrc ~/.bashrc 2>/dev/null

# 各エージェントの設定 / MCP定義に見覚えのないサーバーが無いか
cat ~/.claude/settings.json 2>/dev/null
find . -maxdepth 2 -name ".mcp.json" -exec cat {} +

⑤ 使っているツールが修正版かをバージョンで確認する

# Claude Code（最新版へ）
claude --version

# Cursor（3.0以上であること）
cursor --version

# Amazon Q は Language Servers for AWS 1.69.0 以上であること
# （IDEの拡張機能／言語サーバのバージョン表示で確認）

まとめ — GhostApproval/SymJackが示す新しい攻撃面

GhostApproval（Wiz）とSymJack（Adversa）は、AIコーディングエージェントの「承認」という安全機構が、symlinkという古い仕様によって静かに無力化され得ることを、独立した2チームが別々のツール群で実証した事例です。承認ダイアログが表示するパスと、カーネルが実際に書き込む先が食い違う——たったそれだけの食い違いが、SSH鍵の注入やエージェント設定の乗っ取りを通じてRCEにつながります。

一次ソースで確実に裏が取れるのは、Amazon QのCVE-2026-12958（CVSS 4.0で8.5・Language Servers 1.69.0で修正） です。Cursorはsymlink関連のCVE-2026-50549を3.0で修正済み（詳細は別記事）。Anthropic（Claude Code）は当初「脅威モデルの範囲外」と分類しつつ、symlink警告は報告以前に予防的ハードニングとして投入済みだったと説明しており、現行の2.1系で書き込み前のsymlink解決を強化しています——この経緯は、煽らず正確に受け止めるべきものです。そして「明示的な承認は意図された動作」という初期反応は、Google・OpenAIを含む複数ベンダーに共通していました。

ユーザーとして今できることは、明快です。各ツールを修正版へ更新し、信頼できないリポジトリを開く前に find . -type l でsymlinkを確かめる。 承認ダイアログの表示を鵜呑みにせず、自分の目で実体を確認する——この一手間が、AI開発ツール固有の新しい攻撃面に対する、最も現実的な守りになります。

参照ソース

・GhostApproval: A Trust Boundary Gap in AI Coding Assistants（Wiz） — 6種の対象・ベンダー対応・Anthropicの経緯・開示記録の一次ソース
・SymJack: the approval prompt is lying to you（Adversa AI） — 先行研究。攻撃クラスの概念と各社の初期反応
・NVD — CVE-2026-12958 — Amazon Q / Language Servers for AWS。CVSS・修正版1.69.0・公開日の一次データ
・AWS Security Bulletin 2026-047 — AWS公式の告知（自動更新の案内）
・GHSA-6v3r-4p5c-mrp5（aws/language-servers） — GitHub Security Advisory