Threat
CVE-2026-63093: Cursor for Windows RCE Vulnerability
Publication date unknown · Discovered sentinelone.com
Page published · Page updated
Publication date unknown · First observed: 20 Oct 2026
Coverage timeline
Single-source analysis — one report is available.
Why it matters
CVE-2026-63093 can turn opening an untrusted repository in Cursor into code execution with the developer’s privileges, putting source code, credentials, and signing keys at risk.
CVE-2026-63093 allows an attacker-controlled git.exe in a repository root to execute automatically when the repository is opened in Cursor for Windows, with repeated execution during subsequent polling. The linked vulnerability entry identifies version 3.2.16 as affected, while the accompanying Cursor security profile reports a July 2026 patch.
Summary
CVE-2026-63093 is a binary-planting arbitrary-code-execution vulnerability in Cursor for Windows, with version 3.2.16 explicitly identified as affected. An attacker-controlled repository can contain a malicious git.exe at its root. When a developer opens that workspace, Cursor automatically executes the planted binary without further prompts or clicks. The aggregator reports a CVSS score of 8.8, High. Opening the repository remains a required user action; the evidence does not describe execution without that initial step.[0][14]
SentinelOne attributes the flaw to an untrusted executable search path, classified as CWE-426. Cursor resolves Git from the workspace before trusted installation locations and invokes the selected executable without validating its origin, signature, or location. The malicious binary runs with the current user's privileges during startup and again on a recurring timed cadence. This creates potential exposure of developer-accessible code, credentials, and signing material, but those consequences are assessed risks rather than documented theft in the supplied evidence.[14]
Remediation status is less precise than the technical description. The aggregator reports a quiet patch on July 13, 2026 and Mindgard's full disclosure the following day. SentinelOne's July 24 entry identifies the affected build and lists an NVD publication date of July 17, but the supplied texts provide no fixed-build identifier or complete vulnerable-version range. Defenders should therefore distinguish the reported patch date from verified remediation of a particular installed build. Neither supplied source establishes an in-the-wild campaign or a confirmed compromise attributable to this vulnerability.[0][14]
Attack chain
- Repository preparation — documented exploit scenario: An attacker controls repository contents and places a malicious executable named git.exe at the project root. SentinelOne describes publishing such a repository for a target developer to clone and open; the supplied evidence does not identify an actual malicious repository or distribution campaign.[14]
- Workspace opening and automatic execution: The developer opens the crafted repository in the affected Cursor for Windows build. During IDE initialization, Cursor's Git resolution searches the workspace before trusted installation locations and selects the planted git.exe. Execution requires no additional approval after the workspace is opened and occurs in the current user's security context.[0][14]
- Recurring invocation: Cursor invokes git.exe again on its recurring polling interval, giving the planted executable additional execution opportunities. The evidence specifies a timed cadence but does not provide an interval or document subsequent attacker operations.[14]
Disclosure timeline
| Date | Event |
|---|---|
| 2025-12-15 | According to the aggregator's account of Mindgard's disclosure, the vulnerability was reported to Cursor's published security-reporting address.[0] |
| 2026-01-15 | The aggregator reports that Cursor's CISO acknowledged an automation failure in report handling and invited the researcher to the private HackerOne program.[0] |
| 2026-01-16 | The aggregator reports that the submission was closed as informative/out of scope. It says the report was subsequently reopened after reproduction, but does not give a separate reopening date.[0] |
| 2026-07-13 | The aggregator reports that Cursor quietly patched the vulnerability. The supplied evidence does not identify the fixed release or include a patch-specific vendor advisory.[0] |
| 2026-07-14 | The aggregator dates Mindgard's full disclosure to this day, following a reported disclosure-handling period of approximately seven months.[0] |
| 2026-07-17 | SentinelOne lists this as the CVE's NVD publication date and last-update date. These are dates reported by SentinelOne; an NVD source body was not supplied.[14] |
| 2026-07-24 | SentinelOne published its vulnerability-database article describing binary planting in Cursor for Windows 3.2.16, the untrusted search-path root cause, and recurring execution behavior.[14] |
How it works
The executable-selection boundary is the root cause. Cursor invokes Git for source-control operations in an opened workspace, but its resolution process includes the workspace root before trusted system locations. A repository author can therefore supply an executable with the expected name, git.exe, and have it selected instead of the legitimate Git installation. SentinelOne classifies this behavior as CWE-426, Untrusted Search Path.[14]
The repository's contents become executable input to the IDE without a further consent boundary. SentinelOne states that Cursor does not validate the resolved binary's origin, signature, or location before invocation. Both supplied accounts describe execution upon project opening without additional prompts. The attack consequently depends on opening an attacker-controlled workspace, not on the developer deliberately launching the planted executable.[0][14]
Execution is not limited to a single startup event. SentinelOne describes invocation during IDE initialization and subsequent invocation on a recurring timed schedule. That behavior provides repeated opportunities to run the planted binary; it does not, by itself, establish installation of a separate persistence mechanism.[14]
The payload inherits the current user's privileges. The supplied technical account does not describe privilege escalation beyond that context. It assesses consequences across confidentiality, integrity, and availability and highlights the sensitivity of source code, cloud credentials, and signing keys commonly accessible on developer workstations. Wider software-supply-chain access is a potential consequence, not a documented outcome in these sources.[14]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| Cursor for Windows | Version 3.2.16 is explicitly identified as vulnerable. The supplied evidence does not establish a complete affected-version range or support extending the finding to other operating systems. | The aggregator reports a quiet fix on July 13, 2026. Neither supplied text identifies the fixed build, so the patch date alone cannot establish whether a particular installed version is remediated.[0][14] |
Key takeaways
- For the documented vulnerable build, opening an untrusted repository can cross an execution boundary before the developer intentionally runs project code. Repository contents must not be assumed passive merely because the user is only opening the workspace.[0][14]
- The useful detection characteristic is a repository-root git.exe executed by Cursor, potentially repeatedly—not the Git executable name in isolation. The supplied evidence contains no attacker-specific hashes, domains, or other campaign indicators.[14]
- Keep vulnerability disclosure, potential impact, and observed compromise separate. The evidence explains an arbitrary-code-execution mechanism and reports a patch date, but does not establish exploitation in the wild or identify a fixed release.[0][14]
Defensive actions
- Confirm the vendor-identified fixed Windows release and deploy that build before recording affected installations as remediated.: Version 3.2.16 is explicitly identified as affected, while the reported July 13 patch is not tied to a fixed-build identifier in the supplied evidence. Release-specific confirmation is needed to turn the reported patch status into an actionable fleet decision.[0][14]
- Until remediation is verified, avoid opening untrusted repositories in the affected Cursor for Windows build.: The documented trigger is opening an attacker-controlled workspace containing a repository-root git.exe. No additional prompt or deliberate execution of that file is required after opening.[0][14]
- Apply Windows application-control rules, such as AppLocker, to prevent execution of untrusted repository-resident executables, particularly a planted git.exe.: The aggregator specifically recommends treating cloned repositories as executable content and using AppLocker rules. The technical account identifies execution of the repository-root binary as the exploitation mechanism.[0][14]
- Review process telemetry for Cursor-associated execution of git.exe from repository roots, including launches at workspace startup and repeated launches from the same workspace.: Repository-local execution, startup invocation, and recurring polling are the concrete behaviors described by SentinelOne. Use the executable's location and execution context as investigative pivots; the filename git.exe alone is not sufficient evidence of compromise.[14]
- When validating remediation, check that Cursor resolves Git to a trusted installation rather than accepting a workspace-root executable.: SentinelOne identifies workspace-first resolution and lack of binary-origin validation as the root cause. Validation should address that selection behavior rather than merely confirming that the IDE opens successfully.[14]