警惕Cursor插件侧载风险:别把.env送给窃贼

昨天刷 Reddit 和 Twitter，看见有人炸锅了：有个挺火的 Cursor 插件被插了后门。

先说结论，这事不是吓唬人，也不是键盘侠的危言耸听。

我一开始也不信，心想 Cursor 官方对插件审核不是挺严的吗？但仔细扒了一下，那个插件是个人开发者搞的，通过某种侧载机制绕过了官方市场。它假装是一个普通的代码高亮插件，实际在后台偷偷读取你的 .env 文件和 git 配置。

说实话，这种“AI 工具链信任危机”不是第一次了。你想想，现在的 AI IDE 要读你的整个项目结构，要访问你的本地文件，甚至要联网调用大模型 API。如果给它开了管理员权限，它想干啥都行。

这个坑我替你踩过了

我之前为了偷懒，装过几个第三方的 LLM 对接插件，想把 Cursor 接上我本地部署的 Qwen 模型。当时图快，直接在 GitHub 上克隆了一个不知名的 repo，跟着 README 里的 shell 命令跑了 npm install 和 cursor install。

结果就是，我的项目目录里多了一个 node_modules 文件夹，里面全是些没听过的包。我当时没在意，直到有一次 CI 构建报了一堆奇怪的安全警告，我才去翻 package.json。

发现那个插件偷偷依赖了一个叫 data-helper 的包，这个包的代码里赫然写着 fetch 请求，指向一个陌生的 IP。虽然那个请求当时没发出去（因为我网络断了），但恶意意图昭然若揭。

那一刻我很慌。不只是因为安全，而是因为我的 AI 助手知道我在写什么。它不仅知道我在写代码，还知道我下一步要做什么，我的变量命名习惯，我还没提交的敏感逻辑。这种心理上的不安全感，比单纯的代码泄露更让人难受。

怎么防？别裸奔

现在我对 Cursor 插件的策略很死板：只用官方 Marketplace，或者只用自己写的、锁死版本的插件。

如果你有需求要接入本地模型，别用那些花里胡哨的第三方插件。直接用 Cursor 内置的配置，或者写个极简的 MCP (Model Context Protocol) server。MCP 现在是事实标准，你可以完全掌控它的行为，而且代码量极少，没有供应链攻击面。

比如，你可以自己写一个 50 行左右的 Dart 或 Node.js 脚本，通过 MCP 协议把本地模型暴露给 Cursor。这样，你清楚每一行代码在干嘛，不需要信任任何外部“黑盒”插件。

对于 Flutter 开发者，虽然 Cursor 本身是基于 Web 和 Node 生态的，但理解 MCP 的核心逻辑很重要。以下是一个概念性的 Dart 伪代码，仅用于演示如何建立与本地模型的连接，注意这不是生产环境的完整实现，实际开发中你通常会用 Node.js 编写 MCP 服务端，或者使用现成的开源 MCP SDK：

// 这是一个极简的 MCP 客户端示例伪代码，仅用于演示概念// 实际上 Cursor 原生支持 MCP，你可以参考官方文档配置import'dart:convert';void main(){// 1. 连接到本地模型服务（假设你的 Qwen 跑在 8080 端口）// 注意：这里不发送任何身份凭证，只发送 Prompt// 2. 将 Prompt 发给 LLM// 3. 解析返回的 JSON，提取补全代码  print('MCP connection established to local LLM');// ... }

除了代码层面，还得养成几个习惯。

第一，每次给 Cursor 打开新项目，先检查 .cursor 目录和 settings.json。看看有没有奇怪的启动脚本，有没有指向外网的 Webhook。有些插件会在初始化时注入奇怪的钩子函数。

第二，还有个笨办法但有效：把 .env 文件从项目根目录移走，或者用 .gitignore 严格屏蔽。更重要的是，确保你的 CI/CD 管道不会把这些文件推送到任何公共仓库。很多事故是因为开发者习惯性地把 .env 提交了，然后插件又把它读了出来，最后被 CI 暴露了。

写在最后

工具越强，权限越大，风险越高。

我们习惯把代码喂给 LLM，但我们很少停下来想：如果 LLM 的载体本身是个贼呢？

以前我们担心的是 IDE 本身慢，现在得担心它“不忠”。对于独立开发者来说，代码不仅是资产，更是隐私。别为了那点便捷性，把命门交给未知的第三方依赖。

你们平时会检查 Cursor 插件的依赖树吗？还是说装了就完事，直到出事才查？