# Critical Unpatched Cursor Vulnerability Allows Instant Code Execution on Windows—Seven Months Without a Fix


An AI development tool used by millions remains exposed to arbitrary code execution through a trivially exploitable flaw in its Git binary handling.


A critical vulnerability in Cursor, one of the world's most popular AI-assisted development environments, has been left unpatched for over seven months despite multiple disclosure attempts to the vendor. Security firm Mindgard disclosed the flaw publicly on July 15, 2026, revealing that attackers can achieve arbitrary code execution on any Windows developer's machine simply by including a malicious git.exe file in a Git repository's root directory—with no user interaction beyond opening the project.


With Cursor boasting over 7 million active users, the scope of potential exposure is enormous, particularly given that developers often clone and open repositories from untrusted or compromised sources.


## The Threat


The vulnerability is deceptively simple, yet devastating in its implications.


When Cursor loads a project on Windows, it automatically searches for Git binaries in multiple locations to support its version control and repository analysis features. If a developer opens a malicious repository containing a git.exe file in the project root, Cursor will execute that binary automatically as part of its path resolution logic. No warning appears. No approval is requested. The developer never knows their machine has just run untrusted code.


Mindgard describes the exploit as straightforward and practically indistinguishable from a proof-of-concept:


  • Clone a repository (or create one) with a malicious git.exe in the root directory
  • Open the repository in Cursor on Windows
  • The malicious executable runs immediately with the developer's privileges

    • The attack requires no:

  • Prompt injection
  • Model manipulation or jailbreaking
  • Memory corruption exploits
  • Sophisticated social engineering
  • Complex attack chains

    • "Exploitation simply requires a developer to open a project containing a git.exe binary in the repository at the root," Mindgard wrote in its disclosure. "Cursor will execute it automatically as part of its path resolution logic without warning, approval, or even an indication that executable content from the repository is about to run."


    ## Background and Context


    Cursor has rapidly become one of the leading AI-assisted coding environments since its launch, positioning itself as a superior alternative to GitHub Copilot and other AI code assistants. The platform integrates Claude, GPT-4, and other LLMs directly into a developer-friendly IDE, allowing real-time code suggestions, refactoring, and debugging assistance. Its 7+ million active user base includes individual developers, startups, and enterprises—making any widespread vulnerability a potential supply-chain vector for attacks.


    The Disclosure Timeline Reveals a Pattern of Silence:


    | Date | Event |

    |------|-------|

    | December 15, 2025 | Mindgard reports vulnerability to Cursor |

    | January 2026 | Cursor CISO invites Mindgard to HackerOne bug bounty; issue resubmitted and confirmed reproducible |

    | July 15, 2026 | Mindgard publishes public disclosure after seven months of inaction |


    According to Mindgard, despite the flaw being confirmed as reproducible on HackerOne and receiving acknowledgment from Cursor's leadership, no patch, timeline, or communication has been provided to affected users. "Coordinated disclosure only works when there is coordination," Mindgard stated in its report. "Seven months after initial disclosure, we have no indication that users are being protected, that remediation is underway, or that affected organizations have been informed."


    Cursor has not responded to SecurityWeek's request for comment as of publication.


    ## Technical Details


    Understanding the Path Resolution Attack Vector


    The vulnerability stems from how Cursor resolves Git binary locations on Windows systems. The application needs to locate the git executable to perform repository operations, analyze commit history, and support version control features. Rather than hardcoding a single path or requiring explicit user configuration, Cursor searches multiple locations in a predefined order—a practice that is generally reasonable for usability but becomes dangerous when it includes untrusted directories like the workspace itself.


    The path resolution logic includes:

  • User's PATH environment variable
  • System Git installation directories
  • The repository root (the vulnerable inclusion)
  • Bundled Git binaries

    • On Linux and macOS, this same vulnerability exists in theory but presents far lower practical risk because those operating systems more rigidly enforce executable permissions and lack the .exe file extension semantics that make Windows exploitation straightforward. However, Windows developers face the full brunt of this flaw.


    Why This Bypasses Common Defenses


    Modern developer machines often run endpoint detection and response (EDR) tools, antivirus software, and security monitoring. However, many of these tools are configured to trust files that exist within a developer's active workspace—the assumption being that developers intentionally added those files. A malicious git.exe disguised as a legitimate repository tool can evade heuristic detection because:


  • It resides in a location the developer "invited" by cloning the repo
  • It runs as part of an expected application startup workflow
  • It executes with the developer's user privileges, often bypassing process sandboxing
  • Initial execution happens before EDR tools can establish behavioral patterns

    • ## Implications for Developers and Organizations


    The attack surface is broad and growing.


    For individual developers:

  • Supply chain infiltration: Attackers can compromise popular open-source repositories or create convincing fakes to distribute malware to thousands of developers simultaneously
  • Lateral movement: Compromised developer machines often have access to internal repositories, deployment keys, CI/CD credentials, and production environments
  • Credential theft: Attackers gain access to SSH keys, GitHub tokens, API credentials, and environment variables stored on the developer's machine

    • For organizations:

  • Enterprise risk: A single developer opening a malicious repository can compromise an entire organization's codebase, build systems, and production deployments
  • Zero visibility: Without endpoint security tuned specifically for development environments, organizations may never detect that code execution occurred
  • Compliance impact: Depending on the nature of the data accessed, a breach via this vector could trigger regulatory notification requirements under GDPR, CCPA, or industry-specific regulations

    • For AI-assisted development tools:

  • Emerging trust model problem: As AI coding assistants become central to the development workflow, their security posture directly impacts the security of all downstream code and infrastructure
  • Vendor accountability: The seven-month lack of response raises serious questions about Cursor's security maturity and incident response capabilities

    • ## Recommendations


    For Cursor Users (Immediate Actions)


    1. Audit repositories: Review any repositories you've opened in Cursor over the past seven months. Check the root directory for unexpected executables, particularly git.exe, python.exe, or other common tool names.


    2. Rotate credentials: Assume your SSH keys, GitHub/GitLab tokens, and API credentials may have been compromised. Rotate all secrets, review recent access logs, and monitor for unauthorized activity.


    3. Consider alternatives temporarily: Until a patch is released, consider switching to standard IDE + GitHub Copilot, VS Code, or JetBrains IDEs with Copilot integration as a lower-risk interim solution.


    4. Monitor endpoints: Ensure your EDR or antivirus actively monitors the Cursor installation directory and alerts on unexpected child processes.


    For Organizations


  • Policy update: Revise your secure development guidelines to restrict the use of unreleased or patched development tools until vendor security posture is verified
  • Endpoint hardening: Configure EDR to flag execution of unexpected binaries within development project directories
  • Network segmentation: Ensure developer machines have restricted network access to production systems, and require additional authentication for accessing sensitive resources

    • For Cursor and the Broader Security Community


  • Vendors must establish clear vulnerability response SLAs (e.g., patch within 30–60 days for critical flaws)
  • Bug bounty programs should have escalation paths and public commitment timelines
  • The security research community should feel empowered to disclose when coordinated disclosure breaks down

    • ## HackWire Analysis


    This vulnerability is a harbinger of a broader challenge in modern software security: the assumption that developer machines are trustworthy. As development becomes more collaborative, remote, and dependent on third-party tools and repositories, the distinction between "trusted" and "untrusted" code boundaries has blurred dangerously.


    What makes this story particularly damaging isn't the flaw itself—it's Cursor's non-response. Seven months of silence after a confirmed, reproducible code execution vulnerability represents a failure of vendor accountability. When a security firm reports a critical flaw, confirms coordination, and receives no patch—no timeline, no acknowledgment beyond basic triage—the only reasonable conclusion is that user security is not the priority.


    The timing is also instructive. As AI-assisted development tools rapidly gain adoption and become central to developer workflows, this vulnerability reveals a critical gap: many of these newer vendors haven't yet internalized the security obligations that come with controlling execution on developer machines. They're building products at startup velocity while operating at enterprise risk.


    For defenders, this serves as a wake-up call to audit *all* development tools—not just source code—for similar path-resolution and auto-execution flaws. The techniques Mindgard identified in Cursor likely exist in competing tools, waiting discovery. The fact that Cursor's CISO acknowledged the HackerOne submission but took no action afterward is the real scandal here; it shows that even vendor security leadership doesn't guarantee response.


    Until Cursor releases a patch and confirms deployment at scale, developers should treat any Cursor-opened repository as potentially compromised. That's not paranoia—that's the appropriate risk posture when a billion-user-scale tool leaves code execution unpatched for half a year.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)