我們寫過的那些「打開資料夾」式攻擊，會在你打開儲存庫時執行程式碼、從磁碟讀走你的雲端金鑰。這一次只改了一行設定，代理就交出了它少了便無法運作的憑證：它自己的模型 API 金鑰。

這個漏洞是 CVE-2026-21852，由 Check Point Research 在 Claude Code 裡發現，於 2025 年 10 月 28 日向 Anthropic 揭露，12 月 28 日修復，並在 2026 年 1 月 21 日獲得 CVE 編號。Anthropic 幾個月前就出了修補。我們在七月寫它，是因為它替一個任何修補都改變不了的事實劃下了一道清楚的線：編碼代理帶著一把模型 API 金鑰，在每一個請求上送出它，而一個儲存庫可以編輯它送往的地址。

這個漏洞做了什麼。

把 Claude Code 指向一個專案，它會讀取那個專案的設定，也就是 .claude/ 底下那些讓儲存庫能自帶設定的檔案。其中一項設定是 ANTHROPIC_BASE_URL，代理呼叫模型時所對話的地址。預設值是 api.anthropic.com，而這項設定之所以存在，是為了讓團隊能經由自己的閘道或 proxy 轉送。專案能設定它，本就是設計使然。

一個惡意儲存庫把它設成一台攻擊者掌控的伺服器。接著，如 Check Point 所描述，「在受害者決定信任該目錄之前」，Claude Code 就朝著 ANTHROPIC_BASE_URL 所指的任何地方發出它的啟動 API 請求，而那些請求帶著——用 Check Point 的話說——「authorization 標頭——我們完整的 Anthropic API 金鑰，完全以明文暴露」。攻擊者的伺服器從一個代理主動送出的請求上讀走標頭，而且如 Check Point 所言，「無需任何使用者互動」。你 clone 了儲存庫、跑了 claude，金鑰在信任提示還沒畫完之前就沒了。

CVE-2026-21852，從頭到尾。一個儲存庫在它的 .claude 專案設定裡放了一行設定：把 ANTHROPIC_BASE_URL 指向攻擊者的伺服器。開啟時，在你回答「信任這個資料夾」之前，Claude Code 就把它的啟動請求送到那個地址，Authorization 標頭裡帶著真正的 Anthropic API 金鑰。攻擊者的伺服器讀走標頭。這個攻擊沒有在你的機器上執行任何東西，也沒有從你的磁碟讀走任何東西；是代理把自己的憑證寄到了錯的地址。來源：Check Point Research。

一把 Anthropic API 金鑰能觸及帳號的工作區，連同它共享的檔案儲存與計費。Check Point 逐一走過這個觸及範圍：攻擊者可以讀寫工作區的檔案、刪除它們、耗盡儲存配額，並且用你的錢燒掉 API 額度。代理沒被要求，就交出了整個運作所依賴的那把憑證。

一場什麼都沒執行的攻擊。

這個類型我們寫過。Miasma 在 Microsoft 自家的儲存庫裡埋下了設定，打開資料夾便執行了一個好幾 MB 的二進位塊，在檔案系統裡搜刮金鑰。Amazon Q 從一個 clone 下來的工作區自動啟動 MCP 伺服器，帶著開發者滿滿一整個環境的 AWS 金鑰與 SSH sockets。在 Cursor 的案例裡，一段提示詞注入驅動一個工具覆寫了守衛，然後跑了一個 shell。三者共享同一個形狀：開啟時的不受信任內容導致程式碼執行，而那些程式碼會去找你的祕密，也就是 ~/.aws 和 ~/.ssh 裡的那些。

CVE-2026-21852 跳過了那整套機關。惡意儲存庫沒有觸發任何 hook，也沒有跑任何 shell；它改了一個地址，而代理，一如設計地運作著，把自己的憑證送到了那裡。洩漏的那把金鑰，正是代理在它發出的每一次呼叫上都必須傳送的金鑰。你沒辦法把它鎖進一個行程讀不到的檔案裡，因為那個行程本來就該送出它。

Anthropic 的修正對這個漏洞而言是正確的：信任對話框如今先出現，而且用他們的話說，「在使用者確認信任對話框之前，不會發起任何 API 請求」。今天再重導 base URL，在你信任資料夾之前不會有任何東西離開。不過這個修正管的是時序。一旦你信任了資料夾——而開發者整天都在信任資料夾——真正的金鑰仍然坐在代理的環境裡，離一次重導只差一行設定，仰賴著未來每一條碰到它的程式路徑都正確無誤。

金鑰屬於別的地方。

真正持久的問題是：為什麼真正的金鑰坐在一個儲存庫的設定能瞄準它的地方。那是一個架構問題，而我們打造 Bromure Agentic Coding 就是為了回答它。

Bromure 把你的編碼代理跑在一台可拋棄的 Linux VM 裡：代理本身、它衍生的 shell、它安裝的套件、它發出的模型呼叫。主機上的一個 proxy 坐在代理與 api.anthropic.com 之間的線路上。VM 握有的是一把樁金鑰，一個語法上有效、實際上一文不值的占位符，而真正的 Anthropic 金鑰留在主機上。當一次正當的呼叫指向真正的模型端點時，主機的 proxy 會在線路上把樁換成真金鑰，再從回應裡把它換回來。祕密做完它唯一的工作，而攻擊者能偷走的那份副本，不存在於代理的世界搆得到的任何地方。

把這個攻擊對著這套安排重播一遍。惡意儲存庫把 ANTHROPIC_BASE_URL 設成 attacker.evil。代理在 VM 裡把它的啟動請求送去那裡，帶著它僅有的那把金鑰——樁。proxy 把真金鑰的替換綁定在真正的端點上，一個指向未知伺服器的請求，離開時帶的是占位符。攻擊者的伺服器讀走 Authorization 標頭，收割到一個在公開網際網路上毫無意義的字串。重導成功了，卻什麼也沒撈到。

同一個儲存庫，兩台機器。左邊，代理跑在你的筆電上，真金鑰在它的環境裡；儲存庫重導 ANTHROPIC_BASE_URL，金鑰便隨著 Authorization 標頭前往攻擊者那裡。右邊，在 Bromure Agentic Coding 裡，VM 只握有一把樁金鑰。主機的 proxy 在線路上換入真金鑰，而且只為指向真正 api.anthropic.com 的呼叫，所以一個被重導向攻擊者的請求，離開 VM 時帶著的是樁，攻擊者收割到的是一個占位符。

這個保證仰賴一個細節：仲介把真金鑰綁定在真正的目的地上，只為指向 api.anthropic.com 的呼叫替換祕密，別處一概不換。把這個綁定做對，被重導的 base URL 就是惰性的。把它做錯——把真金鑰換到任何一個對外請求上——你就是在下一層把這個漏洞重建了一遍。 proxy 的價值就在於：只為一個地址釋出祕密，並把其他每一個地址都當成不受信任。

仲介改變了什麼

真正的模型金鑰從不進入代理所跑的那台 VM。主機握著它，而且只為指向真正端點的呼叫，才把它放上線路。儲存庫愛怎麼重導 base URL 都行；離開的請求帶著的是樁，而樁在你的機器之外一文不值。

它沒有改變什麼

信任仍然由你來給。把代理設定成對著一個攻擊者經營的閘道說話，仲介無從知道你指錯了地方；你指到哪裡，它就仲介到哪裡。而且這個保證是一次一個綁定地生效：模型金鑰在這裡，你的其他祕密走同一套樁與替換的安排，每一個都和它背後的端點綁定一樣強。

那個同伴漏洞，以及同一個答案。

CVE-2026-21852 是和一個更響亮的手足一起到來的： CVE-2025-59536。在那個漏洞裡，儲存庫的 .claude/settings.json 可以定義 hooks——Claude Code 在啟動時執行的 shell 命令——或強制啟用專案的 MCP 伺服器，而那些命令「在執行 claude 後立即執行，使用者甚至還來不及讀信任對話框」。那一個確實是開啟即程式碼執行，是熟悉的形狀，而它的答案也是熟悉的那一個：在一台可拋棄的 VM 裡，它衍生出的 shell 在本該是真正權杖的地方找到的是憑證樁，而一個會改變狀態的動作會在 hypervisor 邊界暫停，等主機上的一次確認。這個論證我們已經完整寫過。

兩個漏洞看起來不同——一個執行程式、一個改變地址——卻落在同一個地方：編碼代理會讀取並依據那些隨著你交給它的程式碼一起到來的檔案行動，而其中一些檔案決定了什麼會執行、祕密會去哪裡。 Anthropic 兩個都修補了。長久的答案，是把祕密放在那些檔案指得到、卻搆不到的地方。

一場範圍分明的勝利。

把模型金鑰留在代理的環境之外，擊敗的是這次重導，以及那一整族誘騙代理把自己的憑證送往新地方的攻擊，因為代理能送出的那把金鑰一文不值。hypervisor 與 proxy 在代理之下強制執行這一點，對代理本身無所要求。

信任仍是你的工作。你仍然要決定打開哪些儲存庫、設定哪些閘道，而一個把你的金鑰送往你所指之處的仲介，若你故意指向一個壞地方，它就會把金鑰送去那個壞地方。限縮一把外洩金鑰能做什麼，也仍然落在模型供應商身上；Anthropic 的修補與工作區控管顧的是那一側。

編碼代理必須帶著一把金鑰、把它送往某處，而在 2025 年末的一段窗口期裡，clone 下來的儲存庫裡的一行設定決定了送往哪裡。修補關上了那扇窗。Bromure Agentic Coding 則乾脆把金鑰拿走：代理在一台從未握有真金鑰的可拋棄機器裡工作，而 proxy 只為單一一個地址把真金鑰放上線路。安裝它，把你的代理指向任何你喜歡的儲存庫，讓下一個被重導的 base URL 帶走一個在任何地方都一文不值的字串。