一个改写把安全写法换成了字符串拼接
出问题的是仓库里的 .github/workflows/jira_issue.yml。原来的写法把 issue 标题先存进环境变量，再用 jq 组装 JSON——这是 GitHub 自己推荐的安全模式。改写后变成把标题直接插进 shell 的 echo 命令里，靠 sed 转义。问题出在顺序：GitHub 的模板展开发生在前，sed 转义发生在后，标题里的一个单引号就能先一步跳出引号串。另有一处判断条件读的是 pull_request.user.login，而 issue 事件里 pull_request 为 null，这个本该拦人的门在 issue 场景下恒为真，未认证用户就此畅通。 Wiz 拿到的是 runner 的带外回连、Jira base URL 和一枚属于 qa@snowflake.net 的 Jira API token，可读工程、安全合规与漏洞赏金三类项目。时间线很短：6 月 18 日 PR #1218 合入引入，6 月 23 日 Red Agent 通过 HackerOne 上报（报告号 #3819931），Snowflake 当天以 PR #1402 修复。Snowflake 表示未发现被未授权访问的证据；该问题未分配 CVE，且只存在于仓库自动化里，没有随任何 connector 版本发出。
谁放行的，双方说法对不上
这是需要区分表述的部分。Wiz 最初的说法是 GitHub Advanced Security 的 Copilot Autofix 扫过最终版 PR 却没报出注入，8 月 17 日更新为：Copilot 作为 co-author 检查了合并后的 PR 与代码改动并判定「全部通过」，同时承认无法确定这段改动本身是否由 AI 辅助写成。GitHub 的回应是明确否认——写出这段代码的是人，Copilot Autofix 既没有参与也没有审查过它。 可查的痕迹支持 GitHub 一侧的时间线：那段不安全的改写出现在 2025 年 8 月 25 日一位 Snowflake 工程师的提交里，Copilot 的 co-author 署名来自 6 月 18 日 squash 合并时的行尾 trailer——co-author 能证明它出现在 PR #1218 里，证明不了它写了这几行。能一锤定音的扫描日志只有 GitHub 手里有，目前未公开。在此之前，「Copilot Autofix 放行了漏洞」这个说法应视为未证实。
对写 CI 的人
真正可迁移的一条是：GitHub 2025 年 7 月就发过这类工作流注入的指引，明确要求不要把不可信的 issue 数据直接展开进 run 块，而要过一层环境变量——引入问题的提交比这份指引晚了一个月。把 issue 标题、PR 标题、分支名当成攻击者可控输入来审，比追问哪段代码是不是 AI 写的更有用。
via: Wiz Red Agent 技术博客、The Hacker News、The Next Web（GitHub 回应）、Infosecurity Magazine