Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution

A significant design vulnerability in the Cursor AI code editor on Windows allows a malicious or compromised Git repository to achieve code execution the moment a developer opens it — no interaction, no confirmation dialog, no warning. The flaw was disclosed publicly on July 15, 2026, and targets developers who use Cursor to work with open-source projects or cloned repositories.

The Vulnerability

When Cursor is opened with a repository directory on Windows, it implicitly invokes git.exe to read repository state (branch information, git history, staging area, etc.). The critical flaw: Cursor does not enforce that git.exe must come from the system PATH or a trusted location — it resolves the binary name in the current working directory first.

This means: if a malicious repository contains a file named git.exe in its root directory, Cursor will execute that file when the repository is opened. The malicious binary:

• Executes as the current user, with all their credentials and file system access
• Requires no user interaction — just opening the folder is sufficient
• Produces no visible warning in the Cursor UI
• Is not blocked by Windows SmartScreen in this execution context if the file appears to be a Git executable

The researcher who discovered this described the attack path as "horrifyingly simple" — a single 64-byte Windows executable named git.exe dropped in the repo root is enough to compromise a developer's machine.

What an Attacker Can Steal in Seconds

When Cursor auto-executes a malicious git.exe, an attacker gains immediate access to everything the developer has access to:

A well-crafted payload could silently exfiltrate this data to an attacker-controlled endpoint in under a second — before the developer even sees the repository contents in the editor.

Attack Scenarios

Scenario 1: Malicious Open-Source Repository

An attacker creates or compromises an open-source package on GitHub, NPM, or PyPI and adds a git.exe to the repository root. When a developer clones the repo and opens it in Cursor on Windows, code executes immediately.

Scenario 2: Supply Chain Attack via Fork

An attacker forks a popular legitimate open-source project, adds the git.exe payload, and creates a pull request. Maintainers reviewing the PR locally in Cursor trigger execution.

Scenario 3: Social Engineering

An attacker sends a developer a link to a "public repository" or shares a zip archive of a "project" with the git.exe embedded. Opening in Cursor triggers the payload.

Scenario 4: CI/CD Pipeline Attack

CI/CD systems that clone repositories and run Cursor-based tooling (e.g., automated code review, IDE-based linting) on Windows agents could be targeted to compromise build infrastructure credentials.

Historical Context: Similar Path Hijacking Issues

This class of vulnerability — current-directory binary hijacking — has a long history on Windows, predating modern development tools. The Windows DLL search order and executable resolution order have historically resolved binaries from the current working directory before the system PATH, leading to numerous privilege escalation vulnerabilities over the years.

What makes this particularly concerning in the context of AI-powered code editors like Cursor:

• Developers actively clone untrusted code — the core workflow of open-source development
• AI editors operate with broad permissions — they read, index, and analyze entire directory trees on open
• Trust is implicit — developers expect their editor to be safe to use with any repository

Similar issues have been identified in other developer tools, though the specific Cursor behavior appears to be a distinct code path.

Mitigation

For Developers (Immediate)

1. Update Cursor — check for a patched version; Cursor's team was notified and a fix is expected imminently
2. Avoid opening untrusted repositories in Cursor on Windows until a patch is confirmed
3. Inspect repositories before opening: dir /b git.exe or ls git.exe in the repository root before loading in any editor
4. Use a sandboxed environment for evaluating untrusted code (VM, container, or Windows Sandbox)

For Cursor Users Generally

# Quick check before opening any cloned repo in Cursor on Windows
# Run in the cloned repo directory:
Get-ChildItem -Name "git.exe" -Recurse | Select-Object -First 10
# If git.exe appears in any directory OTHER than C:\Program Files\Git\, investigate before opening

For Organizations

• Block untrusted repository access on developer workstations via endpoint policy where feasible
• Monitor for unexpected process spawning from Cursor's parent process tree
• Credential rotation policy: If developers may have opened untrusted repos in Cursor on Windows recently, consider rotating SSH keys, cloud credentials, and API tokens as a precaution

Why AI Code Editors Are High-Value Targets

Cursor, GitHub Copilot (VS Code), Windsurf, and other AI-powered editors have become central to developer workflows — they have deep integration with git, cloud providers, and CI/CD systems. A compromise of a developer's AI editor instance can yield:

• Complete source code access for all active projects
• Cloud credentials with production access
• Supply chain attack capability — the ability to commit malicious code to repositories the developer has push access to
• Pipeline secrets from .env files, docker-compose.yml, and CI configuration files

Developer workstations are increasingly recognized as among the highest-value targets in the attack surface for supply chain compromise. This Cursor vulnerability is a concrete example of why the attack surface of AI-integrated developer tools warrants serious scrutiny.

Source: The Hacker News