网络安全
Check Point 发现关键 Cursor IDE 缺陷：AI 驱动开发中的静默威胁
全球人工智能辅助代码工具市场价值约为 6.7 年为 2024 亿美元，预计到 25.7 年将超过 2030 亿美元如今，对现代软件开发工具的信任比以往任何时候都更加重要。这股热潮的核心是一类新型的人工智能代码生成器——例如 Cursor——它将传统编程环境与人工智能相结合，从而实现代码工作流程的自动化和加速。
Cursor 尤其受到开发者的青睐，因为它深度集成了大型语言模型 (LLM)，允许用户使用自然语言提示生成、调试和重构代码。它是一款 AI 驱动的 集成开发环境（IDE）— 一款软件应用程序，将开发人员编写、测试和管理代码所需的核心工具集中在一个地方。
但随着越来越多的开发过程由人工智能驱动和自动化，这些工具中的漏洞构成了越来越严重的风险。
随着最近发现 CVE-2025，54136，一个由 Check Point Research此漏洞并非用户代码中的 bug，问题在于 Cursor 如何处理信任和自动化。攻击者可以利用 Cursor 提供的可信自动化功能，在受害者设备上悄无声息地执行恶意命令，而该功能并非旨在被武器化。
表面上看起来方便 AI编码助手在这种情况下，它就成了一个后门——每当开发人员打开他们的项目时，它就可能在没有任何警告的情况下被触发。
缺陷：通过 MCP 攻击信任
这个漏洞的核心是 Cursor 的 模型上下文协议 (MCP)——一个允许开发人员定义自动化工作流程、集成外部 API 并在 IDE 中执行命令的框架。MCP 的功能类似于插件，在简化 AI 辅助代码生成、调试和项目配置方面发挥着核心作用。
该安全问题源于 Cursor 处理信任的方式。引入 MCP 配置时，系统会提示用户批准一次。然而，在初始批准之后，即使内容发生更改，Cursor 也不会重新验证该配置。这会导致一种危险的情况：看似良性的 MCP 可能会被恶意代码悄无声息地替换，并且修改后的配置将会执行，而不会触发任何新的提示或警告。
攻击者可以：
-
将看似无害的 MCP 文件提交到共享存储库。
-
等待团队成员在 Cursor 中批准。
-
修改 MCP 以包含恶意命令（例如，反向 shell 或数据泄露脚本）。
-
每次在 Cursor 中重新打开项目时，均可获得自动、静默的访问权限。
该缺陷在于 Cursor 将信任绑定到 MCP 键名称，而不是配置内容。一旦信任，名称可以保持不变，但底层行为却变得危险。
现实世界的影响：隐身性和持久性
这种漏洞不仅仅是理论上的风险——它代表了现代开发环境中的实际攻击媒介，在现代开发环境中，项目通过 Git 等版本控制系统在团队之间共享。
-
持久远程访问： 一旦攻击者修改了 MCP，每当合作者打开项目时，他们的代码就会自动触发。
-
静默执行： 没有显示任何提示、警告或警报，使得该漏洞非常适合长期持久存在。
-
权限提升： 开发人员的机器通常包含敏感信息（云访问密钥、SSH 凭证或专有代码），这些信息可能会受到损害。
-
代码库和 IP 盗窃： 由于攻击是在后台发生的，因此它成为了获取内部资产和知识产权的静默门户。
-
供应链弱点： 这凸显了人工智能开发流程中信任的脆弱性，这些流程通常依赖于自动化和共享配置，而没有适当的验证机制。
机器学习遇到安全盲点
Cursor 的漏洞凸显了机器学习与开发者工具交汇领域中出现的一个更大问题：对自动化的过度信任。随着越来越多的开发者平台集成 AI 驱动的功能（从自动补全到智能配置），潜在的攻击面急剧扩大。
像这样的字词 远程代码执行（RCE） 和 反壳 不再是老式黑客工具的专利。在这种情况下，RCE 是通过利用已获批准的自动化技术实现的。只需修改已受信任的配置，即可启动反向 Shell（受害者的计算机连接到攻击者）。
这代表着信任模型的崩溃。IDE 假设已批准的自动化文件永远安全，实际上为攻击者提供了一个静默且可重复的进入开发机器的入口。
是什么让这种攻击媒介如此危险
CVE-2025-54136 尤其令人担忧的是其隐蔽性、自动化和持久性。在典型的威胁模型中，开发人员通常被训练来识别恶意依赖项、奇怪的脚本或外部漏洞。但在这里，风险隐藏在工作流程本身中。这是一个攻击者利用 信任 而不是代码质量。
-
隐形重返大气层： 每次 IDE 打开时都会发生攻击，除非外部监控，否则没有任何视觉提示或日志。
-
进入门槛低： 任何具有存储库写权限的合作者都可以将 MCP 武器化。
-
漏洞利用的可扩展性： 在许多开发人员使用共享工具的组织中，单个经过修改的 MCP 就可能广泛传播危害。
建议的缓解措施
Check Point Research Cursor 于 16 年 2025 月 30 日负责任地披露了该漏洞。Cursor 于 2025 年 XNUMX 月 XNUMX 日发布了补丁来解决该问题，但更广泛的影响仍然存在。
为了防范类似的威胁，组织和开发人员应该：
-
将 MCP 视为代码： 审查并控制所有自动化配置的版本。将它们视为代码库的一部分，而不是良性元数据。
-
更改后重新验证： 当先前受信任的配置发生改变时，工具应该实施提示或基于哈希的验证。
-
限制写访问： 使用存储库访问控制来限制谁可以修改自动化文件。
-
审计AI工作流程： 了解并记录每个支持 AI 的配置的作用，尤其是在团队环境中。
-
监控IDE活动： 跟踪并警告由 IDE 触发的自动命令执行以捕获可疑行为。
结论：缺乏监督的自动化是一个弱点
Cursor IDE 漏洞应该成为整个软件行业的警示。AI 增强型工具不再是可有可无的，它们正变得至关重要。但随着 AI 的普及，我们对信任、验证和自动化的理解也必须发生转变。
CVE-2025-54136 暴露了以便利为导向的开发环境的风险，这些环境并未验证持续行为。为了在这个新时代保持安全，开发人员和组织必须重新思考“可信”的真正含义，并确保自动化不会成为隐藏在众目睽睽之下的无声漏洞。希望从技术角度理解该漏洞的读者，请阅读 Check Point Research 报告。
