事件背景：AI 开发工具的“隐秘角落”
在 AI 辅助编程领域，Cursor 无疑是目前最火的编辑器之一。然而，近期安全研究机构 LayerX 披露的一项发现，给开发者群体敲响了警钟。研究指出，Cursor 在处理敏感凭据（如 API 密钥、会话令牌）时存在严重的安全架构漏洞，其 CVSS 评分高达 8.2。
从我们的应急响应经验来看，开发者往往过度信任自己使用的开发工具，而忽略了编辑器插件生态背后的“信任边界”。当一个工具将便利性置于安全性之上时，开发者所依赖的生产力工具，反而可能成为攻击者窃取核心资产的“跳板”。
攻击链分析：静默窃取的全过程
这一漏洞的核心在于 Cursor 对敏感信息的存储方式。与大多数现代应用利用操作系统自带的安全加密层（如 macOS 的 Keychain 或 Windows 凭据管理器）不同，Cursor 将这些高度敏感的信息明文存储在本地的一个 SQLite 数据库中（路径通常位于 ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb）。
更关键的是，Cursor 编辑器并未在核心程序与扩展程序之间建立有效的访问控制机制。这意味着：
1、攻击植入：攻击者通过发布或诱导开发者安装带有恶意代码的扩展程序。 2、权限越权：由于缺乏隔离，任何已安装的扩展程序都能直接读取该 SQLite 数据库。 3、静默窃取：恶意扩展无需任何用户交互，即可在后台静默查询并提取 API 密钥与会话令牌。 4、外发数据：通过简单的后台请求，将窃取的凭据发送至攻击者控制的服务器。
这一过程没有任何 UI 异常，也不会触发任何安全提示，开发者往往在不知不觉中就丢失了访问云端 AI 模型及开发环境的最高权限。
专家视角：为何这是开发者的“阿喀琉斯之踵”
在本次事件中，Cursor 官方的态度引发了广泛讨论。厂商倾向于认为这是“设计使然”，并将安全责任转嫁给用户，要求开发者自行定义信任边界。但在实际的企业安全运营中，要求每一位开发者去审计数以百计的插件代码是不现实的。
这一环节是很多企业容易忽视的盲区。类似攻击近年来明显增加，攻击者不再仅仅盯着传统的服务器漏洞，而是通过攻击开发者的个人终端设备，通过窃取 Git 凭据、云服务 API Key 等方式，实现对企业生产环境的“降维打击”。
安全建议与 Solar 防护经验
针对此类风险，Solar 应急响应团队建议广大开发者及企业安全团队采取以下措施：
1、最小化安装：对 IDE 扩展程序进行严格管理，仅安装官方认证或经过代码审计的插件，拒绝来源不明的第三方扩展。 2、凭据隔离：如果条件允许，避免将长期有效的 API 密钥直接存储在编辑器中，优先使用环境变量或临时的、具有受限权限的访问令牌。 3、监控异常外联：企业内网应建立针对开发终端的异常流量监控，重点排查编辑器进程发起的非预期网络请求。 4、强化身份验证：对于依赖 AI API 的服务，应开启多因素认证（MFA），即使 API 密钥泄露，也能在一定程度上阻断攻击者的进一步操作。
安全是一个动态的过程，工具的便捷不应成为安全防线的豁免权。在享受 AI 带来的效率提升时，请务必保持对“开发者终端”这一关键资产的警惕。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com