Cursor 0day: When Full Disclosure Becomes the Only Protection Left
453 points
• 2 days ago
• Article
Link
Mindgard 的安全研究人员在 Cursor 的 AI 辅助开发环境中发现了一个关键漏洞，该漏洞可导致任意代码执行。漏洞非常简单：当开发者在 Cursor 中打开项目时，应用会自动扫描是否存在 Git 可执行文件。如果仓库根目录下存在名为 git.exe 的恶意文件，Cursor 会立即执行该文件，且不会弹出任何提示、警告或征得用户许可。只要仓库保持打开，该执行过程会反复触发，给用户带来持续的安全风险。
尽管 Mindgard 于 2025 年 12 月 15 日报告了该漏洞并通过多种渠道跟进，但在超过七个月的时间里问题一直未得到修补。 Cursor 在一段时间没有回应后才承认问题，但公司既未提供更新、也未展示修复进展或采取保护用户的措施，反而在此期间发布了数十次软件更新。鉴于该漏洞性质直观且厂商缺乏应对，研究人员最终选择全面公开披露。
该漏洞影响严重：Cursor 被数百万开发者和数千家企业广泛使用，而利用该问题几乎只需打开一个被植入恶意文件的项目，凸显出现代快速演进的开发平台中存在的固有安全隐患。研究人员强调，对此类工具的信任应通过透明的行为和对安全缺陷的主动修复来建立，而不仅仅凭借工具的实用性。
针对缓解措施，受 Windows 管理的系统可临时使用 AppLocker 或 Windows App Control 等工具，限制工作区目录中指定可执行文件的运行。对个人用户，研究人员建议仅在隔离环境中打开不受信任的仓库，例如在虚拟机或 Windows Sandbox 中操作。对这些权宜之计的依赖凸显了当厂商未尽职责时，用户需要被告知风险并自行采取防护措施的必要性。
最终，此次披露反映出安全生态中一个更广泛且令人担忧的变化：传统的漏洞披露流程难以跟上以 AI 为重点、节奏快且高增长的公司环境。 Mindgard 发布这些细节，旨在帮助开发者和组织就其安全态势做出明智决策。研究人员认为，当一家公司停止沟通并将用户暴露在已知威胁中时，公开披露成为防止进一步风险的最后手段。
Security researchers at Mindgard have identified a critical vulnerability in the Cursor AI-assisted development environment that allows for arbitrary code execution. The flaw is remarkably simple. When a developer opens a project in Cursor, the application automatically scans for Git binaries. If a malicious file named git.exe is present in the root of the repository, Cursor executes it immediately without any user prompts, warnings, or approval. This process occurs repeatedly while the repository is open, posing a persistent security risk to users.
Despite being reported by Mindgard on December 15, 2025, and followed up on through various channels, the vulnerability remained unpatched for over seven months. While Cursor eventually acknowledged the issue after a period of unresponsive communication, the company failed to provide updates, demonstrate progress on a fix, or protect its users, even as it continued to release dozens of software updates. This lack of engagement, despite the straightforward nature of the bug, prompted the researchers to move to full public disclosure.
The implications of this vulnerability are significant, as Cursor is a widely adopted tool used by millions of developers and thousands of companies. Because the exploitation of this bug requires nothing more than opening a tainted project, it serves as a stark reminder of the security risks inherent in modern, rapidly evolving development platforms. The researchers emphasize that trust in such tools must be earned through transparent behavior and a proactive commitment to addressing security flaws, rather than just utility.
For users on Windows-managed systems, temporary mitigation involves using tools like AppLocker or Windows App Control to restrict the execution of specific binaries within workspace directories. On consumer systems, researchers advise opening untrusted repositories only within isolated environments such as virtual machines or Windows Sandbox. The reliance on such workarounds highlights the necessity for users to be informed of risks when vendors fail to fulfill their responsibilities.
Ultimately, this disclosure highlights a broader, troubling shift in the security landscape where traditional disclosure pipelines struggle to keep up with the fast-paced, high-growth environment of AI-focused companies. By releasing these details, Mindgard aims to ensure that developers and organizations can make informed decisions about their security posture. The researchers contend that when a company stops communicating and leaves users exposed to known threats, public disclosure becomes the only remaining option to prevent further risk.
201 comments • Comments Link
Cursor IDE 在 Windows 上存在严重漏洞：该软件会以高优先级在项目目录中执行名为 `git.exe` 的本地文件，这可能在打开仓库时触发任意代码执行。
对该漏洞的初次报告被忽视或冷处理。尽管通过 HackerOne 和直接联系管理层等渠道进行了数月跟进，但问题在当前版本中仍未修复。
根本原因是 Windows 在检查系统 PATH 之前会先在当前工作目录中搜索可执行文件，这是一个遗留行为；Cursor 未通过对 Git 命令使用完全限定路径来缓解这一风险。
有人认为克隆并打开不受信任的存储库本身就存在风险，但也有人强调，用户有合理期待：仅在 IDE 中打开一个文件夹不应导致任意本地二进制被执行。
当前的安全报告环境愈发紧张，大量 AI 生成的漏洞报告泛滥，使公司难以区分真实威胁与低质量噪声。
此问题被拿来与过去的 AutoRun 安全问题相比拟：当时外部来源自动执行文件造成了广泛且易被利用的攻击面，最终迫使操作系统和软件默认设置进行系统性更改。
IDE 通常通过弹出 "workspace trust" 对话框等机制来降低此类风险，但本次漏洞表明该机制可能被绕过，或在建立信任前就可执行代码。
该漏洞可被用于供应链攻击：攻击者将恶意的 `git.exe` 二进制提交到存储库或包中，从而感染任何仅为审查或贡献而打开该项目的开发者。
开发团队互动不足，外界因此猜测该问题要么被视为"不会修复"的设计选择，要么表明团队目前将功能发布速度置于安全工程之上。
披露过程也受到了批评：使用 AI 撰写报告虽提高了效率，但也增加了对报告中技术细节清晰度和意图的怀疑。
总体来看，这次讨论反映出对安全披露缺乏透明度以及以 AI 为中心的开发工具存在技术疏漏的深切不满。尽管对该漏洞是否比现代 IDE 中已有风险更"重大"存在争议，各方一致认为在没有明确用户意图的情况下执行本地二进制文件是一种危险的设计选择。 AI 新工具快速且常常"临时拼凑"的开发方式与软件环境对传统安全要求之间的紧张关系，仍是社区关注的核心问题。最终，这次互动凸显了当开发者将快速迭代置于既定安全协议之上时，遗留的操作系统行为与现代 IDE 功能结合，如何导致长期未得到解决的关键安全漏洞。 • A critical vulnerability exists where the Cursor IDE on Windows executes a local file named `git.exe` found within a project directory with high precedence, potentially leading to arbitrary code execution upon opening a repository.
• Initial reports of the vulnerability were met with dismissal or silence, and despite months of follow-up attempts through multiple channels including HackerOne and direct leadership outreach, the issue remains unpatched in the current version.
• The root cause lies in how Windows searches the current working directory for executables before checking the system PATH, a legacy behavior that Cursor fails to mitigate by using fully qualified paths for Git commands.
• While some argue that cloning and opening an untrusted repository already implies a risk of compromise, others emphasize that users have a reasonable expectation that merely opening a folder in an IDE will not trigger arbitrary binaries.
• The current climate for security reporting is increasingly strained, as the prevalence of AI-generated vulnerability reports makes it difficult for companies to distinguish between legitimate threats and low-quality noise.
• Comparisons were drawn to the "AutoRun" security issues of the past, where automatic execution of files from external sources created widespread, easy-to-exploit attack vectors that ultimately required systemic changes to OS and software defaults.
• IDEs typically mitigate such risks by implementing "workspace trust" dialogs, but the existence of this vulnerability suggests either a failure of that system or a bypass that allows execution before trust is established.
• The vulnerability could be weaponized through supply chain attacks, where a malicious actor commits a `git.exe` binary into a repository or package, effectively infecting any developer who simply opens the code to review or contribute.
• The lack of engagement from the development team has led to speculation that the issue is either viewed as a "won't fix" design choice or that the team is currently prioritizing feature velocity over security engineering.
• Critics of the disclosure process noted the use of AI to draft the report, which while efficient, adds a layer of skepticism regarding the clarity and intent of the underlying technical message.
The discussion reflects deep frustration with both the lack of transparency in security disclosure processes and the technical oversight of AI-centric development tools. While a significant portion of the conversation debates whether the vulnerability constitutes a "major" threat compared to existing risks in modern IDEs, there is a clear consensus that executing local binaries without explicit user intent is a dangerous design choice. The broader tension between the rapid, often "hacky" development of new AI tools and the traditional security requirements of software environments remains a primary concern for the community. Ultimately, the interaction highlights how legacy OS behaviors combined with modern IDE features can create critical security gaps that remain unaddressed when developers prioritize rapid iteration over established safety protocols.