AI编程工具存在TOCTOU高危漏洞，可窃取CI密钥

一个 GitHub issue 现在可能已经可以渗透出你的 CI 密钥，而导致这一问题的工具正是你的团队用来"提效"的那个。这件事值得关注，值得比现在更多的讨论。

这不是什么新的数学问题，只是老漏洞披上了新马甲。Time-of-check-to-time-of-use（检查时到使用时的竞态条件）这类缺陷早在多用户 Unix 系统出现文件权限竞态条件时就已存在。新的是攻击面：编程 Agent 读取 GitHub issue、.env 文件或 AGENTS.md 配置文件作为"上下文"，在一次处理中判定该上下文安全，然后在后续处理中用完整权限对其操作。把"文件描述符"换成"LLM prompt"，你得到的本质上就是当年教授警告过你的同一个漏洞——只不过现在它有了一个 CVE 编号和一个营销问题。

三家厂商，三种实现，同样的架构缺陷。这才是值得深思的部分。当 Claude Code、Gemini CLI 和 OpenAI Codex 都在 harness 层面存在验证缺口时，这不是巧合，这是趋同进化。每个构建这些 Agent harness 的人都在用同样的捷径（一次验证、永久信任）解决同样的问题（让模型在外部输入上自主行动）。

这里被过度强调的："目前没有已确认的野外利用"这句话会被一些人读作"所以没问题"。但问题依然存在，只是意味着还没人公开炫耀，或者还没人注意到。在带有密钥的 CI 基础设施上运行的工具中出现 CVSS 10.0 级别的漏洞，是这类漏洞能造成的最坏场景之一。没有已确认的泄露并不能证明安全，只能说明这次研究人员先到了一步。

这里被低估的：信任边界问题不是打一个补丁就能解决的。GitHub issue 标题、.env 文件、Agent 读取以获取"指令"的配置文件——这些都是天然不可信的输入，然而这些工具的全部卖点就是"让 Agent 读取你的代码库然后自己处理"。每一个摄入点都是潜在的注入向量。打掉这个具体的 CVE 并不能封堵这一整类漏洞，它只是关上了这座建有很多门的房子里的一扇门。

谁从当前的叙事中获益？说实话，厂商们在这里有一个相当干净的叙事：发现、修复、继续、没有事故。这是标准的"负责任的披露起了作用"的弧线，公平地说，这次确实起了作用。但它同时也悄悄地把一个根本性的架构问题（跨特权边界做验证后信任）重新定义为一个已被"修复"的偶发漏洞，而真正的教训是：这种 harness 设计模式本身需要受到审视——每个在做这件事的 Agent 产品都应如此。

如果你把这些工具接入了 CI，这是给你的提醒："AI 编程助手"和"可以访问你密钥的流程"现在是同一句话。把 Agent 的操作面当作第三方 GitHub Action 来对待：最小权限、范围限定的 Token、不要因为方便就给予整个仓库或写全部范围的权限。如果你的 Agent 不需要读取 .env 文件就能完成工作，那它就不应该有读取它的路径。

对于安全团队，有意义的动作不只是打补丁，而是向你的 AI 工具供应商提出一个尖锐的问题：你们的验证究竟发生在哪里，相对于模型获得行动权限的地点？"我们验证了输入"不是答案。"验证发生在与执行相同的信任边界内，在上下文摄入和工具调用之间没有重新检查"才是答案——如果一个供应商给不出这种程度的细节，这也是有价值的信息。

对于更广泛的行业：这种情况会持续发生，直到 Agent harness 变得无聊、被标准化、被约束起来——就像沙盒和权限模型当年在浏览器和移动操作系统上变得无聊一样。我们还处于早期。这件事在 HN 上零参与度实际上比 CVE 本身更能说明问题——很多人现在正把这些工具部署到生产流程中，却连想都没多想。

当你的 CI 流水线的任务是快速运行不受信的代码，而你的 AI Agent 的任务是读取不信任的输入并自主行动时，"Agentic"在什么时候不再是一个特性，而开始变成一个漏洞类别本身？

Claude Code 和 Gemini CLI 漏洞让 GitHub Issue 能触达 CI Workflow 密钥

要了解进一步的行动，你可以考虑屏蔽这个人或报告滥用。