Cursor被曝高危漏洞：任何插件都能偷走你的API密钥，而官方说"这是用户自己的事"。
漏洞有多离谱？
安全公司LayerX挖出的这个漏洞，CVSS评分8.2。核心问题一句话就能说清：Cursor把开发者的API密钥和会话令牌，存在一个本地SQLite数据库里，而且完全不设防。
文件路径就明晃晃地躺在那儿：~/Library/Application Support/Cursor/User/globalStorage/state.vscdb。
任何安装的扩展程序都能读取这个文件。不需要特殊权限，不需要用户点击确认，甚至不会触发任何警报。恶意插件装上的那一刻，你的凭证就已经被偷走了。
这和正经软件的做法完全相反。macOS有钥匙串，Windows有凭据管理器，这些都是系统级的加密存储。Cursor偏要把敏感信息裸奔在本地，还让所有插件共享同一个信任边界。
攻击链条简单到可笑：装一个看起来无害的扩展→扩展读取数据库→明文提取密钥→直接访问你的AI服务账户。整个过程"低攻击复杂度"，脚本小子都能上手。
官方回应：甩锅三连
LayerX今年2月1日提交报告，Cursor安全团队2月5日确认收到。然后呢？
他们的核心论点：扩展和用户处在"同一本地信任边界"。翻译成人话：任何能访问你文件系统的本地应用，本来就能读这些数据。
这个逻辑的问题在于——扩展不是"任何本地应用"。它是用户主动安装进Cursor工作流的，用户默认信任Cursor的生态环境。把扩展和系统级应用混为一谈，是在偷换概念。
更离谱的是，截至4月28日，漏洞仍未修复。官方给出的"解决方案"：用户自己负责，只装可信扩展。
这相当于银行金库不上锁，然后说"储户自己别把钱存进来就行了"。
开发者实际面临什么风险
很多程序员在Cursor里接入了OpenAI、Anthropic、Google等第三方AI服务。密钥一旦泄露，攻击者能直接干这些事：
• 调用你的付费API额度，账单爆炸
• 读取你上传给AI的代码片段，商业机密裸奔
• 篡改AI返回的结果，在你代码里埋后门
• 横向渗透，用同一套密钥尝试登录你的其他账户
最阴险的是全程无感知。你不会收到异地登录提醒，不会看到API调用异常告警，因为攻击者用的是你自己的密钥、你自己的会话。
为什么Cursor敢这么干
从产品逻辑倒推，这很可能是技术债的代价。
Cursor基于VS Code分支开发，而VS Code的扩展架构设计之初就没把"恶意扩展"当成主要威胁模型。大家都是开源工具，社区自律，谁想到AI时代会把真金白银的API密钥塞进编辑器？
但Cursor不是普通代码编辑器。它是"AI原生"开发环境，用户必然要在里面配置各种AI服务的访问凭证。产品定位变了，安全架构没跟上。
另一个猜测：系统级密钥存储有跨平台兼容成本。Windows用Credential Manager，macOS用Keychain，Linux还有secret-service、KWallet等一堆实现。Cursor选择SQLite，可能是为了"一套代码跑遍所有桌面"。
省下的开发成本，现在以用户安全风险的形式还回来了。
现在能做什么
在Cursor推出结构性修复之前，LayerX给出的建议很实在：
• 审查已安装的每个扩展，不认识的一律卸载
• marketplace里没经过验证的工具，别碰
• 定期检查API服务商的调用日志，发现异常用量立刻轮换密钥
长期看，Cursor必须把凭证迁移到系统级加密存储，并在扩展和数据库之间建立隔离边界。这不是"要不要做"的问题，是"还能拖多久"的问题。
一个更尖锐的问题
Cursor的回应暴露了一种危险的产品思维：把"本地信任边界"当成安全免责金牌。
按照这个逻辑，任何桌面应用都可以把敏感数据裸奔在文件系统，然后告诉用户"其他应用也能读，所以不怪我"。这种推理如果成立，整个桌面软件的安全基线都要重写。
更讽刺的是对比。同样是AI编程工具，GitHub Copilot怎么做的？它把用户OAuth令牌存在系统钥匙串里，扩展进程通过受控API访问，而不是直接读数据库文件。
技术方案是现成的，Cursor只是没做。
当一款产品的核心卖点是"提升开发效率"，它的安全架构却在拖后腿——开发者的时间省下来了，省下的时间可能用来处理密钥泄露后的烂摊子。这笔账，真的划算吗？
热门跟贴