部落格 發布於 AIA: 2026年8月2日

Claude Code GitHub Action：不可信內容如何利用讀檔工具，跨過持續整合環境的憑證隔離邊界

Microsoft 在受控研究中發現，攻擊者可以把指令放進 GitHub issue、pull request 或留言；符合條件的工作流程把這些不可信文字交給 Claude Code GitHub Action 後，Claude 可能用 Read 工具讀取 /proc/self/environ。Bash 雖然在 bubblewrap 內執行，環境變數也會先清除，但同一個程序裡的 Read 走了另一條路徑，仍能取得 ANTHROPIC_API_KEY；移除金鑰前綴有助於避開模型拒絕與 GitHub 遮罩規則。Anthropic 已修正公開研究中的敏感 /proc 讀取，部署方仍要讓所有工具共用同一套機敏憑證保護邊界，以及不由模型自行決定的固定授權規則。

Indirect Prompt InjectionCredential ExposureTool AuthorizationAI Coding AgentGitHub Security
6 項對應的 AIDEFEND 防禦手法
來源: Securing CI/CD in an agentic world: Claude Code Github action case 
作者: Microsoft Defender Security Research Team, Dor Edry, Amit Eliahu
原文發布: 2026年6月5日

威脅分析

  • 不可信 GitHub 文字會成為 agent 上下文。攻擊者不需要 repo 寫入權限，只要把偽裝成合規要求的指令放進 issue、pull request 或留言，符合條件的工作流程就可能把內容交給 Claude Code。
  • 兩條工具路徑套用不同的隔離方式。Bash 在 bubblewrap 內執行，也會經過 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB 清除環境變數；同一程序內的 Read 不受這兩項保護，可以直接開啟 /proc/self/environ。
  • 字串轉換削弱後面的過濾。攻擊指令要求 Claude 移除 Anthropic key 的前七個字元，藉此避開模型拒絕，也讓輸出不再符合 GitHub 用來遮罩 secret 的 sk-ant- 特徵。
  • 實際外洩通道取決於工作流程設定。在不同設定下，轉換後的內容可能經 WebFetch、Bash、GitHub MCP 動作或 show_full_output 記錄離開；不是每個環境都同時開放這些通道。
  • 這是受控研究，而且已有修正。Microsoft 在 2026 年 4 月 29 日回報這項問題，並表示 Anthropic 已在 Claude Code 2.1.128 拒絕讀取敏感 /proc 檔案。

適用的 6 項 AIDEFEND 防禦手法

AID-H-017.003
Decoupled Plan-Then-Execute Architecture
極高
Claude 只能提出結構化的讀檔計畫，不能直接開啟路徑。規則式動作選擇器（Action Selector）要把目標路徑解析到已核准的 repo 根目錄下，拒絕目錄跳脫，也拒絕那些只有字串前綴相同、實際卻位於核准根目錄之外的路徑。只有在確認動作符合角色允許清單後，系統才能呼叫已註冊的工具。這會直接擋下 /proc/self/environ。不過，現行實作指引沒有把檢查與開檔做成同一個不可分割動作，因此正式環境還要另外防止符號連結置換，以及檢查與使用時間差（TOCTOU）競態。
AID-H-017.007
Dual-LLM Isolation Pattern
極高
原始 issue、pull request 與留言內容，先交給沒有 repo、檔案系統、網路或憑證權限的隔離型模型（Q-LLM）解析。驗證中介元件（broker）只能透過經簽章的封裝資料，釋出允許清單中預先定義的 repo 任務欄位與不透明 GitHub 物件 ID；一般自由文字不能當成安全邊界。每項高權限工具操作提案仍須通過執行端授權。
AID-D-003.002
Sensitive Information & Data Leakage Detection
高
建立經簽章的租戶規則包。規則包要包含受保護的精確字串，用來比對移除前綴後的 Anthropic API key；也可以使用範圍受限的 RE2 規則，比對組織能重建的金鑰內容。每個完整且正規化的輸出欄位都要掃描，並產生與回應綁定的簽章證據。這只能偵測已設定的字串形式，本身不負責阻擋發布。
AID-H-006.002
Text, Markup & Structured Output Sanitization and Release Gate
高
完整回應或工具參數必須先保留；只有在上述租戶專用偵測器、遮蔽處理與資料去向政策都完成後，才能發布。只要偵測器發現問題，或發生逾時、結果格式錯誤、證據無法建立或驗證、偵測器出錯，就不得送出任何內容。這項邊界只保護確實接入發布檢查的 WebFetch、GitHub MCP、工作輸出、記錄與其他通道。
AID-H-018.004
Intent-Based Dynamic Capability Scoping
中
Read、Bash、WebFetch、GitHub 寫入與完整輸出發布，都要註冊成不同的工具名稱或能力。系統只能根據可信的工作流程設定與通過身分驗證的觸發來源，產生並簽章一份工具授權，其中列明允許的工具名稱、動作次數上限與有效期限；不能因 issue 或留言內容而擴大權限。這能讓分流任務排除對外連線與會改變狀態的工具，卻仍無法在同一個 Read 工具裡分辨 /proc 與 repo 路徑。
AID-I-001.004
Sandbox Network Egress Restrictions
中
Action 執行環境應預設拒絕對外連線，只由沙箱（sandbox）外部的控制點開放確實需要的模型與 GitHub 端點。工具政策若失效，這層控制仍可擋下任意 WebFetch 與 Bash 回連通道；但它無法管制已核准的 GitHub API 與工作流程記錄。

身為資安防禦者，我們應該這麼做

  • 把所有 Claude Code runner 與 Action image 更新到 2.1.128 或以上版本。在隔離的 repo 中，驗證 Read 與其他能存取檔案系統的工具，會拒絕敏感 /proc 路徑的直接寫法與正規化後的等價路徑、目錄跳脫，以及那些只有字串前綴相同、實際卻位於核准根目錄之外的路徑。
  • 檢查工作流程觸發條件與信任判斷。若工作會自動讀取不可信使用者提交的 issue、pull request 或留言，就不要把 secrets，以及能對外連線或改變狀態的工具，同時交給這項工作。
  • 所有模型提出的檔案動作都要通過同一個規則式選擇器。把路徑解析到核准的 checkout 根目錄後，以可信根目錄的檔案描述元（file descriptor）搭配 openat2(RESOLVE_BENEATH|RESOLVE_NO_SYMLINKS)、O_NOFOLLOW 或平台等效的不可分割機制開檔，再把同一個檔案描述元交給 Read；不能檢查完又用路徑重開。也要測試符號連結置換，以及檢查與使用時間差（TOCTOU）競態。
  • 使用沒有工具權限的隔離型模型與驗證中介元件（broker）解析不可信 GitHub 內容。高權限模型只能取得允許清單中預先定義的 repo 任務欄位與不透明物件 ID；工具範圍必須由工作流程政策產生並簽章，不能由待分析文字決定。
  • 對外連線預設拒絕；處理 secrets 的工作也要關閉 show_full_output。另外在 WebFetch、Bash、GitHub MCP、工作輸出與記錄的發布檢查中，測試移除前綴及其他轉換後的機敏值。
  • 如果 Anthropic API key 可能已外洩，就要保留工作流程輸入、工具呼叫、輸出、網路與稽核證據，撤銷並輪替該 API key、檢查模型供應商的使用紀錄，並盤點該工作原本能執行的 GitHub 動作。

2 個額外的防禦考量

轉換後機敏值的衍生關係與已核准輸出管道

現行的資料值層級去向控管指引會透過伺服器端內容 ID 查詢標記，但不會追蹤子字串的衍生關係，也不會在移除前綴後傳遞標記或追蹤隱含資料流。網路對外連線控制也無法保護已核准的 GitHub API、工作輸出或工作流程記錄。
建議做法: 能不交給模型的機敏值就保留在伺服器端，以不透明參照代替原值。WebFetch、Bash、GitHub MCP、工作輸出與記錄都要加入能識別轉換後機敏值的偵測與發布檢查，並測試移除前綴、切割、編碼、格式化、跨區塊與核准目的位址濫用。

Anthropic 金鑰的撤銷與輪替流程

上列對應控制已涵蓋讀檔阻擋、隔離、能力範圍與網路邊界。疑似外洩的 Anthropic API 金鑰仍須透過 Anthropic 官方的 API 金鑰管理流程處置。框架中的長效憑證具體實作指引，是用於 Secrets Manager 與 ECS 的 AWS IAM 存取金鑰模式，因此本文將 Anthropic 金鑰處置另列為產品特定程序，不列入上方控制對應。
建議做法: 依 Anthropic 官方的 API 金鑰管理流程撤銷或輪替受影響的金鑰，更新所有已知使用端、驗證舊值已無法通過身分驗證，並保留簽發端與使用端證據。

結論

這次問題不是 Claude Code 完全沒有沙箱，而是 Bash 與 Read 穿越同一條機敏憑證保護邊界時，走了兩套不同的控制路徑。修補版本已封鎖公開研究所用的 /proc 讀取路徑；更長期的工程要求是，把不可信 CI 文字與高權限規劃分開，讓每個檔案路徑通過同一個規則式選擇器，並確保機敏值經過轉換後，在每個輸出通道仍受到保護。