近日，安全研究人员披露了 Cursor 在 Windows 环境下存在的一项代码执行安全风险。攻击者可通过在恶意代码仓库根目录中放置特制的 git.exe 文件，使开发者在使用 Cursor 打开该项目时触发程序执行。整个过程无需用户主动运行文件，也不依赖 AI Agent 或提示词注入。
问题的关键在于 Cursor 对 Git 可执行文件的查找与调用机制。
当用户在 Windows 系统中使用 Cursor 打开代码仓库时，程序需要调用 Git 获取项目相关信息。如果可执行文件的搜索路径处理不当，项目目录中的 git.exe 可能被优先识别并执行，而不是系统中正常安装的 Git。
这意味着攻击者可以构造如下项目：
网站资讯
渠道合作
解决方案
更多服务恶意项目/
├── git.exe
├── README.md
├── src/
├── package.json
└── ...开发者从网络克隆或下载该项目后，如果直接使用存在相关问题的开发工具打开，恶意 git.exe 就存在被自动调用的风险。
与传统恶意程序不同，这种攻击场景的危险之处在于，用户可能没有主动双击任何 EXE 文件，只是执行了开发人员十分常见的“下载代码—打开项目”操作。
如果恶意程序成功以当前用户身份运行，其权限通常与当前登录用户一致。
因此，攻击者可能进一步尝试访问开发环境中的源代码、配置文件、SSH 凭据、开发令牌以及其他当前用户有权限读取的数据。如果开发电脑本身保存着服务器、Git 仓库或云平台相关凭据，潜在影响还可能进一步扩大。
这也让“不可信代码仓库”本身成为需要重点防范的攻击入口。
类似的 Windows 可执行文件搜索路径问题此前也曾在其他开发工具和 AI 编程工具的安全研究中出现。
其核心并不在 AI 模型本身，而在于：
开发工具调用 git、node、npx 等外部程序时，如果没有明确限定可信程序路径，就可能错误执行工作目录中的同名程序。
因此，这类问题与“AI生成恶意代码”“提示词注入”等攻击方式存在明显区别。即使完全不使用 AI Agent，只要软件存在不安全的程序搜索与调用逻辑，也可能产生风险。
在相关产品完成修复或确认安全版本之前，对于来源未知的 GitHub、论坛、网盘以及其他渠道提供的代码项目，建议不要下载后立即使用开发工具打开。
可以先检查项目根目录以及关键子目录中是否存在异常的：
git.exe
node.exe
npx.exe
where.exe
cmd.exe
powershell.exe尤其需要警惕与常用开发工具、系统命令同名的可执行文件。
企业开发环境还可以结合 Windows Defender Application Control、AppLocker、EDR 等安全措施限制开发工作区内未知可执行程序的启动。对于来源不明、需要测试的项目，可优先在 Windows Sandbox、虚拟机等隔离环境中进行检查。
随着 Cursor、Codex、Copilot、Gemini CLI 等 AI 开发工具越来越深入开发流程，代码仓库本身的安全边界也正在发生变化。
过去开发者可能认为：
“我只是把代码下载下来看看，只要不运行就没事。”
但当 IDE、插件和 AI 编程工具在打开项目后自动执行 Git 探测、依赖分析、任务扫描等操作时，“打开项目”本身就可能触发额外程序调用。
因此，对于陌生代码仓库，更稳妥的做法是：
先检查，再打开；来源不可信的项目优先在隔离环境中处理。
