你的AI编程助手，可能被网页里的一行字"策反"

上篇文章结尾我预告过一件事：你用的 AI 编程助手，可能被一句话劫持。今天，它来了——而且比"劫持"更狠：在没人盯着的时候，它可能替你执行一条删数据的命令。

凌晨三点，CI 流水线正无人值守地跑着。AI 编码助手拉下一个刚更新的仓库，开始自主读 README、翻 issue——这些都是"干活前的功课"。它不知道的是，仓库里某一行不起眼的文本，正等着它读进去……

这不是科幻片。这是本周刚公开的一个真实漏洞，主角是 Continue CLI——一个 35.6k star 的开源 AI 编程助手。

─ ❖ ─

AI 编程助手是怎么"干活"的

Continue 是开源 AI 编程助手里的头部玩家：在 VS Code 里能当插件用，命令行里也有 CLI。它能读代码、改文件、甚至帮你执行终端命令——就像给 AI 配了一双手。

既然是"手"，就得有个闸门：它内置了一道安全检测，在放行命令前先判断"这条命令危不危险"。

问题就出在这道闸门上。

一份不完整的"黑名单"

这道闸门用的思路，安全圈叫"黑名单"（denylist）：把危险的东西列个清单，碰到的就拦下来。听起来合理，但凡是用黑名单当唯一防线的，迟早翻车——这次的翻车姿势特别典型：

危险路径黑名单只匹配 `/`、`/*`、`~`、`/usr`、`/etc`、`/bin`、`/sbin` 这些字面前缀。可删库套餐里最常见的 `/home`、`/root`、`/var`、`/opt`、`/srv`，一个都没进名单；

更妙的是 `$HOME`：命令行用 shell-quote 解析，`$HOME` 在解析器眼里是"空 token"——检测时看起来像空参数，直接放行；可真正执行时，shell 会把 `$HOME` 展开成你的家目录。检测时是空字符串，执行时是你家目录——一道闸门，两种解读；

还有 `find -delete` 只被判"高风险"、不拦；`shred`、`wipefs`、`truncate`、`pkexec` 这些同样危险的工具，压根没进名单。

一句话：这条黑名单，更像一张"已认识的坏人照片集"，而不是一堵墙。

更关键的是：谁在替你按回车？

如果只是手动模式，顶多是"AI 建议了危险命令、你没注意点了同意"。真正的风险在无人值守模式：

Continue CLI 的 headless（`cn -p`）和 auto 模式下，Bash 工具是默认放行的。AI 智能体自己读网页、读陌生仓库的文件、读 issue 讨论——这些内容全都不可信。只要里面藏一句精心构造的"指令"（提示词注入），智能体就会把它当成用户需求照做，在没人看着的时候执行破坏性命令。

"内容即攻击面"——你喂给 AI 的任何文本，都可能成为攻击入口。这不是 Continue 一家的问题，是当下所有 AI 智能体共同的软肋。

─ ❖ ─

这类漏洞该怎么防？

先把这条补上：截至 2026-08-27，Continue 官方还没有发布修复版本（漏洞 6 月 13 日上报，issue#13001至今仍 open）。所以别等补丁，先自查：

1. 你用的 AI 工具链里，Bash/文件类工具是默认放行还是默认拒绝？默认拒绝才是对的。
2. 无人值守模式（headless/auto/CI）下，AI 会不会接触不可信内容——网页、issue、陌生仓库？
3. 工具文档里宣称的"安全限制"，真的生效吗？建议拿自己的环境做一次白盒实验验证。

从工程视角说，"默认拒绝 + 白名单"（deny-by-default）才是正解：不在名单里的命令一律不执行，宁可让 AI 多问一句，也别让它闷头删数据。路径归一化、变量展开、命令别名，这些都是黑名单永远追不完的天敌——追不完，就别追了，换思路。

─ ❖ ─

你给 AI 编程助手开过哪些"默认放行"？评论区聊聊，也许能帮别人躲过一个坑。

下期预告：给 AI 喂知识库用的 Sitemap，可能是打进你内网的钥匙。

本文基于公开漏洞信息+AI辅助创作，人工审校。数据源：NVD、Vulncheck、GitHub issue#13001（https://github.com/continuedev/continue/issues/13001），扫描时间 2026-08-27。