編按：本文綜合整理自 Wiz 原始研究報告、The Register 獨立報導、Unite.AI 安全分析、dev.to 開發者硬化指南，並加入 Siami 編輯部觀點與分析。
AI 修補程式自己開了後門
2026 年 8 月 17 日，雲端安全公司 Wiz 揭露一項驚人的研究結果：旗下的「Red Agent」自主 AI 安全研究代理人在 Snowflake 公開的 GitHub 儲存庫中發現並實際利用了一個嚴重的 GitHub Actions 工作流漏洞，而這個漏洞本身竟是 5 天前由 GitHub Copilot Autofix 自動生成的「修補程式」所引入。
Wiz 指出，這個事件揭示軟體開發的新現實：在涉及 AI 編碼代理人的工作流中，關鍵漏洞仍可能被引入並通過審查；而自主運作的 AI 安全代理人能夠在真實環境中迅速發現並利用這些漏洞。
根據 Wiz 在 8 月 17 日公布的詳細報告，這個漏洞出現在 snowflakedb/snowflake-connector-net 儲存庫中。Wiz 透過 Snowflake 在 HackerOne 的漏洞揭露計畫進行研究，於 6 月 23 日完成責任通報。Snowflake 在當天完成漏洞修補、撤換受影響的憑證，並透過詳細的稽核日誌確認在曝險窗口期間 Wiz 是唯一存取該資料的行為者。Wiz 也確認在概念驗證測試期間存取的所有資料均已安全刪除。
Wiz 8 月 17 日的更新說明：這次事件中 Copilot 是在合併的 PR 中以共同作者身分檢查程式碼變更，並未注意到其中的關鍵漏洞；至於那段程式碼變更本身是否為 AI 輔助生成，目前仍未釐清。
漏洞技術細節
被引入的漏洞是一個腳本注入（script injection）問題，發生在 jira_issue.yml 工作流中。問題的根源在於 GitHub Actions 工作流接受 GitHub Issue 的標題作為參數，卻未經適當清理就將其嵌入 shell 指令中。
關鍵在於，這個漏洞於 2026 年 6 月 18 日上線，距離 Wiz 發現僅 5 天 — 引入漏洞的是 PR #1218 的合併提交。最終的 squash 提交將「Copilot Autofix powered by AI」標記為共同作者。這次合併的 PR 將儲存庫既有的安全輸入處理模式替換為直接字串展開，卻未觸發 GitHub AI 輔助的安全審查。
技術差異在於：原本的「安全」寫法是把 issue 標題放進環境變數，再用 jq 指令建構 JSON 承載；新引入的寫法則是在 shell 指令內直接展開 ${{ github.event.issue.title }}。AI 的「自動修補」實際上把注入攻擊的入口給寫了進去。
工作流雖然設有 if: 條件，乍看之下像是個保護閘：
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')但在 issue 事件中，github.event.pull_request 永遠是 null，因此這個條件化簡後變成 (null != 'whitesource-for-github-com[bot]') — 永遠為真，代表每個 GitHub 使用者都能通過這道閘門。
從漏洞到憑證外洩
Wiz Red Agent 設計了一個 issue 標題，經過 GitHub 模板展開後能從 echo 字串中脫逸，藉由外帶回呼（out-of-band callback）將 Jira 憑證外洩：
- 在外洩的過程中，Red Agent 最初嘗試使用井字號
#註解掉行尾的指令，但 runner 反而回傳 bash 語法錯誤，因為#也吃掉了TITLE=$(...)的右括號。 - 自主分析的 Red Agent 並未因此停下，而是調整 payload，改用
; echo '正確關閉 shell 區塊。 - 成功從 GitHub Actions runner（Azure IP 20.106.182.197）接收到包含 base64 編碼憑證的回呼。
外洩的 Jira 權杖以 [email protected] 身分通過 snowflakecomputing.atlassian.net 認證，獲得對 Snowflake 工程、安全合規與漏洞獎勵追蹤專案的讀取權限。
為什麼這件事重要
這不是一場失控的 AI 代理人攻擊，而是一次被授權的漏洞獵捕，但它的「自動化端到端」性質暴露了 AI 時代軟體安全的結構性問題。
1. 從「AI 修補」到「AI 注入」的因果翻轉
GitHub Copilot Autofix 的設計目的是「修補漏洞」，但它在這個案例中刪除了原本刻意設計的安全模式，把結構化資料解析器替換成直接字串插值。AI 編碼助理缺乏「為什麼當初這樣寫」的歷史脈絡，它根據機率模式預測程式碼，卻可能不自覺地引入已被棄用的不安全 shell 模式。這意味著我們不能假設 AI 修補等同安全修補 — 兩者必須接受同樣的靜態分析與安全審查。
2. 從「年度滲透測試」到「小時級自主探測」的時間軸壓縮
漏洞從 6 月 18 日上線到 6 月 23 日被自主 AI 代理發現，僅有 5 天。Wiz Red Agent 從掃描到完成 exploit 全程沒有人工介入，自主分析 bash 語法錯誤、調整 payload、接收回呼、評估爆炸半徑。Wiz 頭號研究員 Gal Nagli 在訪談中直言：「我以前希望晚上能找到一個漏洞。今天 AI 跟我說它已經攻破了那個組織。」
3. 從「供應鏈信任」到「代理人對代理人」的攻擊模型
傳統漏洞揭露的時間軸是「研究人員發現 → 通報 → 修補」，週期以月計。現在的時間軸是「一個 AI 寫入漏洞 → 另一個 AI 在幾小時內發現並利用 → 5 天內完成修補」。當攻擊方與防守方都是 AI 代理人時，唯一能拉開差距的是「閘門設計」：在合併前擋下不安全的 AI 生成變更、限制 runner 的權限與生命週期、把憑證生命週期縮短到比漏洞窗口更短。
數據解讀
5 天的曝險窗口、3 種角色（Copilot Autofix 寫漏洞、Wiz Red Agent 攻擊、Snowflake 同日修補）、2 種 AI 代理人交鋒 — 這是 2026 年 AI 資安新常態的具體數字。
關鍵指標：
- 漏洞存活期：5 天（6/18 上線 → 6/23 修補），相較於 Wiz 過往觀察的多數 CI/CD 漏洞生命週期（通常 30-90 天）短了一個量級。
- 修補速度：Snowflake 在收到 Wiz 通知「當天」完成修補（commit 1dc7766, PR #1402），並於隔日完成憑證輪替。
- 可重現性：漏洞觸發條件是「任何 GitHub 使用者開一個 issue」，零認證、零權限，理論上 Snowflake 整個公開儲存庫的所有工作流都暴露在攻擊面。
- AI 自動化層級：從 Red Agent 自動分析 bash 錯誤、調整 payload、執行外洩，整個攻擊鏈無人工介入。
- 未公開的爆炸半徑：Wiz 確認只有自己存取過
[email protected]的 Jira 帳號，但這把權杖能讀取「工程、安全合規、漏洞獎勵」三類敏感專案 — 在真實攻擊情境下可能延伸出更多供應鏈風險。
最值得警惕的數字是漏洞與發現之間的 5 天差距：在大多數企業的 CI/CD 中，這種攻擊從「發生」到「被注意到」往往要幾週甚至幾個月。Wiz 展示的自主探測能力將這個時間從「月」壓縮到「天」，把企業的修補速度逼到 AI 自動化的等級。
業界回應與修補建議
Snowflake 在聲明中感謝 Wiz 的負責通報與協作：
「Snowflake 感謝 Wiz 透過我們的漏洞揭露與漏洞獎勵計畫 HackerOne 對這些發現的負責回報與協作。Wiz Research 回報了我們其中一個公開 GitHub 儲存庫的安全漏洞。6 月 23 日收到揭露後，我們立即進行調查並完成修補，我們的調查未發現未授權存取的證據。保護我們的系統仍是首要任務，我們將持續致力於強化軟體開發與安全實務。」
dev.to 開發者社群根據這份報告提出 5 條 GitHub Actions 硬化規則：
- 規則 1：永遠不要把事件承載直接插值進
run:區塊。 - 規則 2：把
actionlint與zizmor設為必要檢查。 - 規則 3：AI 生成的 PR 必須接受與人類程式碼相同的靜態分析與安全審查。
- 規則 4：給 runner 剛好需要的權限，而且只給它需要的那段時間。
- 規則 5：把長效期的 CI/CD 憑證換成短效期、限定範圍的工作負載身分（Workload Identity）。
GitHub 官方文件指出，Copilot Autofix 透過 CodeQL 與 LLM 結合產生修補建議，並會「重新執行 CodeQL 驗證」修補是否真的解決了警示。問題在於：這個驗證流程只覆蓋 CodeQL 自身的查詢套件，對於自訂查詢與第三方工具產生的警示不保證品質，更無法捕捉「AI 修補移除現有安全模式」這類跨檔案、跨歷史脈絡的問題。
Wiz 頭號研究員 Gal Nagli 在 Calcalist 採訪中強調，這個事件代表資安研究的典範轉移：「以前我希望晚上能找到一個漏洞。今天 AI 直接跟我說它已經攻破了那個組織。」他領導的 Red Agent 團隊把過去需要數週的人工滲透測試，壓縮到數小時。
對台灣企業的啟示
台灣的金融業與科技製造業是 GitHub Copilot Autofix 與 AI 編碼工具的早期採用者。這個事件直接命中三個在地議題：
- CI/CD 安全成熟度落差：許多台灣企業的 CI/CD 仍依賴長效期 PAT 與過寬的
if:條件，事件中的「閘門永遠為真」是常見疏失。 - AI 修補的內部規範：絕大多數企業目前沒有明確的「AI 寫入變更需要第二人審查」政策，AI 修補被當作「已通過 CodeQL」自動放行。
- 供應鏈攻擊面：台灣半導體與硬體供應鏈高度依賴公開 GitHub 儲存庫與 CI/CD 工作流，這個事件提醒所有「任何 GitHub 使用者都能開 issue」的工作流都應被視為攻擊面。
簡單可行的第一步：把 actionlint 與 zizmor 設為必要合併檢查（required check），任何不通過的工作流變更都無法合併至 main 分支。這能在不增加人力的前提下，擋下這類腳本注入攻擊。
網友熱門留言 (5)