Following Mindgard’s disclosure of the Windows git.exe auto-execution issue (untrusted search path, CWE-426/427, where a malicious git.exe at the workspace root gets auto-executed), press outlets reported a Cursor spokesperson saying the issue was “addressed on July 13, 2026.” But there’s still no public advisory, CVE, or changelog entry on Cursor’s own site tying this to a specific fixed version.
For teams that need continued use of Cursor signed off by internal security, that gap matters a lot. Right now the only citable source is third-party press coverage, which most security reviews won’t accept as a substitute for a vendor statement.
Two asks:
Could Cursor publish something official and linkable for this issue: a security advisory, a changelog entry naming the version, or a tracked GitHub issue?
More broadly, is there a standing place (advisory page, security.txt-linked feed, GitHub Security Advisories) where fixes like this get published going forward? Knowing that exists, even if a given issue turns out low severity, would save a lot of us from finding out about vulnerabilities via news articles instead of the vendor, and would make it much easier to keep Cursor approved internally without re-litigating trust every time.
For context, our security team paused Cursor usage internally when this disclosure surfaced, since the coverage made it sound unresolved and there was no vendor statement to check against. I went looking for something official to confirm the fix and came up empty. The seven month gap between initial report and public disclosure, plus the lack of any public advisory after the fix, made it hard to bring back a clear answer to the people who need to sign off on continued use. We would rather keep using Cursor than switch tools, but right now the burden of proof is entirely on us to piece together from press articles instead of something Cursor put out itself.
Hi Colin, thanks for the quick response and the helpful link.
One thing I want to make sure I understand correctly before I bring this back to our security team: is the underlying git.exe resolution behavior itself unchanged, with Workspace Trust being the intended control, or did something also change in how Cursor resolves git binaries independent of Workspace Trust?
The reason I ask is that press coverage included a quote attributed to Cursor saying the issue was “addressed on July 13, 2026,” which reads like a code level fix rather than a policy level mitigation. Our own internal testing on a recent build suggests the planted git.exe in a workspace root is no longer executed even without Workspace Trust enabled, which would be a separate thing from the shared responsibility framing above.
If there was a change to the resolution logic itself, even without a formal advisory or CVE, it would help a lot to have that confirmed here so we have one consistent answer rather than two things that sound like they could be in tension. If Workspace Trust is the sole intended mitigation and nothing changed underneath it, that is also useful to know clearly, since it changes what we would recommend enforcing on our end.
Separately, since this statement is posted under Announcements, can I take that as the standard place Cursor will post going forward when something like this comes up, ideally close to when it’s first reported rather than after press coverage prompts it? Having a reliable answer to that helps us a lot on our end, since it means we can point our security team to a known channel to watch instead of relying on news articles to learn about issues.