AI编程工具Serena旧版漏洞:打开项目可能执行代码

下载一个陌生项目，用Serena打开查看，还没开始让AI改代码，攻击者准备的内容就可能已经在本机执行。受影响的是serena-agent 1.6.1及以前版本，1.7.0已经修复。

风险入口藏在项目自己的.serena/project.yml里。这个文件看起来只是工具配置，却能引导Serena加载另一份模式文件，并把其中的文字交给模板引擎处理。

攻击在项目打开时触发

Serena允许项目添加自定义模式。配置中的added_modes可以指向仓库里的另一个YAML文件，里面的prompt会进入系统提示词。

旧版本使用普通Jinja2环境渲染这段文字。Jinja2原本用于把变量填进文本模板；没有沙箱限制时，特殊表达式可以沿着Python对象访问系统命令。

恶意仓库只需把表达式藏进模式文件。Serena加载项目、生成系统提示词时就会执行，甚至发生在它向大模型提供第一次请求之前。

项目使用了yaml.safe_load，它能阻止某些利用YAML反序列化执行代码的方式。但这里的恶意内容在YAML看来只是一段普通字符串。

真正的执行发生在下一步：字符串被交给未沙箱化的模板引擎。只检查文件有没有被安全解析，无法覆盖后续组件怎样使用解析结果。

Serena也有受信项目路径设置，用来限制打开项目时运行命令。研究人员把受信列表设为空后，模板路径仍然能够执行，因为自定义模式的加载没有经过同一项信任检查。

Serena在开发者自己的账户下运行。攻击代码因此可以接触这个账户能读取的内容，包括SSH密钥、云服务凭证、.env文件、浏览器会话和内部网络。

这类后果比让模型回答错误更直接。项目仓库从待分析数据变成了本机程序入口，而开发者平时又经常打开陌生开源库、贡献者分支和复现Bug的项目。

风险也不限于Serena。任何会读取项目配置、渲染模板或自动运行初始化命令的AI编程工具，都要检查配置是否被当成不可信输入。

正在使用Serena时，先确认版本达到1.7.0。旧版本不要打开来源不明的仓库，也不要只依赖受信路径设置。修复版把模板环境换成SandboxedEnvironment，关闭了这条注入路径。

构建同类工具时，项目提供的路径和模板都应限制在明确允许的范围内。解析、加载、渲染和执行每一层都要经过信任检查，不能只在显眼的“启动命令”入口拦截。

打开项目本来是最普通的开发动作。正因为触发条件普通，版本检查应该放在接入工具之前，而不是等到仓库表现异常后再排查。