2026 年 8 月 18 日，Wiz Research 公開了一項令人警醒的安全研究結果：其自主 AI 安全代理 「Red Agent」 在 Snowflake 的公開 GitHub 倉庫中發現了一個由 GitHub Copilot Autofix 引入的指令注入漏洞，並利用該漏洞成功入侵 Snowflake 的內部 Jira 系統——全程無需人類干預。
此事件揭示了 AI 輔助軟體開發中一個深層次的安全困境：AI 生成程式碼引入的漏洞，可以被另一個 AI 安全代理以機器速度自主發現並利用。
事件概要
6 月 18 日，Snowflake 的公開倉庫 snowflakedb/snowflake-connector-net 合併了一個 Pull Request（PR #1218），該 PR 的 squash commit 的合著者為 「Copilot Autofix powered by AI」。此 PR 修改了 Jira 問題觸發的 GitHub Actions 工作流程，實際上移除了原有的安全模式——原本透過 env: 變數傳遞 + jq 解析 JSON 的防護設計，被替換為直接在 run 腳本中插值 ${{ github.event.issue.title }}。
五天後的 6 月 23 日，Wiz Red Agent 自主掃描到這一變更，發現其存在指令注入漏洞：任何 GitHub 使用者都能透過建立一個 Issue，在標題中嵌入惡意命令，進而在 GitHub Actions runner 上執行任意程式碼。
技術深度分析
漏洞原理
該工作流程在 issues: opened 事件上觸發——這意味著任何 GitHub 帳號都可以觸發它。關鍵程式碼如下：
run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\\'/g")問題在於 sed 的跳脫操作發生在 GitHub 模板擴展之後，因此 Issue 標題中的單引號可以直接突破 echo '...' 的上下文，實現任意命令執行。
所謂的「安全閘門」形同虛設
工作流程中的 if: 條件看似具有防護作用：
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')然而在 issues 事件中，github.event.pull_request 始終為 null。條件簡化為 null != '...' ——永遠為真。所有 GitHub 使用者均可繞過。
Red Agent 的自主適應能力
在初始滲透嘗試中，Red Agent 使用了註釋字符 # 來註釋掉行末內容，但這意外也吃掉了 TITLE=$(...) 的閉合括號，導致 bash 語法錯誤。Red Agent 沒有停止或失敗，而是：
- 檢測到錯誤
- 調整 payload 為
; echo '以正確閉合 shell 語法 - 重新發送請求
幾秒鐘後，遠端監聽伺服器就收到了來自 GitHub Actions runner 的回呼，其中包含 base64 編碼的 Jira 憑證。
影響範圍
被竊取的令牌以 qa@snowflake.net 身分认证到 snowflakecomputing.atlassian.net，授予了對 Snowflake 的工程、安全合規及漏洞獎勵追蹤專案的讀取權限。
修復與回應
- 6 月 23 日：Wiz 負責任揭露漏洞後，Snowflake 於同日完成修復
- 受影響的憑證被立即輪換
- 詳細日誌稽核確認 Wiz 是曝光期間的唯一行為者
- Wiz 確認所有用於概念驗證測試的數據已被安全刪除
核心教訓
- AI 輔助開發缺乏歷史上下文：Copilot Autofix 的自動 PR 移除了先前為了防範注入而設計的
env: + jq安全模式，因為 AI 不理解「為何如此設計」 - AI 安全審查的盲點：GitHub 的 AI 輔助安全審查未能標記這個嚴重的注入漏洞
- AI 安全代理的雙面刃：Wiz Red Agent 成功展示了 AI 代理可以以機器速度發現、適應並利用漏洞——速度與規模已超越人類安全團隊的能力範圍
Wiz 研究團隊最後強調，安全團隊必須實施防護欄（Guardrails），阻止 AI 代理將結構化數據解析器替換為直接的字符串插值——這正是本次事件中 Copilot Autofix 所做的那樣。
本文信息來源：Wiz Research Blog（Gal Nagli），2026 年 8 月 18 日發布。