Wiz Research构建的一款自主AI安全Agent展示了这样一种风险：一行看似不起眼的Shell代码，如何迅速演变为一次完整的凭据泄露。
这款名为Wiz Red Agent的工具自主发现、利用并验证了Snowflake公共仓库snowflake-connector-net中一个严重的GitHub Actions注入漏洞，最终在全程没有任何人工操控的情况下获得了Snowflake内部Jira实例的读取权限。
该漏洞位于名为jira_issue.yml的工作流文件中，这个工作流原本用于在有人创建GitHub Issue时，自动生成对应的Jira工单。
漏洞的根源可追溯到2026年6月18日合并的拉取请求#1218。此次修改将原本通过环境变量和jq进行解析的安全处理方式，改成了直接把不受信任的Issue标题插入Shell脚本中，由此埋下了命令注入风险。
Part01
AI Agent入侵工作流
由于GitHub会先展开模板内容，再进行Shell转义，只需要在Issue标题中插入一个单引号，就可能突破原有脚本限制，进一步注入任意命令。更严重的是，工作流中原本用于限制访问权限的条件判断，在Issue打开事件中始终会被判定为true。这意味着，理论上任何GitHub用户都可以触发这一漏洞。
值得注意的是，GitHub Advanced Security扫描了包含漏洞代码的确切版本，却未能标记出问题。
同一拉取请求中，还有一处由Copilot辅助完成的修改，涉及另一个文件jira_close.yml。不过，Wiz后来澄清，Copilot记录的贡献仅限于这个单独文件，与jira_issue.yml中的漏洞代码并无直接关系。即便如此，在对合并后的PR进行审查时，这一严重缺陷仍然没有被发现。
Part02
自主攻击链：从发现到利用
Red Agent在漏洞上线仅五天后（2026年6月23日）就发现了这个弱点。它构造了一个恶意的issue标题，使用base64编码的带外回调从GitHub Actions runner中窃取Jira凭据。
第一次payload尝试因使用了注释字符而破坏了shell语法，该Agent自主诊断了bash错误，并重写payload以正确闭合脚本，最终在第二次尝试时成功。
几秒钟内，Wiz的监听器便收到了来自Azure托管runner的回调，其中包含base64编码的Jira API令牌，该令牌关联到服务账户qa@snowflake.net。
该令牌成功通过了Snowflake的Atlassian实例的身份验证，使其能够查看工程、安全合规以及漏洞赏金追踪等项目。对于一个配置错误的CI工作流而言，这堪称相当严重的爆炸半径。
Part03
响应与安全启示
Snowflake在通过HackerOne收到漏洞报告当天即作出回应，修补了工作流，轮换了暴露的Jira令牌，并通过审计日志确认在暴露窗口期内只有Wiz的测试流量。PoC测试期间访问的所有数据均已被删除。
该事件凸显了软件安全领域日益增长的担忧：AI辅助编码既能捕捉不安全模式，也能同样轻易地重新引入这些模式，而现有静态分析工具可能跟不上这种节奏。
这也标志着威胁格局本身的转变：自主AI Agent可以将从发现到利用的时间线从数周压缩到数小时。
对于安全团队而言，这也意味着CI/CD流水线的安全要求需要同步提高。一方面，应明确强制执行更安全的编码模式，避免将不可信输入直接插入Shell脚本；另一方面，应尽量采用短时有效凭据，降低凭据泄露后的影响范围。
与此同时，AI生成或辅助修改的代码也需要接受严格审查。随着攻防双方的自动化程度不断提高，安全审查的速度和质量也必须同步跟上，而不能继续落后于代码生成和漏洞利用的节奏。
参考来源：
AI Agent Hacks Snowflake GitHub Workflow and Reaches Internal Jira
https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/
