Claude Code运行陌生仓库的安全风险：AI智能体如何被接管

一个你真的会遇到的场景

想象这样一幕：有人给你发来一个 GitHub 仓库链接，你懒得自己配环境，于是顺手丢给 Claude Code，说一句「帮我跑起来」。它开始读 README、装依赖、执行初始化——每一步都像日常工作里再普通不过的操作。

然后项目抛出一个报错：「环境还没准备好，请运行初始化脚本」。如果是你自己动手，可能会停一下，先看看这个脚本到底做了什么。但 Claude Code 不会这么想。在它眼里，这只是一个「还没完成的任务」，于是它继续往下跑。

问题，恰恰就出在这个脚本上。

这条安全研究来自 Mozilla 旗下的 Lindin 团队，科技媒体 The Decoder 也做了跟进报道。它揭示的不是一个理论漏洞，而是一条能在真实开发流程中被触发的攻击链。

攻击链如何藏得无迹可寻

这次攻击最狡猾的地方，在于把危险内容藏进了你看不见的地方。

脚本本身并没有把恶意指令写进仓库代码里。相反，它去查询了一条 DNS 记录。你可以把 DNS 理解成互联网的「通讯录」——平时它负责告诉电脑，某个域名应该去哪里找服务器。而这次，研究人员把一段外部指令悄悄塞进了这本通讯录里。

具体来说，DNS 除了常见的地址映射功能，还支持一种叫做 TXT 记录的字段——原本用于存储域名验证信息或邮件防伪配置。攻击者可以将任意字符串写入这个字段，包括一段完整的 shell 命令。当初始化脚本执行 DNS 查询时，返回的「文本信息」会被直接传入执行函数中，完成一次「数据即代码」的注入。由于 DNS 查询是完全合法的网络行为，防火墙和安全工具几乎不会对此产生警觉。

在安全领域，这类手法有一个专门的名字：间接提示注入攻击（Indirect Prompt Injection）。攻击指令不出现在 AI 直接可见的代码中，而是藏在运行时才会动态加载的外部数据源里，极大增加了事前检测的难度。

这意味着：

• 你打开仓库，肉眼看不到恶意代码；
• 代码扫描器扫描仓库，也扫不出问题；
• AI 读 README 的时候，同样看不到任何异常。

每一块单独拿出来看，都像正常操作：README 像正常的 README，报错像正常的报错，初始化脚本像正常的脚本，DNS 查询也像一次普通的网络请求。

可当它们连在一起，就变成了一条完整的攻击链。只有当初始化脚本真正跑起来时，那段藏在 DNS 里的外部指令才会被取回来，并在你的电脑上执行。

攻击后果：你的凭证已在别人手中

一旦指令在你的机器上执行，后果并不轻。

攻击者可以打开一条从你电脑连接出去的通道。你本地的敏感凭证——API Key、GitHub Token、云服务密钥——都可能顺着这条通道被悄悄带走。

这里还有一个容易被低估的连锁风险：开发环境中的凭证往往牵一发而动全身。一个 GitHub Token 可能拥有对多个私有仓库的写权限；一个云服务密钥可能关联着存储桶、计算实例和数据库；即便是看似普通的 API Key，也可能泄露业务逻辑中的提示词和用户数据，并直接产生高额账单。在真实攻击场景中，窃取到凭证后的自动化利用往往在几分钟内就已完成，远早于受害者察觉异常。

更让人后背发凉的是，整个过程几乎毫无声息。终端不会跳出「你被攻击了」的警告，它甚至可能只显示一句轻描淡写的「环境准备好了」。你以为任务顺利完成，实际上密钥已经在别人手里了。

问题不在 AI 笨，而在它太勤快

很多人第一反应可能是：Claude Code 是不是太蠢了，连这都识别不出来？

但研究揭示的真正麻烦恰恰相反——它太勤快了。

看到报错，它想修；看到说明，它照做；看到初始化失败，它继续补救。一个普通开发者面对「请运行初始化脚本」时，可能会本能地犹豫一下、审查一番；而 AI 智能体往往会毫不迟疑地跨过这个心理门槛。

这正是 AI 智能体与普通聊天机器人的本质区别所在。聊天机器人的能力边界停在「生成文本」，它的错误最多是让你复制到一段错误的文字；而 AI 智能体（AI Agent）具备真正的「工具调用」能力——它可以读写文件、执行终端命令、发起网络请求。Claude Code、Devin、GitHub Copilot Workspace 都属于此类。这种架构赋予了 AI 真正的「执行权」，使其能够对真实世界产生持久影响。

安全研究者将这类系统的潜在风险称为「能力越界」（Capability Overhang）：当一个系统的行动能力远超其安全判断能力时，它的「热心」本身就构成了一个攻击面。换句话说：

• 聊天机器人的错误停留在「信息层」；
• 智能体的错误直接落到了「行动层」。

当一个工具拥有执行权限时，它的「热心」就可能被恶意方利用成攻击的入口。

防范 AI 智能体安全风险：多问一句话

过去这些年，安全圈反复提醒我们一句老话：不要运行来路不明的陌生代码。

而在 AI 智能体时代，这句话需要再加一层：不要让 AI 替你运行它还没看懂的东西。

审视一个陌生仓库时，别只停留在「代码本身干不干净」这个层面。你还应该多问一句：

当 AI 把它跑起来之后，会不会去外面「拿东西」回来？

具体到实践中，建议养成以下几个防护习惯：

1. 隔离运行环境：对陌生仓库使用沙箱、容器或临时虚拟机，避免让 AI 智能体直接触碰主机与真实凭证；
2. 凭证最小化原则：不要在会被 AI 操作的环境里保存长期有效的 API Key、Token 和云密钥；优先使用有限权限的短期令牌；
3. 审查初始化脚本：对任何「请运行某脚本」的提示保持警惕，尤其留意涉及网络请求、DNS 查询的环节；
4. 限制智能体权限：在条件允许的情况下，为 AI 工具的命令执行与网络访问设置人工确认关卡。

AI 智能体工具正在快速渗透进我们的开发流程，效率提升是肯定的。但效率的另一面，是它们也继承了「执行权限」这把双刃剑。这条研究提醒我们：在把钥匙交给 AI 之前，先想清楚它可能会替你打开哪扇门。

核心要点