網路安全研究機構 Wiz 近期揭露了 Snowflake 在其公開的 .NET 連接器儲存庫（snowflakedb/snowflake-connector-net）中存在的一個嚴重漏洞。這個漏洞屬於 GitHub Actions 工作流注入（Workflow Injection），允許攻擊者透過提交精心設計的 GitHub Issue，在 Snowflake 的自動化工作流中執行任意指令，進而導致內部敏感憑證外洩。
背景與漏洞成因
GitHub Actions 是許多開發團隊用來實作 CI/CD（持續整合與持續部署）的自動化工具，允許開發者定義特定事件（如提交程式碼、開啟 Issue 或 Pull Request）觸發的自動化任務。在 Snowflake 的這個案例中，儲存庫內定義了一個名為 jira_issue.yml 的工作流檔案，其目的是在有新的公開 Issue 被建立時，自動將相關資訊同步至內部的 Jira 追蹤系統。
然而，該工作流在設計上存在重大缺陷：它直接將由使用者控制的 Issue 標題與內容，透過字串插值的方式直接放入 shell 的執行區塊（run: block）中。在這種機制下，如果攻擊者在 Issue 的標題或內容中插入特定的 shell 指令符號（例如反引號或分號），GitHub Actions 的執行環境會將其視為指令而非純文字，從而導致指令注入（Command Injection）。
此外，該工作流原本試圖透過檢查使用者名稱來過濾非法請求，但它錯誤地引用了 pull_request.user.login 屬性。由於觸發事件是 Issue 而非 Pull Request，該屬性在執行時會被 GitHub 視為空字串。這導致原本設計的安全性檢查完全失效，任何公開使用者提交的 Issue 都能觸發該工作流。
攻擊路徑與影響
Wiz 的研究團隊利用其 Red Agent 系統進行授權測試，成功驗證了此漏洞。攻擊者首先發送一個初步的 Payload（攻擊載荷）來測試環境，在修正語法錯誤後，成功從 GitHub Actions 的執行器（Runner）獲得回調。
這次攻擊最嚴重的影響在於憑證外洩。由於該工作流需要與 Jira 溝通，因此在環境變數中儲存了 JIRA_BASE_URL、JIRA_USER_EMAIL 以及最關鍵的 JIRA_API_TOKEN。攻擊者一旦成功執行指令，就能直接讀取這些機密資訊。
在本次事件中，外洩的 Token 屬於 Snowflake 的 QA 帳號，該帳號擁有對 Snowflake 內部 Jira 專案的讀取權限，涵蓋範圍包括工程開發、安全合規以及 Bug Bounty（漏洞獎金計畫）的追蹤記錄。這意味著攻擊者可能獲知公司內部的已知漏洞清單與安全修補進度，對企業安全構成潛在威脅。
修補方式與技術反思
Snowflake 在接獲通報後迅速採取行動，於 2026 年 6 月 23 日合併了修復程式。修復的核心在於改變處理不可信數據的方式：不再將 GitHub 表達式直接擴展到 shell 指令中，而是將其賦值給環境變數，再將這些變數作為參數傳遞給 jq（一個輕量級且靈活的命令行 JSON 處理器）。透過這種方式，輸入內容會被視為純資料而非可執行的程式碼，徹底杜絕了注入風險。
值得關注的是，Wiz 指出這次漏洞可能與 AI 輔助編碼工具 GitHub Copilot Autofix 的修改有關。雖然提交紀錄顯示 Copilot 參與了相關的合併請求，但無法明確判定漏洞程式碼是由 AI 直接生成的。這提醒了開發者，即使使用 AI 進行程式碼重構或自動修復，仍必須經過嚴格的人工審查，因為 AI 可能在優化結構的同時，忽略了關鍵的安全邊界。
實務限制與總結
根據 Snowflake 的調查，該漏洞在預設分支上暴露了約五天時間，但官方聲明表示並未發現未經授權的外部訪問跡象，且相關的 Jira Token 已在發現後立即輪替。
此事件再次強調了 CI/CD 安全的重要性。GitHub 早在 2025 年就曾發布文件警告，禁止在 run 區塊中直接擴展不可信的 Issue 數據，並強烈建議使用中間環境變數。對於所有使用 GitHub Actions 的團隊而言，應將外部輸入視為不可信，避免直接將其傳遞給 shell，以防止自動化流程淪為攻擊者的跳板。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。