Earlier this week, a potential vulnerability was disclosed in Cursor, the AI-enabled development platform that is a fork of VSCode. This vulnerability is a file called git.exe in the root of a repo or any project folder will be automatically executed without user interaction. That was viewed as a potential flaw in the software, but apparently Cursor was told about it in December and has really had no response at all to it.
Fast forward to today, when IFIN discovered that that vulnerability isn’t in Cursor. It’s actually in VSCode itself. Let’s walk through an example.
Example Case
First, for safety’s sake, I copied calc.exe, renamed it git.exe, and dropped it in a private repo that I have for testing.
Then I opened VS Code and selected the open workspace from the folder option after I had pulled the repo to my local machine. calc.exe was indeed executed.
As it turns out, this is behavior by design in Windows, and likely neither Cursor nor Microsoft views this as an actionable vulnerability. There are parts of pipelines that probably require this functionality, but it clearly can be used very easily to trick developers into running malware on local machines. VSCode does warn you not to open untrusted repos, but how many people just click through that? I know I have.
Remediation options
As far as options on remediation, it’s very clear that at the corporate level you can’t prevent git.exe from running on Windows workstations. However, you can probably put in rules to prevent it from being run from unexpected file paths, and that is the best you’re going to be able to do right now. If you’ve got better ideas, please drop them in the comments because I think this is a discussion topic worth going over. I see this as potentially something that could be used for a real attack.
I’d be curious, how is your VSC configured/what additional plugins are you running? I seem to recall some plugins causing similar behaviour in the past & I am currently unable to reproduce it with a clean VSC (even with trusted folders).
Maybe taking one step back & quickly talking about the original Cursor vulnerability: By the looks of it the Cursor one may be limited to a specific git command & not a general thing.
Folder in C:\Downloads/gittest with copied calc.exe to git.exe
User with local admin
1. Clean VM, new VSC from code.visualstudio.com/Cursor from Download
VS Code
No calc upon opening the folder, nor upon entering Trusted mode. in VSC. clicking the source control icon does nothing either. I note a prompt to “Download Git for Windows.”
Internal logs are consistent with this timing. Indeed, through all visible logs, the only logged events concurrent with popping calc are GitHub authentication.
And even signing out doesn’t stop it. Now, what about Cursor? If I sign in to GitHub through Cursor (no idea how this even works), will I pop Calc?
As I was writing this, @wdormann, who does have an account here discovered that the actual trigger is Copilot Chat’s “Enable AI Features” setting.
I have reproduced this finding, with additional details.
Clicking on this button will trigger the GitHub auth pipeline, which will also kick off the local git.exe.
At long last, I also got Cursor to pop! Just had to wait 10 minutes from launch.
Interestingly, after calc popped. the “GitHub Authentication” log which correlated with the VS Code entries is also present in Cursor. It wasn’t before.
So while the “AI Features” seem to be where the code lives, I have a strong suspicion that the mechanism is also related to getting GitHub sessions.
I’m reasonably confident the culprit is here:
In which, if Git is not found in some expected places, git.exe is executed locally.
discovered that the actual trigger is Copilot Chat’s “Enable AI Features” setting.