AI 自动修复竟帮黑客攻破 Snowflake

AI-Generated GitHub Copilot "Autofix" Allowed Compromise of Snowflake's Jira

▲ 76galnagli32 HN 评论区
AI 自动修复竟帮黑客攻破 Snowflake

Wiz 的 Red Agent 在 Snowflake 的公开仓库中发现了一个严重漏洞，根源竟是一次由 GitHub Copilot 生成的“自动修复”提交。这次 AI 操作意外移除了原有的安全输入过滤，导致攻击者只需创建一个特定标题的 GitHub issue，就能在 GitHub Actions 中执行任意命令并窃取 Jira 凭证。Wiz 在发现漏洞后迅速验证并上报，Snowflake 当天即完成修复并轮换凭证。这一事件警示我们，AI 生成的代码同样需要严格的安全审查，自动化助手可能因缺乏上下文而引入严重的安全回退。

AI 编程助手可能会无意中引入工作流注入漏洞，而自动化 AI 代理则能迅速在真实环境中发现这些问题。
阅读原文 →HN 评论区RSS

HN 评论区

32
  1. inahga

    我大概率也会犯同样的错误。写 GitHub Actions 时不使用静态分析工具，这简直太不负责任了。

    在 CI 中使用 zizmor：https://github.com/zizmorcore/zizmor

    error[template-injection]: 通过模板扩展导致的代码注入

    --> .github/workflows/jira_issue.yml:24:29

    |

    22 | run: |

    | --- 这个 run 块

    23 | # 转义标题和正文中的特殊字符

    24 | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\\'/g")

    | ^^^^^^^^^^^^^^^^^^^^^^^^ 可能会扩展为攻击者可控制的代码

    |

    = note: 审计置信度 → 高

    = note: 此问题包含自动修复方案

  2. mjr00

    看看漏洞引入时原本试图做什么，挺有意思的 [0]

    > 像 jira_close.yml 这样的工作流使用了已弃用的 atlassian JIRA 动作，并且依赖 gh-actions 仓库。这并不理想，也不必要地复杂。该 PR 更新了 jira_close 工作流，改为通过 curl 直接调用 API。同时也保留了自定义字段的使用。

    我不评论这个项目的管理方式及其优先级排序，但就我个人的经验而言，在 AI 出现之前，这类改动会被坚定地归类为“这是个小麻烦，把它放进技术债务 backlog，和另外 50000 个工单放在一起”，然后永远没人去动它。人工投入时间去理解如何修复问题、进行代码变更、测试并部署，其成本对于这种几乎毫无实际价值的改动来说太高了。

    现在有了 AI，这就变得像启动一个 agent 并告诉它做个改动那么简单；所花精力不过等同于最初写那个 backlog Jira 工单而已。

    这就好比开源社区正面临的低价值 PR 问题，公司们迟早要意识到，代码的审查和维护是有成本的，哪怕代码本身是近乎免费生成的，在公司内部流程中也是如此。仅仅因为一个 agent 能通过几行指令修复一个小麻烦的技术债务，并不代表它就应该这么做。

    [0] https://github.com/snowflakedb/snowflake-connector-net/pull/...

  3. procone

    YAML 简直是噩梦般的规范。

    在追求让标记语言“人类可读”的过程中，它制造了无数陷阱。

    说实话，我现在反而更喜欢 XML 了。

  4. vultour

    第一个链接的 PR (#1218) 只有一个由 Copilot 共同署名的提交，而且它与漏洞无关，PR 中的其他建议也无关。是我漏掉了什么吗？

  5. CodeWithLeo

    这里真正有趣的教训其实并不是

同日更多故事

2026-08-17