北京
2026年1月14日，安全研究机构Pillar Security披露了一个编号为CVE-2026-22708的漏洞，影响AI编程工具Cursor。这个漏洞的特殊之处在于：开发者明明看到并批准了一条完全无害的命令，最终执行的却是攻击者的代码。
问题出在"批准"本身
大多数团队在使用AI编程代理时，都会配置一份允许列表（allowlist），列出代理可以不经询问直接运行的命令。这套机制背后的假设是：任何危险操作都会以弹窗形式出现，开发者可以选择拒绝。但Pillar Security的研究人员证明，这个假设并不成立。
当Cursor以自动运行模式（Auto-Run Mode）配合允许列表使用时，部分shell内建命令（shell built-ins）既不会出现在允许列表中，也不会触发审批弹窗。研究人员点名了export、typeset和declare这三条命令。它们不是磁盘上的独立程序，而是shell自带的指令，因此绕过了检查机制。
一条README就能改变命令含义
攻击路径是这样的：任何能把文本送到代理面前的内容——一个README文件、一个依赖包、一条issue评论——都可以利用这些内建命令静默修改环境变量。比如Git读取的PAGER变量（决定输出显示方式）或Python读取的PYTHONWARNINGS变量，平时没人会注意它们。
环境变量被修改后，开发者接下来批准的任何命令——哪怕普通得像git branch——实际运行的已经是攻击者的代码。整个过程中，开发者看到的是准确的审批提示，批准的是一条真正无害的命令，却照样获得了任意代码执行的结果。原因在于，那条命令的含义在一分钟前就被从未展示给开发者的操作偷换了。
没有内存破坏，没有权限提升
这个漏洞不涉及内存破坏，也没有权限提升。攻击者不需要利用任何底层系统缺陷，纯粹靠"改变命令的上下文"就达到了目的。Cursor官方将该漏洞评级为High（高危），并在2.3版本中完成修复。
值得注意的是，即使允许列表完全为空，这个攻击依然有效。因为内建命令根本不经过允许列表的检查，空列表和完整列表在这一点上没有区别。
Docker沙箱能挡住什么，挡不住什么
针对这类问题，Docker沙箱提供了一层边界防护：它把代理的执行环境隔离在容器内，限制其访问宿主机文件系统和凭据。但沙箱并不能解决所有问题——它无法阻止代理在容器内部执行恶意代码，也无法识别"命令含义被篡改"这类逻辑层面的攻击。
要覆盖单台笔记本允许列表遗漏的场景，需要组合使用工具包（kits）、组织策略和审计日志。这些机制从不同层面补充了边界防护的盲区：工具包约束代理可用的工具范围，组织策略统一安全基线，审计日志则让事后追溯成为可能。
这个案例的核心教训是：允许列表机制本身存在结构性盲区——它假设"危险操作一定会以可识别的形式出现"，但攻击者可以改变命令的语义，让无害的命令变成有害的执行。安全设计不能只依赖单一检查点，多层防护才是应对这类"语义偷换"攻击的正解。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
