← 所有文章

程式碼倉庫不該為自己的信任投票

2分鐘閱讀
From the guide: Claude Code Comprehensive Guide

2026年4月24日，Anthropic發布了GHSA-q5hj-mxqh-vv77，這是一個CVSS 7.7的Claude Code信任對話框繞過漏洞。37天前，也就是3月18日，同一個專案發布了GHSA-mmgp-wc2j-qcv7，CVSS分數同樣是7.7。同一個代理執行階段、同樣是六週的時間窗內，出現兩個信任對話框繞過漏洞，絕非巧合。12

兩者共有的形態正是教訓所在。在3月的漏洞中，由專案控制的.claude/settings.json在工作區信任檢查之前就被讀取，而該檔案中的bypassPermissions權限模式輕易地通過了關卡。2在4月的漏洞中，惡意倉庫在.git/內提供了一個精心構造的commondir檔案，信任評估器跟隨該指標指向使用者已信任的目錄，工作區於是繼承了該信任，根本不需要顯示對話框。1

沒人開啟過的倉庫內，僅僅兩行文字就足以為工作區投下「受信任」的一票。倉庫所提供的專案層級介面（hooks、MCP伺服器設定、技能、子代理）隨後便能依據這一票進行解析，無論是在會話開始時即時載入，或是在被呼叫時才延遲載入。任何代理執行階段的下游防禦，都被一個在它們存在之前就由執行階段做出的決定所限制。

TL;DR

  • 37天內出現兩個Claude Code信任對話框繞過CVE，顯示出當倉庫控制的位元組能影響工作區信任時會出什麼問題。
  • 使用者端的立即修補方式是升級至2.1.84以上版本，縮限~/.claude.json中的信任路徑，並避免如~/Projects這種寬泛的父路徑信任。
  • 結構性的修補是一條載入順序的不變式：在工作區路徑被明確信任之前，不解讀工作區的任何位元組。

兩份公告實際修補了什麼

對照文件閱讀這些修補程式，便能讓載入順序的失敗清晰可見。修正後的版本重新排序了信任評估器被允許查閱的位元組。

3月公告描述了Claude Code在解析工作區信任之前就先解析了專案設定。2.1.53版的修補翻轉了這個順序，讓信任檢查不再於使用者做出決定之前，從工作區內讀取.claude/settings.json。24月公告則描述了信任評估器在解析工作區路徑本身時，竟跟隨了倉庫.git/目錄中的commondir檔案。2.1.84版的修補則阻止評估器在進行信任評估時，將倉庫控制的commondir內容視為權威。1兩個修補都恢復了同一條不變式：信任決策不得查閱位於候選工作區內部的位元組。

CVE的分類也指向相同的診斷。3月的漏洞被歸類為CWE-807，Reliance on Untrusted Inputs in a Security Decision（在安全決策中依賴不受信任的輸入）。34月的漏洞則被歸類為CWE-20加上CWE-77，Improper Input Validation（不當的輸入驗證）以及Improper Neutralization of Special Elements（不當的特殊元素中和處理），原因在於commondir解析將倉庫控制的位元組視為權威。1CWE不同，但破裂的假設相同：一道安全閘門讀取了它正在守護的那個產物。

信任前的介面範圍比設定參考所暗示的更廣

Claude Code記錄了一組由專案控制、在會話開始時介入的介面，這些都必須留在信任閘門之後。這一類的兩個CVE證明，只要其中任何一個進入信任決策本身，這條不變式就會崩壞。這些介面分為兩個信任分析必須分開處理的範疇：隨著倉庫複製而來的位元組，以及使用者在工作區本地新增、未提交的位元組。4567

倉庫提交的介面（隨git clone而來）。這是供應鏈介面。屬於這一群組的任何項目，都是攻擊者撰寫惡意倉庫時所能控制的。

介面 位置 影響
專案設定 .claude/settings.json 權限模式、模型、工具、hooks。被CVE-2026-33068利用。2
專案提示 CLAUDE.md 合併進系統提示的專案指令。
斜線命令 .claude/commands/*.md 專案定義的命令；部分已被技能取代。7
子代理 .claude/agents/*.md 具名的子代理定義。
MCP伺服器設定 .mcp.json 在會話開始時引用的工具提供者。5
技能 .claude/skills/* 範圍化的任務組件。
原始碼位元組 樹狀結構任意位置 對話框後讀取作為脈絡。

工作區本地介面（預設不提交）。這些不會經由供應鏈進入工作區；它們是本地使用者建立後才出現的。它們仍位於工作區路徑內，因此信任閘門在路徑被批准前，仍須將其視為不受信任。

介面 位置 影響
專案本地設定 .claude/settings.local.json 工作區本地覆寫，通常被gitignore。4

Hooks位於.claude/settings.json之中，而非獨立檔案；4月公告描述攻擊者直接填寫該鍵值。164月的漏洞還揭露了一個根本不在Claude Code設定參考之中的介面：一個git內部檔案commondir，其作用是將工作樹解析回其父倉庫。8惡意倉庫提供了精心構造的commondir配置，當Claude Code在信任評估期間跟隨該指標時，便繼承了目標路徑的信任。git內部介面打破了專案設定介面的數量限制，這才是真正的教訓。分類體系並非封閉的。攻擊面是由在對話框觸發前哪些位元組被讀取所定義，而任何能影響路徑解析或設定的東西都是攻擊目標。

這個模式正是MCP伺服器是新的攻擊面在另一個高度上指出的。9MCP伺服器在生態系跟上其影響之前，就已將工具提供者介面急遽擴張。信任對話框繞過正是同樣的形態，只是在更低一層。每一個讓倉庫得以預先設定代理的便利功能，都會在上方分類表中加上一列。每一列都是下一個此類CVE的候選者。

櫥櫃的背面：載入順序的不變式，而非更聰明的對話框

Paul Jobs教導Steve，櫥櫃的下方應與正面同樣講究。10櫥櫃的隱喻在這裡並非裝飾。它是修補方案的脊樑。

信任對話框就是櫥櫃的背面。使用者看不到載入順序。他們看到對話框、按下信任，便假設工作區內的所有位元組在那一按之前都是惰性的。實作必須贏得這個假設。當實作未能做到時，這個假設本身就成了攻擊面。

載入順序就是決定這個假設是否被贏得的不變式。從兩份公告與公開的Claude Code設定文件來推測，最簡模型大致如下：216

  1. 從~/.claude/settings.json讀取使用者設定。
  2. 從~/.claude/settings.local.json讀取使用者設定。
  3. 評估目前工作區路徑是否受信任。
  4. 若否，顯示對話框。若使用者按下信任，則持久化該路徑。
  5. 讀取倉庫內專案範圍的.claude/settings.json。
  6. 讀取專案範圍的.claude/settings.local.json。
  7. 從合併後的設定中解析hooks、MCP伺服器、技能與子代理。
  8. 執行SessionStarthooks。

公告並未精確記錄每一步，且技能、子代理與MCP相對於設定合併的位置屬於使用者看不見的實作細節。但公告確實建立的是第3步的邊界。第3步之前所解析的任何東西都屬於受信任輸入區。第3步及之後所解析的任何東西，都不得查閱工作區位元組。3月的漏洞調換了第3步與第5步：專案設定先被解析，而這些設定所設立的權限模式（bypassPermissions）輕易地通過了第3步的信任檢查。24月的漏洞則將攻擊移入第3步本身：工作區路徑解析查閱了由倉庫控制的commondir檔案，偽造的內容讓信任檢查解析至攻擊者所選擇的受信任路徑。1無論哪一種，到了第7步或第8步時，工作區早已被信任，每一個專案層級的介面都依據這一票載入。

櫥櫃背面所要求的規則只有一句話：在使用者明確信任工作區路徑之前，不解讀工作區內的任何位元組。不讀.claude/settings.json。不讀commondir。不讀CLAUDE.md。不讀檔名清單。不讀hook檔案。不讀MCP伺服器設定。只要它位於工作區之內，決定信任的程式碼就不會看它。

Visual Studio Code在2021年5月以Workspace Trust（1.57版）發布了這項修補。自該功能推出以來，核心的資料夾信任類別未曾出現任何已發布的繞過漏洞，雖然圍繞受信任網域與擴充套件行為的鄰近議題仍持續出現。11122.1.53版（即3月公告所引用的修補版本）透過調換第3步與第5步，落實了Claude Code版本的這條不變式。22.1.84版（即4月公告所引用的修補版本）則透過拒絕在信任評估期間跟隨倉庫控制的commondir檔案，落實了同一條不變式。1兩者都是恢復不變式的修補，而非發明新的防禦。

Steve測試拉出了下一條線索：Blake會願意在這上面署名嗎？13在這六週時間窗內，Claude Code的答案是否定的，因為廠商曾兩度簽核、出貨並修補此類繞過漏洞。這是廠商該負責修補的標準。最低值得交付的產品正是該署名所引用的標準。14最低是範圍的限制，不是品質的折扣。最低可行的信任對話框是一個能擋下廉價情境的對話框。最低值得交付的信任對話框，則是一條載入順序的第一步——這條順序在使用者做出決定前，拒絕解讀任何倉庫位元組。你交付的產品，正是你拒絕在獲得授權前解讀的位元組。

不變式所要求的三項修補

這條規則就是不變式。三個模式由它直接衍生。

單向閘門。做出信任決策的程式碼只讀取路徑、使用者的點擊，以及位於工作區之外、儲存於~/.claude.json的持久化信任狀態。15其他什麼都不讀。任何讓工作區檔案參與信任決策的重構，都是退化。

路徑解析不得帶來傳遞性信任。較佳的不變式是：工作樹、子模組、include檔案以及符號連結目標各自需要獨立的提示。Visual Studio Code的Workspace Trust則相反，允許父資料夾的信任套用至子資料夾，這個選擇正是當路徑解析被偽造時，諸如~/Projects這種寬泛的父路徑信任會被利用的原因。較嚴格的規則付出多幾次對話框的代價，卻移除了整個傳遞性信任面；較寬鬆的規則維持低摩擦，但也接受路徑解析的漏洞會變成信任解析的漏洞。11

在信任讀取順序的回歸測試中加入對抗式fixture。精心構造的對抗式倉庫，提交一些金絲雀工作區檔案。測試斷言：在對話框被確認之前，沒有任何程式碼路徑讀取這些金絲雀檔案。若未來執行階段的變更在信任評估期間讀取了任何金絲雀檔案，建置便失敗。CWE-501，Trust Boundary Violation（信任邊界違規），是值得在測試分類中追蹤的更廣家族，與已發布公告所使用的更具體CWE-807與CWE-20/CWE-77分類並列。16

三者皆不昂貴。第一個是程式碼的缺席。第二個的代價是使用者可見的摩擦。第三個是一次工程投入加上後續的紀律。信任引導鏈的妥協屬於一個縱深防禦姿態並不適用的類別，因為信任下游的每一層都依據工作區剛剛協助做出的信任決定執行。在信任之外建立防禦，於鷹架層而言根本不可能，因為當信任解析後，工作區所能讀取的，正是這些鷹架。

廠商必須交付這條不變式。信任對話框繞過CVE就是觀察者衡量廠商是否達標的方式。六週內出現兩個並非雜訊，而是一個訊號：這條不變式還沒以建置強制的斷言形式被編進測試套件。在它編進去之前，這個類別的下一個CVE，只是在等找到第十個輸入。

倉庫不該為自己的信任投票。信任是被評估的產物唯一不該插手協助做出的決定。代理防禦的其他每一層（hooks、技能、驗證器、偵測器、護欄）都位於那一票的下游。當投票被操縱時，下游的工作就只是擺設。櫥櫃的正面修飾無法挽救它的背面。

常見問題

什麼是Claude Code信任對話框繞過？

Claude Code信任對話框繞過發生於不受信任的工作區在使用者明確批准之前，就被當成受信任處理。在2026年3月的CVE中，倉庫控制的設定在信任被評估之前就影響了權限模式。在2026年4月的CVE中，精心構造的git工作樹/commondir佈局導致信任透過已受信任的路徑被解析。

我該如何縮限~/.claude.json中的信任路徑？

開啟~/.claude.json並檢視projects對應表。尋找以下類型的條目：hasTrustDialogAccepted為true、但目錄內已無有效程式碼的；像~/Projects這種寬泛父路徑的；以及任何與工作樹相鄰佈局重疊的路徑。逐倉庫的信任會增加對話框，但能避免一個被接受的父路徑悄悄涵蓋每一個子路徑。

為什麼父路徑信任對Claude Code來說很危險？

父路徑信任很危險，因為一個被接受的目錄可以涵蓋許多子工作區。若路徑解析被偽造，或惡意工作樹指回該父路徑，子倉庫便能繼承從未被授予的信任。逐倉庫的信任會增加摩擦，但能阻止無關倉庫之間的傳遞性信任。

哪一條不變式可防止信任對話框繞過？

不變式是：在使用者明確信任工作區路徑之前，不解讀工作區內的任何位元組。信任程式碼可以讀取路徑、使用者的點擊，以及倉庫之外的持久化信任狀態。它不應在對話框之前讀取.claude/settings.json、CLAUDE.md、.mcp.json、hooks、技能、commondir，或任何由倉庫控制的檔案。

參考資料

  1. Anthropic, “Trust Dialog Bypass via Git Worktree Spoofing Allows Arbitrary Code Execution,” GHSA-q5hj-mxqh-vv77, April 24, 2026. CVE-2026-40068. CVSS v4 7.7. Affects 2.1.63–2.1.83. Fixed in 2.1.84. ↩↩↩↩↩↩↩↩

  2. Anthropic, “Workspace Trust Dialog Bypass via Repo-Controlled Settings File,” GHSA-mmgp-wc2j-qcv7, March 18, 2026. CVE-2026-33068. CVSS v4 7.7. Fixed in 2.1.53. ↩↩↩↩↩↩↩

  3. MITRE, “CWE-807: Reliance on Untrusted Inputs in a Security Decision,” cwe.mitre.org. ↩

  4. Anthropic, “Claude Code settings reference,” code.claude.com docs. Project-level configuration surface and .claude/settings.local.json workspace-local override semantics. ↩↩

  5. Anthropic, “Model Context Protocol configuration,” code.claude.com docs. .mcp.json format. ↩↩

  6. Anthropic, “Hooks reference,” code.claude.com docs. Lifecycle event taxonomy. ↩↩↩

  7. Anthropic, “Skills reference,” code.claude.com docs. .claude/skills/* format and the skills/commands relationship. ↩↩

  8. Git, “gitrepository-layout: Git Repository Layout,” git-scm.com. commondir file format for worktrees. ↩

  9. Author’s analysis in MCP Servers Are the New Attack Surface, April 8, 2026. ↩

  10. David Sheff, “Playboy Interview: Steven Jobs,” Playboy, February 1985. Paul Jobs’s cabinet-back lesson is told in Steve Jobs’s own words in the interview. ↩

  11. Microsoft, “Workspace Trust in Visual Studio Code,” code.visualstudio.com/blogs, July 6, 2021. Shipped in Visual Studio Code 1.57 (May 2021 release). ↩↩

  12. Microsoft, “Workspace Trust,” Visual Studio Code documentation. Folder-trust semantics and the parent-folder trust behavior. ↩

  13. Author’s analysis in The Steve Test. “Would I sign my name to this without flinching?” ↩

  14. Author’s analysis in Minimum Worthy Product. Minimum as scope constraint, worthy as quality bar. ↩

  15. Anthropic, “Claude Code configuration file,” code.claude.com docs. ~/.claude.json stores per-user settings including trusted project paths. ↩

  16. MITRE, “CWE-501: Trust Boundary Violation,” cwe.mitre.org. ↩

相關文章

Project Glasswing：當模型找到太多漏洞時

Anthropic打造了一個能找出數千個零日漏洞的模型，隨後將其限制給12個合作夥伴使用。Project Glasswing對於代理輔助安全的意義——4月19日更新，內容涵蓋Opus 4.7、現已上線的Cyber Verification …

1 分鐘閱讀

Ralph 迴圈：我如何在夜間運行自主 AI 代理

我建構了一套自主代理系統，搭配停止鉤子、生成預算與檔案系統記憶體。以下是失敗經驗與真正能交付程式碼的方法。

3 分鐘閱讀