NameTrap 标识符投毒攻击

AI 编码智能体的工作方式决定了它的软肋：为了理解任务，它大量消费来自网络的第三方代码——克隆仓库、阅读示例、检索文档。这些内容共同构成模型的上下文，塑造它接下来写出的代码。据 arXiv:2610.34253，NameTrap 利用的正是这一点：攻击者拿到某个公开的第三方 Python 文件，不修改任何逻辑语句，只把变量名、函数名等标识符重命名——例如把临时变量改名为与不安全反序列化相关的惯用名称——然后让这份「看起来正常」的文件进入智能体的上下文。

攻击是工程化的而非手工的：攻击侧智能体按目标 CWE 类别的命名惯例迭代调整标识符，每次改动都在本地用探测补全验证效果，确认改名后的文件能稳定诱发智能体生成目标弱点的代码后才发布诱饵。因此最终诱饵的特征是双重的：不含任何注入指令，也不含任何漏洞语句——传统上用来发现恶意代码的两类信号都不存在。

论文的评估覆盖 6 个 AI 编码智能体、10 个底层语言模型、4 类漏洞：CWE-78（命令注入）、CWE-79（跨站脚本）、CWE-327（加密算法使用不当）、CWE-502（不安全反序列化）。实验起点选取「干净版本从不触发目标弱点」的文件，以剥离文件本身的问题。结果：标识符层面的操纵在六个智能体上取得 22.5%–56.0% 的整体攻击成功率，个别智能体与模型组合达 75.0%；对照实验显示其显著优于随机重命名、中性重命名与既有的 XOXO 标识符投毒攻击。

两个稳健性发现值得注意：攻击在繁体中文提示词环境下依然有效，说明不是英文语境的巧合；攻击可跨模型迁移，在一个模型上对齐好的命名方案对其他模型同样起作用，这意味着攻击者一次制作、多处生效。

论文测试了两类防御，均告失守。检测侧：三个 AI 安全分析器与四个静态分析器扫描投毒文件后，没有一个报告目标弱点——原因在于文件本身确实没有漏洞语句，漏洞只出现在智能体读完文件后生成的代码里，静态分析的对象就找错了地方。防御侧：在智能体系统中加入安全提醒（security reminder）未能稳定阻止漏洞被引入。

这与本站已有条目构成的攻击图谱形成互补：工具投毒（ENC-SECURITY-20）污染的是 MCP 工具描述等元数据，Repeat-After-Me（ENC-SECURITY-22）利用的是视觉与文本提示注入，NameTrap 则开辟了标识符这条更隐蔽的通道。三者的共同点是对「智能体消费的外部内容即攻击面」这一事实的利用，差异在载体：元数据、多模态内容、还是代码本身的名字。

NameTrap 对实践者的启示集中在供应链审查的扩展：对进入智能体上下文的第三方代码，除了扫描漏洞语句与恶意指令，还应审查标识符命名中的异常模式——例如与已知 CWE 惯例高度对齐却不合项目自身命名风格的改名。论文本身尚未给出经验证的防御方案，可行的方向包括对依赖 diff 做标识符级审查、对智能体的代码生成结果独立做漏洞扫描（扫描产物而非上下文）、以及在沙箱中限制生成代码的执行权限（参见沙箱逃逸条目 ENC-SECURITY-14 关于边界完整性的讨论）。

局限与开放问题：实验基于论文自建的评估环境，真实世界中此类攻击的在野案例尚无公开报告；成功率随模型与智能体配置波动较大；随着模型对齐训练加强，命名诱导的有效性可能变化。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。

随着编码智能体在软件供应链中的位置越来越靠前，针对其输入上下文的投毒攻击预计会持续演化：标识符之外，注释、文档、提交信息等「看似无害的元内容」都可能成为载体。防御侧的对应方向是把「上下文完整性」纳入智能体安全的常规评估维度，并发展面向生成产物的独立审计工具。NameTrap 这类研究的价值在于提前暴露攻击面——在在野利用出现之前，把名字写进威胁模型。