GhostApproval：六款 AI 程式設計助理請求權限，卻指錯了檔案

2026 年 7 月 8 日，安全公司 Wiz 公布了 GhostApproval，這是一項研究發現：在儲存庫中植入一個符號連結，會讓六款 AI 編碼助理寫入其工作區之外的檔案——寫入 ~/.ssh/authorized_keys，這會授予持續的免密碼 SSH 存取權，或寫入 ~/.zshrc，該檔會在下次 shell 啟動時執行——而確認對話方塊卻只顯示該連結所偽裝成的無害檔案。Wiz 測試了 Amazon Q Developer、Anthropic 的 Claude Code、Augment、Cursor、Google Antigravity 和 Windsurf，並回報這六款全都出現此模式。目前尚未有野外利用的通報：這項工作屬於概念驗證示範，且該檔案庫條目並未記錄任何實際危害。三家廠商已發布修正，兩家確認收到報告後便不再回覆，還有一家則爭辯這種行為根本不算漏洞。 Orca AI Incident Archive 保存了這項發現的完整記錄，與其他歸在其 SANDBOX 類型標籤下的條目並列。

這個基本手法本身已是舊聞。符號連結跟隨（symlink following）被編目為 CWE-61，數十年來一直是攻擊基本手法——Wiz 列出它在競態條件、套件管理器與容器逃逸中的較早用途——而這些全都依賴某個工具在未先解析的情況下寫入使用者可控的路徑。讓這項發現值得命名的，是第二層：在數個產品中，助理自身的推理辨識出危險的目的地，而顯示給人的提示卻把它隱藏了。Wiz 將其列為 CWE-451，關鍵資訊的使用者介面不實呈現。安全邊界確實存在。但人要運用它所需的資訊卻不存在。

這個把戲如何運作，以及它最終落在什麼上

Wiz 的惡意儲存庫刻意設計得平淡無奇。它包含一個名為 project_settings.json 的符號連結，該連結指向開發者的 SSH 授權金鑰檔案，另有一個 README 指示代理程式在工作區設定時更新那個「config」。當開發者要求助理依照 README 操作時，代理程式會跟隨該連結並寫入攻擊者的公開金鑰。如果該機器執行攻擊者可觸及的 SSH 服務，從此即可免密碼登入。第二種變體將同一個誘餌指向 ~/.zshrc，因此酬載會在下次開啟終端機時執行，完全不需要 SSH 存取。

Wiz 對這項技術故障的描述很簡短：沙箱（若存在）不會驗證正規路徑，因此針對專案內部所發起的寫入，會落在連結所指向的任何位置。該公司的概念驗證以其自身說法，在「6 款頂尖的 AI 程式設計助理」中的 6 款重現了此問題，並為每一款發布了螢幕截圖。受影響的對象，是任何在這些工具中開啟並非由自己撰寫的儲存庫的人——在正常的開發者工作流程中，這包括分叉專案、第三方相依套件，以及對外部貢獻者分支的任何程式碼審查。

命名錯誤檔案的那個對話框

最明確的證據來自 Claude Code。在 Wiz 的測試中，該代理的推理——按該公司的引述——寫道：「我可以看到 project_settings.json 實際上是一個 zsh 設定檔。」使用者看到的權限提示詢問：「要對 project_settings.json 進行這項編輯嗎？」代理知道寫入的目標位置；授權的人卻不知道。Wiz 稱由此產生的同意「實質上是空的」，並稱人在迴路中的檢查只是橡皮圖章。

有三款產品讓這個落差比錯誤標示還糟。Windsurf 把檔案寫入磁碟，早於Accept 與 Reject 按鈕出現，因此那個對話框只是復原選項，而非授權關卡——Wiz 表示，等到使用者能夠拒絕時，金鑰早已就位。Amazon Q Developer 也呈現相同的順序，只在寫入後提供一個復原按鈕。Augment 則完全沒有詢問：Wiz 示範了一次透過符號連結的讀取，在聊天紀錄中顯示出專案外一個作為誘餌的 AWS 憑證檔案；以及一次對 ~/.ssh/authorized_keys 進行符號連結寫入，完全沒有任何對話框。另一方面，Cursor 和 Google Antigravity 顯示了未解析的路徑，並要求使用者點擊以授權解析後的路徑。

Wiz 的首次測試於 2026 年 2 月 10 日進行，報告則於 2 月 12 日至 3 月 5 日間發出。其披露時程記錄了各方的確認：Anthropic 於 2 月 15 日、Augment 於 2 月 24 日、Google 於 2 月 26 日、Cursor 於 3 月 2 日、AWS 於 3 月 6 日，以及擁有 Windsurf 的 Cognition 於 6 月 23 日。公開披露是在首次報告後約五個月才進行。

六個供應商，三種答案

Wiz 依自身嚴重性分級評比這些發現，從 AWS 的 High 到 Augment、Cursor、Google Antigravity 與 Windsurf 的 Critical。三家廠商將該報告視為漏洞並發布修補。該存檔將此條目評為高嚴重性、信心等級 A，且主要公告在機制上與 Wiz 一致。

• Amazon Web Services。高嚴重性，追蹤編號為 CVE-2026-12958，並已在 Language Servers for AWS 1.69.0 中修復。AWS 自家的公告 2026-047-AWS 於 2026 年 6 月 23 日發布，確認 1.69.0 之前存在「缺少符號連結驗證的問題」，並列出含有此修正的最低外掛程式版本：Amazon Q Developer for Visual Studio Code 2.20、Amazon Q Developer for JetBrains 4.3、Amazon Q Developer for Eclipse 2.7.4，以及 AWS Toolkit with Amazon Q for Visual Studio 1.94.0.0。公告指出，沒有暫行解決方法，語言伺服器會自動更新，除非網路設定阻礙更新；並感謝 Wiz 的協調揭露。CNA 記錄依 CVSS 4.0 將該問題評為 8.5 分，依 CVSS 3.1 評為 7.8 分。

• Cursor。關鍵等級，追蹤編號為 CVE-2026-50549，已於 Cursor 3.0 中修復。該記錄由 GitHub 以 CNA 身分於 2026 年 6 月 25 日發布，在 CVSS 4.0 下評分為 9.3。其描述對攻擊者的詮釋與 Wiz 的儲存庫說法略有不同：惡意代理程式會在工作區內建立符號連結，並迫使路徑正規化失敗——原因可能是目標不存在，或是該路徑的讀取權限遭到移除——之後寫入便會在未經核准的情況下退回原始路徑，並可能覆寫沙箱輔助程式，以達成非沙箱執行。

• Google.Wiz 將 Antigravity 評為 Critical，並將修復記錄為 1.19.6 版，於 2026 年 5 月 22 日部署。其嚴重性欄位顯示「Pending」，而根據 Wiz 的說法，Google 當時正在評估是否發布 CVE；公開紀錄中並未出現 Antigravity 的 CVE 識別碼。

• Augment。依 Wiz 的評級為嚴重，於 0.754.3 版測試，2026 年 2 月 24 日獲確認，發布時尚未修補。雲端安全聯盟（Cloud Security Alliance）針對此發現的研究報告記載了 Augment 的反駁論點，即代理程式是在使用者本人的憑證下運作。

• Windsurf。依 Wiz 評級為 Critical，於組建 V1.9566 測試，Cognition 於 2026 年 6 月 23 日確認，且發布時尚未修補。

• Anthropic. 有爭議。沒有 CVE，且 Claude Code 的受測版本 2.1.42 在 Wiz 的表格中狀態為「Rejected」。

Anthropic 的拒絕，以及早於報告的修正

Anthropic 對 Wiz 的回覆是經過深思熟慮的拒絕。根據 Wiz 的引述，該公司寫道：「這超出我們目前的威脅模型範圍。」{{1}}「當使用者首次在某個目錄中啟動 Claude Code 時，必須先確認他們信任該目錄，才能開始工作階段。{{2}}您所描述的情境涉及使用者在含有惡意符號連結的目錄內，明確確認某個權限提示，而這超出了 Claude Code 的威脅模型範圍。」{{/2}}{{/1}}該工單最後以「Informative」結案。

那個推論具有連貫的結構：使用者信任該目錄，然後核准了操作，因此兩個同意時刻都受到尊重。Wiz 的反駁是，知情同意需要準確的資訊——核准 project_settings.json，而寫入卻落在 ~/.ssh/authorized_keys，形式上是一項決定，實質上卻是空洞的決定。Wiz 並未宣稱已定論哪個立場正確，本文也沒有。實務上的觀察是，AWS、Google 和 Cursor 採取了另一種看法並修補了。

Wiz 亦回報，Claude Code 在這場爭議期間已有所變更：該公司寫道，目前版本會解析符號連結，並在寫入敏感檔案前發出警告；同時指出，Anthropic 拒絕說明此事是否與該報告有關。2026 年 7 月 7 日，Anthropic 提供了一則由 Wiz 引述的更正：「Edit/Write 權限對話框中的符號連結警告於 v2.1.32（2026 年 2 月 5 日）推出，比本報告提交給我們早九天。它是根據內部審查進行主動安全強化的一部分而新增的。拒絕評論是我們分診系統的自動回覆。」

版本時序對得上，但關於變更內容的公開紀錄卻對不上。Claude Code 2.1.32 於 2026 年 2 月 5 日 17:03 UTC 發布至 npm registry，這比 2 月 14 日的報告早了九天，與 Anthropic 的說法完全一致。然而，該版本的公開 changelog 條目列出了十二項變更，包括 agent teams、memory recording 以及若干 UI 修正，其中卻沒有任何一項提到符號連結或權限對話框。最早描述這種確切行為的 changelog 條目出現得晚得多：2026 年 9 月 22 日發布至 npm 的 2.1.280 版記載「修正透過符號連結路徑進行的寫入被以其樹內拼寫判定：提示會指明寫入實際落於何處」，而 2026 年 10 月 1 日的 2.1.287 版則記載，透過儲存庫提交的符號連結寫入敏感檔案時，shell 寫入現在會指明其落點並等待真人確認。Wiz 自身觀察到 2.1.173 及之後的版本會解析符號連結，這也同樣落在報告之後，因為 2.1.173 是在 2026 年 6 月 11 日發布。

什麼是已經確立的，什麼不是

• 已確立。機制如下：儲存庫中的一個誘餌符號連結、一個跟隨該連結的代理程式、一次落在工作區之外的寫入，以及一個指出錯誤路徑的確認介面。Wiz 在全部六項產品中重現了此問題，並公布截圖。已有兩筆 CVE 記錄，並由其 CNA 發布；AWS 的公告也獨立確認了低於 1.69.0 的漏洞與修復。Anthropic 並未否認該行為發生過；它爭議的是這是否構成一種漏洞。

• 單一來源。Augment、Windsurf 與 Google Antigravity 的嚴重性評級是 Wiz 的判斷，而非 CNA 分數，因為這三者皆未發布任何 CVE。「Windsurf 與 Amazon Q 會在對話框出現前寫入」的主張，是依據 Wiz 的截圖與敘述；尚無廠商公開證實此先後順序。

• 有爭議。工具是否對使用者負有保護義務，使其免於受欺騙性工作區所害，抑或目錄信任加上一次點擊就能解決這個問題。Anthropic 認為是後者；Wiz 則表示，它顯示的提示讓那次點擊變得毫無意義。檔案庫並未將該紀錄標示為有爭議：事實已獲共識，只有詮釋仍有爭議。

• 尚未確認。Augment 與 Windsurf 自文章發表後是否已修復此漏洞。本文所審閱的所有報導，包括雲端安全聯盟（Cloud Security Alliance）2026 年 7 月 15 日的說明，仍將兩者描述為未修補；亦未發現任一廠商發布公開修復通知。

日期本身帶有一個小插曲。Wiz 的貼文及其披露時間線都寫的是 2026 年 7 月 8 日，Infosecurity Magazine 則稱概念驗證於 7 月 7 日發布，其自身的報導日期為 7 月 9 日，而檔案條目的日期是 2026 年 7 月 9 日，精確到日。這項發現、相關報導與檔案在「哪一週」上並無分歧；它們在「哪一天」上最多相差兩天。

關於這六個漏洞之一的早期研究，值得另行記上一筆。CSO Online 的 Evan Schuman 於 2026 年 7 月 9 日撰文指出，Cato Networks 曾在 Wiz 更廣泛的研究之前，回報過該漏洞僅涉及 Cursor 的版本。SecurityWeek 於 2026 年 7 月 3 日刊出的該研究報導，將其命名為 DuneSlide，並將 CVE-2026-50548 與 CVE-2026-50549 指派給這兩個漏洞，兩者皆評為 9.8，還將修復它們的 Cursor 3.0 發行版日期定為 4 月 2 日——這些數字與 Wiz 的時間線不符：Wiz 將 Cursor 的修補程式發布時間定在 6 月 5 日；也與 6 月 25 日發布、評分為 9.3 的 CNA 記錄不一致。9.8 與 9.3 是同一漏洞的兩個評分者；4 月與 6 月這兩個日期，可能分別描述的是發行版與公告，而不是對修補程式何時發布意見相左。

之後有什麼改變？

具體來說，Amazon Q Developer 使用者已改用語言伺服器 1.69.0，在大多數設定下是自動完成；Google Antigravity 使用者則自 2026 年 5 月 22 日起改用 1.19.6；Cursor 使用者改用 3.0；Claude Code 使用者則改用一個能解析連結的版本，另有進一步的提示保真度變更於 2026 年 9 月與 10 月間在 2.1.280 和 2.1.287 中推出。至於 Augment 與 Windsurf 使用者，根據截至發布時可取得的證據，他們只得到一個值得留意的日期，除此之外別無其他。

Wiz 自身的建議範圍狹窄且偏技術性：在顯示提示前先解析符號連結；當解析後的路徑落在工作區之外時明確提出警告；且在取得明確授權前絕不寫入磁碟，讓對話框成為把關機制，而不是復原按鈕。雲安全聯盟（Cloud Security Alliance）的說明則加入治理框架：將程式設計助理視為具備檔案系統存取權限的特權軟體，而非編輯器外掛，並直接詢問供應商，在確認提示出現之前是否已解析路徑。經 CSO Online 引述的 IDC 的 Katie Norton 指出，殘餘風險在於供應鏈原本就已運作的地方：外部貢獻者、分叉的儲存庫與第三方相依套件，「而非內部撰寫的程式碼」。

仍未定案的是設計問題，而非程式錯誤。六個獨立打造的產品都收斂到同一套流程——顯示所請求的路徑、信任那次點擊——而之後的分歧在於責任歸屬，不在於機制。檔案條目帶有一個里程碑標記，那是檔案庫的判斷，認為這筆紀錄描述的是一種類別，而非單一廠商的失誤，而這種解讀很難反駁：同一套簡短的概念驗證成功了六次。