Key Takeaways
- More than six months after an attempted coordinated disclosure, Cursor publicly responded to a critical zero-day only after Mindgard disclosed the unpatched vulnerability details publicly to protect affected users.
- Cursor's response frames the vulnerability as a shared responsibility issue, while Mindgard maintains that silently executing code when a repository is opened crosses a clear trust boundary that software should enforce.
- The debate extends beyond Cursor, highlighting a broader challenge as AI vendors race to deliver increasingly autonomous capabilities while secure-by-default design struggles to keep pace.
In This Article
When Mindgard privately reported a zero-click arbitrary code execution vulnerability affecting Cursor in December 2025, we expected the normal coordinated disclosure process to lead to a remediation timeline, a security advisory, or at the very least a clear technical discussion. Instead, more than six months passed without a patch or public acknowledgement.
Only after we publicly disclosed the vulnerability in our recent article, Cursor 0-Day: When Full Disclosure Becomes the Only Protection Left, did Cursor provide a detailed public response to media enquiries. Our team was initially encouraged to see the response from Cursor given that public discussion is an important part of improving software security, and Cursor also acknowledged that it should have communicated its determination directly to Mindgard. We appreciate that recognition.
The response itself, however, raises a much broader question. Is this an acceptable standard for protecting technology that organizations increasingly depend on as critical infrastructure?
Shared Responsibility Requires a Visible Trust Boundary
In their response published by Dark Reading, Cursor argues that the report falls outside both its bug bounty program and its definition of a security issue, because the company operates under a shared responsibility model. According to its response, customers are responsible for assessing the risk of every repository their code opens in addition to deciding which repositories, prompts, MCP servers, rules and tools they introduce into their environment, and vulnerabilities that depend upon malicious content already existing within that environment generally fall outside the scope of Cursor’s security responsibilities.
Shared responsibility has long been an established principle in security. Cloud providers, enterprise software vendors and infrastructure platforms all rely on it. The model succeeds because responsibilities are clearly defined and customers are given meaningful opportunities to make informed decisions about trust.
Cursor’s stated position is that the same principle applies here. However, developers open repositories they have never seen every day. They review pull requests, investigate bug reports, evaluate open-source projects, reproduce proofs of concept and assess third-party code. The expectation throughout decades of software development has remained remarkably consistent: opening a repository allows a developer to inspect its contents. It does not execute those contents.
Unfortunately, Cursor's vulnerable execution path crosses that boundary. Simply opening a repository containing a malicious executable named git.exe causes Cursor's own binary resolution logic to locate and execute that binary. The developer receives no warning, no prompt requesting permission and no indication that opening a folder is about to become code execution. Shared responsibility depends upon software exposing the decisions users are expected to make. When execution occurs without visibility or consent, responsibility remains with the software performing that execution.
Industry Precedent Already Exists
This class of vulnerability is neither novel nor controversial. Searching untrusted directories for executables has repeatedly resulted in security vulnerabilities across developer tooling over many years. The industry has consistently assigned CVEs, issued security updates and adopted the same remediation strategy: resolve executables from trusted locations rather than allowing attacker-controlled directories to influence executable search paths.
Git Credential Manager Core whose proof-of-concept was also Calculator renamed git.exe, GitPython, Git for Windows' gitk, Git GUI and Git LFS have all addressed variations of this same issue. The accepted fix is well understood: resolve git from a trusted absolute path and exclude the workspace directory from the executable search. Git for Windows itself already declines to search the current directory for this reason.
The underlying weakness is well understood, and so is the solution. This history matters because it demonstrates that the security community has already answered the question of ownership. When software executes an attacker-controlled binary because of an unsafe search path, responsibility rests with the software vendor to correct the behavior.
Security Controls Should Protect Normal Use
Cursor also identifies Workspace Trust as the appropriate mitigation for organizations that regularly work with untrusted repositories. Again, unfortunately the practical reality is less reassuring. Workspace Trust is disabled by default according to Cursor's own documentation, meaning new installations receive no protection from this execution path. Once enabled, users who trust a repository return Cursor to normal operating mode, where the vulnerable behavior remains available. Restricted Mode disables the AI and agent capabilities that define Cursor's value as an AI development environment, effectively asking users to stop using the product's primary functionality in order to remain protected.
Security controls should enable developers to work safely while continuing to perform normal development activities. They should not require developers to abandon the capabilities that attracted them to the product in the first place.
Cursor has also not publicly demonstrated that Restricted Mode intercepts this specific execution path, which occurs during project initialization rather than through the extensions, terminal or task execution mechanisms Workspace Trust was designed to govern.
Bug Bounty Scope and Customer Security Are Different Conversations
Every vendor has the right to define the scope of its own bug bounty program. Those programs exist to determine eligibility for rewards, and reasonable people can disagree about where those boundaries should be drawn. Those same reasonable people almost always agree that customer security is a very separate engineering question though.
The vulnerability reported by Mindgard was reproduced and confirmed through HackerOne. More than six months have elapsed since disclosure, and nearly two hundred Cursor releases have shipped without a remediation or security advisory. The important question is no longer whether the issue qualified for a bounty payment. The important question is whether customers can expect the behavior to be corrected.
A public commitment to remediation, together with a timeline and a demonstration that the proposed mitigations address the vulnerable execution path, would provide the clarity developers and organizations need.
We've Seen This Before
The Cursor discussion reflects something much larger than a single vulnerability. Every major technological shift experiences a period where innovation advances faster than security engineering. The early web transformed commerce, communication and society, but it also introduced an era of widespread security failures. Identity theft, financial fraud, browser exploits and insecure applications eroded public confidence in conducting business online. Consumers did not immediately trust online shopping because the technology had not yet demonstrated that it deserved that trust.
The industry eventually adapted. Browsers became more secure. Payment platforms invested heavily in fraud prevention. HTTPS became the standard rather than the exception. Security evolved from an optional feature into an expected characteristic of every serious online service. The transformational role of security in the end user experience enabled the extraordinary growth of e-commerce we now take for granted.
Artificial intelligence is approaching the same point. AI companies are shipping increasingly autonomous systems that interpret natural language, invoke tools, execute commands, access sensitive data and make decisions on behalf of users. Those capabilities create tremendous opportunities, but they also introduce new trust boundaries that software vendors are responsible for securing.
The human element has not changed. Developers will continue opening unfamiliar repositories. Students will continue experimenting with public projects. Organizations will continue evaluating third-party software before deciding whether to trust it. These are ordinary, expected behaviors that modern security architectures should accommodate rather than discourage.
As AI systems become more capable, secure defaults will become increasingly important. Users should not need to discover obscure configuration settings or fundamentally change how they work in order to remain protected. They should reasonably expect that opening a folder allows them to inspect code without executing it.
Trust Determines Adoption
The AI industry is moving at extraordinary speed, and that pace has produced remarkable innovation. It has also created a responsibility to ensure that security matures alongside capability. History consistently shows that features attract users, but trust keeps them. The technologies that achieve widespread, lasting adoption are those that make security an integral part of the user experience rather than an optional consideration left to individual customers.
Opening a repository should remain exactly what developers expect it to be: the beginning of understanding code, not the beginning of executing it. If the AI industry wants to avoid repeating the mistakes that slowed previous technology revolutions, protecting users by default must become a foundational design principle rather than a competitive differentiator. That transition is inevitable. The only remaining question is how quickly vendors choose to embrace it.
Continuing the Conversation
Mindgard appreciates Cursor's willingness to engage publicly on this issue and to acknowledge that communication during the disclosure process could have been stronger. Open technical discussion is an essential part of responsible vulnerability disclosure, particularly as AI-assisted development tools become increasingly capable and deeply integrated into software engineering workflows.
Security has always matured through collaboration between researchers and vendors. Every major technology platform has benefited from difficult conversations that challenged existing assumptions and ultimately resulted in stronger products and safer defaults. AI-assisted development should be no different. As these tools continue to evolve from code assistants into autonomous software agents, the industry has an opportunity to establish security expectations that match their growing capabilities.
Our hope is that this discussion contributes to that broader evolution. Developers should be able to adopt AI tools with confidence that fundamental trust boundaries are being protected, and vendors should continue raising the baseline for secure-by-default behavior. We look forward to continuing to engage with Cursor, and with the wider industry, as we collectively work toward a safer and more trustworthy developer experience.
