Snowflake 的 Jira 權杖：一個由 Copilot 共同簽署、而 GitHub 稱是人類撰寫的瑕疵

2026 年 6 月 23 日，由 Wiz 打造的自主安全代理 Red Agent 在 Snowflake 所擁有的公開 GitHub 儲存庫上開了一個 issue，並取得一組憑證。出問題的工作流程 .github/workflows/jira_issue.yml 位於儲存庫 snowflakedb/snowflake-connector-net，其用途是在任何人開啟 issue 時建立 Jira 工單——它將工單標題直接建入 shell 命令，而非透過環境變數傳遞，因此精心構造的標題在 GitHub Actions runner 上被當作程式碼執行。Red Agent 取回的權杖以 qa@snowflake.net 身分向 snowflakecomputing.atlassian.net 驗證成功，並具備對 Snowflake 的 engineering、security-compliance 與 bug-bounty Jira 專案的讀取權限。該漏洞已存在五天。Wiz 於 2026 年 8 月 17 日發表完整分析。此事件在 Orca AI Incident Archive 中登錄為記錄 2026-08-17-snowflake-jira-zhao-dao-can，該檔案庫收錄完整記錄集及其信心等級與引用來源。

插值，以及那個從未執行的防護

此工作流程是由 GitHub 事件「issues: opened」觸發的。任何擁有 GitHub 帳號的人，只要在公開儲存庫上開啟一個 issue，就能觸發它——不需要邀請、不需要維護者角色、也不需要 fork。有漏洞的步驟會將 issue 標題讀入一個 shell 變數：TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)，並帶有兩個篩選器，原本是為了在字串組合之前跳脫雙引號和單引號。

問題出在執行順序，而不是跳脫。GitHub 會在 bash 開始解析之前，先把運算式的內容代入腳本文字中，因此問題標題中的一個單引號就會關閉 echo 所保持開啟的引號字串。那兩個 sed 篩選器是在同一個腳本內、於替換之後才執行，無法修復已經改變該行解析方式的引號問題。Wiz 的文章明確指出，這種跳脫來得太晚，無法阻止突破；而一個精心構造、帶有收尾引號與分號的標題，會把攻擊者選擇的命令附加到 run 步驟中。

第二道控制措施本應縮小受眾範圍，卻沒有做到。該作業包含一個 if 條件，將 github.event.pull_request.user.login 與 whitesource-for-github-com 機器人的登入名稱進行比較，顯然是為了阻止自動化依賴項拉取請求提交工單。在 issues 事件中，根本沒有 pull request 物件，因此比較的對象是一個 null 屬性。GitHub 官方文件（由 The Hacker News 引述）指出，對不存在的屬性進行解引用會評估為空字串；Wiz 的分析則透過 null 值得出相同結果。無論哪種情況，該條件對每個使用者都評估為 true，而針對該機器人的例外則變成了對網際網路的通行通道。

這起注入之所以值得通報、而非被視為例行問題，關鍵在於它周遭還伴隨著什麼。同一個步驟把 JIRA_BASE_URL、JIRA_USER_EMAIL 與 JIRA_API_TOKEN 當成環境變數一併載入，因此在執行器上任意執行命令時，伸手就能碰到憑證，而不是面對一片空白基底。並未查出任何 Snowflake Connector for .NET 發行版本受到影響：這項弱點存在於該儲存庫的 CI/CD 自動化流程中，而不在已發佈的連接器程式碼裡。

Red Agent 拿走了什麼，以及它聲稱丟棄了什麼

Wiz 對這起漏洞利用事件的敘述，正是讓此事有別於掃描器發現結果的關鍵所在。第一個酬載使用了井號字元，將 TITLE=$(...) 賦值中的右括號註解掉，結果產生 bash 語法錯誤，而非回呼。該代理程式讀取錯誤訊息後，改寫酬載，以分號和新的 echo 引號關閉 shell 區塊，隨後收到頻外呼叫。該酬載使用 curl 連線至 oast.me 的子網域，並附上三個憑證變數的 base64 編碼值，而回呼則來自 Azure IP 20.106.182.197，Wiz 將該位址歸因於一個 GitHub Actions runner。

它回傳的權杖是 qa@snowflake.net 的 Jira API 權杖，而 Wiz 將其影響範圍描述為讀取權限，涵蓋 Snowflake Atlassian 雲端執行個體上的工程、安全法遵與漏洞賞金追蹤專案。這正是該檔案所記錄的危害：並非在組建機器上執行程式碼達五天，而是一組能讀取工單佇列的憑證——那些佇列正是尚未修復的工程與安全漏洞被提交之處，且依 Wiz 的描述，其中還包含漏洞賞金追蹤器。

Wiz 表示，它已安全刪除在概念驗證期間所存取的一切。Snowflake 在給 CSO Online 的聲明中表示，該報告「已立即展開調查並完成修復」，且「我們的調查未發現任何未經授權存取的證據」；Wiz 的部落格補充說，Snowflake 檢視了這五天期間的稽核日誌，並未發現除了 Wiz 自家測試位址之外有任何第三方使用。Snowflake 並未公布那些日誌，因此「沒有其他行為者」的結論是基於其說法以及 Wiz 對此的摘要，而非兩個組織之外任何人所能閱讀的文件。

這行有漏洞的程式碼是誰寫的？

那個問題衍生出第二個、規模更大的報導。PR #1218 標題為「SNOW-2069227: Update jira workflows」，於 2026 年 6 月 18 日以 squash 方式合併為提交 4a1b8ce，而該 squash 提交將 Copilot Autofix powered by AI 列為共同作者之一。Wiz 最初的標題正是緊扣這一點，將該缺陷描述為位於一個由 GitHub Copilot 協助的 pull request 中，而早期業界報導也遵循同一論調——SC Media 的標題寫道「Wiz agent finds Snowflake repo flaw in code co-authored by GitHub Copilot Autofix」。

GitHub 的立場（由 The Next Web 報導，並在雲端安全聯盟的一份研究備註中概述）是：其內部審查發現「這些導致該漏洞的貢獻是人類撰寫的」，而 Copilot Autofix「既未審查、也未參與其中」。這項反駁的技術依據在於 git 歷史。擠壓合併（squash-merge）會將一個 pull request 壓縮成單一提交，並把每一行共同作者署名一併帶入，不論該作者實際碰觸了哪些行；因此一行共同作者署名記錄的是參與了該 pull request，而非對某個特定 hunk 的作者身分。在同一個 pull request 中，Copilot 共同署名的提交 6d0e2fa 所更動的是 jira_close.yml——那是與有漏洞的 jira_issue.yml 不同的工作流程。不安全的插值被歸因於提交 094038e，日期為 2025 年 8 月 25 日，GitHub 將其歸屬於一位 Snowflake 工程師 sfc-gh-hpathak；PR #1218 則在 2026 年 6 月將該模式放上了預設分支。

Wiz 並未撤回該項發現，且在發布當天改變了論述框架。其部落格於 8 月 17 日 19:57 UTC 發布更新，將 Copilot 描述為「一位檢查了已合併 PR 與程式碼變更的共同作者」，它「認定一切無虞」，卻未注意到這些漏洞，並承認「目前不清楚該程式碼變更是否有 AI 協助」。在那份說法中，AI 的失誤屬於審查環節，而非作者身分：已合併的提取請求帶有 Copilot 共同簽署，而注入攻擊仍未被攔下。CSO Online 引述 Wiz CTO Ami Luttwak 表示，要在人類與 AI 之間建立清楚的歸屬「正變得有點困難」，而且「只看 PR 的共同作者並不夠」。

兩方說法共同的部分，值得與他們爭執的部分分開來看。雙方都同意該 squash commit 帶有 Copilot Autofix 的共同作者尾註，且該工作流程可被利用。雙方也都不爭執 GitHub Advanced Security 掃描了 pull request 的最終修訂版本、擷取了 jira_issue.yml，卻未標記該注入問題——Wiz 將其報導為漏報，而 GitHub 的反駁針對的是作者身分，而非掃描本身。仍未解決的是，Copilot 究竟有沒有審查過那些有漏洞的程式行：Wiz 表示有一次審查執行並讓它們通過，GitHub 表示該工具並未涉及這些行，而足以定案的日誌掌握在兩家公司之一手中。紀錄同時記載雙方說法，而非從中選擇。

五天，以及之後改變了什麼

報告送達後，修復動作很快。Wiz 於 6 月 23 日透過 Snowflake 的 HackerOne 專案提交編號 #3819931 的報告，並在同日以 Slack 通知 Snowflake 的安全團隊；Snowflake 合併了 PR #1402（commit 1dc7766），該變更以傳遞給 jq 作為參數的環境變數，取代了直接的表達式展開。Wiz 的時間軸將 Jira 權杖的輪換記為 6 月 24 日，The Hacker News 的報導也呈現同樣的分裂。相較之下，Wiz 自家的引言卻稱 Snowflake 已修復該漏洞，並「在同一天」輪換了該憑證——這是主要來源內部的矛盾，紀錄不應加以掩蓋。修補於 6 月 23 日上線；輪換在 Wiz 的表格中則記為 6 月 24 日。

這起披露案的時程由 Snowflake 主導：Wiz 將公開披露期限定為 2026 年 7 月 25 日，也就是依該計畫政策於 6 月 25 日完成處理後的三十天，並於 8 月 17 日發布分析。Snowflake 對 CSO Online 的聲明表示，該公司「感謝 Wiz 負責任的通報」，並正與 Wiz 合作，向業界分享這些經驗教訓。無論是 Wiz 的分析，還是 The Hacker News 的報導，皆未包含 CVE 識別碼、CVSS 評分，或列於 CISA 已知遭利用目錄中的紀錄；該缺陷是公開儲存庫中的工作流程設定，而非已發行的程式庫，因此它從未以常規方式進入漏洞資料庫。

該紀錄確立了什麼，以及未確立什麼

該檔案庫將其歸類為研究成果，而非部署事件，嚴重程度為高，信心等級為 A，確認涉及 AI 且有實際危害紀錄；其日期為 2026 年 8 月 17 日，即 Wiz 發布當日，而事件本身橫跨 6 月 18 日至 23 日。已確立的核心範圍狹窄且可查證：一個公開工作流程將攻擊者控制的文字插值進 shell 指令，其防護條件所比對的屬性在該事件中為 null，同一步驟中存有 Jira token，一個自主代理利用了此點，而 Snowflake 在一天內合併了修補並輪換了憑證。

屬於推論而非記載的部分，正是隨意轉述往往會抹平的部分。Copilot Autofix 被記載為該 pull request 的共同作者，並未被記載為有漏洞程式碼行的作者；最初新聞週期所採用的「AI 對 AI」框架，已被報導機構在數小時內部分撤回，並遭 GitHub 駁斥。已合併 pull request 的 AI 審查是否檢視過 jira_issue.yml，仍是一個未定論的事實問題，而非已有定論。而存取權限的範圍，儘管 Wiz 有詳細描述，仍未經獨立稽核：目前沒有任何 Jira 權限、工作流程執行或稽核紀錄被公開。

這個修正模式正是 GitHub 自家指引自 2025 年 7 月起所建議的做法——把不受信任的 issue 資料傳入環境變數，再以引數方式交給 jq，而不是在 run 區塊內展開它。Snowflake 合併的提交正是這麼做，而修正後的處理仍留在預設分支上。對任何把這份紀錄當成先例來看的人而言，可長可久的結論在於歸屬而非注入：當一個 pull request 牽涉數個人類與數個代理程式時，共同作者 trailer 無法告訴你某一行是誰寫的，而 Wiz 與 GitHub 最後也都用不同的說法表達了這一點。