AI编程工具Cursor近期被曝出严重安全隐患。安全公司LayerX在例行审计中发现，这款广受欢迎的代码编辑器存在一个访问控制缺陷，CVSS评分高达8.2，属于高危级别。问题的棘手之处在于，任何已经安装在Cursor里的扩展，都能在用户毫无察觉的情况下，把开发者的API密钥和会话令牌全部拿走——整个过程不需要弹窗授权，也不会留下任何告警日志。

明文存在本地，谁都能读

按照现代软件的安全惯例，像API密钥这类敏感凭证，理应交给操作系统层面的加密保管设施，比如macOS的钥匙串（Keychain）或者Windows的凭证管理器。这些系统级存储的好处在于，即便恶意程序进入了用户电脑，也需要突破额外的权限边界才能触碰到核心密钥。

但Cursor的做法显然偏离了这条基线。LayerX的研究人员发现，Cursor把用户的API密钥、会话令牌等敏感信息，直接塞进了一个本地的SQLite数据库文件，路径就躺在~/Library/Application Support/Cursor/User/globalStorage/state.vscdb。更关键的是，这个文件没有加密。也就是说，只要某个程序能访问文件系统，打开这个数据库就能直接读到明文内容。

按理说，扩展和核心编辑器之间应该有一道"隔离墙"。但Cursor目前并没有在扩展与这个SQLite数据库之间设置任何访问控制边界。结果是，每一个已安装的扩展，无论是官方推荐的还是用户从第三方市场随手下载的，都天然具备读取该数据库的权限。

攻击链路：四步完成静默窃取

这种漏洞的利用门槛远比想象中低。攻击者不需要构造复杂的远程渗透链路，甚至不需要诱导用户点击可疑链接。整个攻击流程可以拆解成四步：

第一步，攻击者在Cursor扩展市场发布一个看起来人畜无害的工具，可能是配色主题、代码格式化插件，或者某个号称能提升效率的小助手。这类工具往往功能单一、界面简洁，很容易通过市场审核，也极易获得用户信任。

第二步，开发者像往常一样点击安装。由于Cursor当前的扩展机制并不会在安装环节提示"该扩展需要访问您的凭证数据库"，用户看到的只是一个普通的权限申请列表，甚至完全没有权限提示。很多人会在无意识中完成安装。

第三步，恶意扩展在后台执行一段极其简短的查询脚本，直接定位到state.vscdb文件，从中提取存储的API密钥和会话令牌。因为这些数据本身就是明文，扩展无需破解、无需解密，读取即是得手。

第四步，提取到的凭证通过HTTP请求或者其他隐蔽通道，被发送到攻击者控制的远程服务器。整个过程静默完成，用户侧看不到网络异常提示，Cursor也不会触发任何安全告警。

危害不止于密钥本身

很多开发者习惯在Cursor里配置多个AI服务的接入密钥，涵盖OpenAI、Google Cloud、Anthropic等主流平台。一旦这些密钥被批量窃取，连锁反应会迅速蔓延。

最直接的风险是账户接管。攻击者拿到会话令牌后，相当于直接拥有了开发者在该AI服务上的身份凭证，可以查看历史对话、访问已上传的私有代码片段，甚至调用高额度计费接口。对于绑定了企业账户或按量付费套餐的用户来说，这意味着账单可能在短时间内飙升至惊人数字。

更深层的隐患在于数据泄露。Cursor里沉淀的往往是企业最核心的代码资产、架构设计文档，以及未公开的算法逻辑。攻击者通过窃取的后台访问权限，不仅能读取历史聊天记录，还可能顺藤摸瓜，摸到关联的代码仓库元数据。对于金融、医疗、基础设施等对合规要求极高的行业来说，这种泄露的代价很难用金钱直接衡量。

厂商回应与修复僵局

LayerX在2026年2月1日就将漏洞细节正式提交给Cursor安全团队。对方在2月5日确认收到了报告，但给出的初步回应并不令安全社区满意。Cursor方面的核心论点是：扩展和用户进程处于同一本地信任边界内，任何具备文件系统访问权限的本地应用理论上都能读取这些数据，因此这更像是一个"预期内的行为"，而非严格意义上的漏洞。

截至2026年4月28日，这个CVSS 8.2的高危问题依然处于未修复状态。Cursor官方的态度倾向于让用户自行承担扩展筛选的责任，建议只安装可信来源的插件。但在LayerX和多位独立安全研究者看来，这种回应回避了根本问题——既然Cursor选择将高价值凭证集中存储在本地，就应该为这份集中化带来的风险提供对等的防护机制，而不是把安全责任完全转嫁给终端用户。

眼下能做什么

在Cursor推出结构性修复之前，开发者能采取的防御措施相对有限，但也不是完全被动。

第一，清理现有扩展。打开Cursor的扩展面板，逐条审视已安装列表。对于那些长期未更新、作者信息模糊、下载量异常偏低，或者功能描述含糊不清的插件，建议直接卸载。宁可暂时牺牲一点便利性，也不要给潜在的恶意代码留驻留空间。

第二，隔离高价值密钥。如果工作流允许，尽量把核心API密钥从Cursor的全局配置中剥离出来，改用环境变量注入或者临时密钥轮换机制。这样即便本地数据库被读取，攻击者拿到的是一枚已经失效或权限受限的令牌。

第三，关注官方更新。这个漏洞的修复并不涉及复杂的密码学重构，核心改动只有两个：给扩展和数据库之间加一道访问控制边界，以及把凭证迁移到系统级加密存储。如果Cursor团队后续调整安全策略，优先升级版本。

从行业视角看，这起事件再次暴露了AI编程工具在快速迭代中的安全债问题。当产品功能以周为单位更新时，凭证存储、权限隔离这类底层架构设计往往容易被忽视。对于开发者而言，在享受AI辅助编程效率红利的同时，保持对本地凭证分布的敏感度，或许应该成为新的安全习惯。