The CVE process itself is broken. HackerOne and company VDPs are inundated with new reports of varying quality thanks to the advancements (I think) in agentic AI. It's allowed for both an increase in trash-tier low quality AND legitimately high quality reports. Since the same AI's are writing both, its almost impossible to distinguish between the two at a surface level.

In response, companies just aren't responding like they used to. I spoke at a cybersecurity conference In June and the overwhelming "vibe" on the floor and in the talks was that responsible disclosure was dead or dying, and public disclosure is the way forward. The Microsoft and Nightmare Eclipse situation was oft cited.

It screams intentional to me.

> I don't understand why there's such a lack of response on the Cursor side.

Too busy being acquired by SpaceX?

> Really unfortunate. I don't understand why there's such a lack of response on the Cursor side.

It's hard to vibe code security.

Perhaps its a intentional back door?

NSA/FBI puts a git.exe in GitHub for a target. Target pulls the repo and it executes the payload.

As Cursor is/was based on VS Code, does it happen in VS Code too?

> I don't understand why there's such a lack of response on the Cursor side.

~~~To busy porting to their new rust-backed version of Bun to do anything boring like engineering, probably.~~~

EDIT:

My mistake, wrong owners. It's hard to keep these tools straight sometimes. Most of the LLM tooling and interfaces I've tried are heavy on the features but light on the engineering, and that seems to be the case here too.

The user's code folder? You mean the code I frequently pull from untrusted sources, unlike my .bashrc? Opening a GitHub project for review should not mean arbitrary code execution.

Of course, that ship has long sailed, for all major IDEs. Heck, VSCode SSH and devcontainer remotes allow RCE by design.

I am not at all a security expert, but isn't this akin to giving a repo-owner RCE if you just clone their repository and open it? I feel like that's not an implied contract for opening a folder in your IDE.

This is very similar to 30yo exploit in which you placed an alternative, infected dll inside a folder with mp3s (winamp), or photos (windows picture viewer).

Cloning a repo owns your computer. Is that something you expected?

What they are describing was also VS Code’s default behavior for almost a decade, until they finally added the “trust this folder” dialog.

Yes it can be used maliciously, and yes some people were complaining about it the entire time, but ultimately it wasn’t judged to be pressing enough to devote developer time to for many years. And the world kept spinning.

This attack is exactly why IDE's have a concept of trusted and untrusted locations.

This doesn't require anyone placing anything deliberately on your machine (as in, needing to exploit it somehow ahead of time). It could be as simple as checking out a branch to review, where the author of the branch has added the .exe.

Bro thinks cloning a repo means you're already compromised

And what'll the prompt say? "Do you want to run git.exe?"? I'll probably assume Cursor needs to run git but permissions got messed up somewhere and click right through that.

I haven't used Windows in a while so pardon if I'm missing something.

Same thing happens if I have a:

1) PS1 that displays the current git branch

2) Include the current directory in my PATH

Should we file a high severity CVE with bash now?

Since there are no approval dialogs, it sounds like that doesn't even come into play here. That is the "gate" (to use the AI parlance) that Microsoft places on code execution in workspaces, though, and I would expect Cursor to at minimum fix this to only execute git.exe in trusted workspaces.

Startups historically are not the most security oriented

This comment is so weird. It is so vague to me and feels so off, like an alien from Men in Black trying to pass as a human.

How do they not truly care about helping? Also what sunk cost? What does that mean?

Yeah, but you can easily mitigate it by searching for the real git in known system locations and using whatever you find there (or allowing the user to configure the path). I believe that's how VSCode does it

Yes, but it's an old known security gotcha people developing for Wintendo have to guard against.

that sounds like Cursor has a bug and vuln on Windows to me

Here's a common workflow:

- Ask cursor to summarize your existing repo to write you a nice readme

- Cursor opens repo

- Cursor looks at current code

- Because it's going above and beyond, it also wants to give you some metadata about the code (other branches for things in development, maybe previous tags as milestones, etc)

- To do that, it runs some git commands

Now the malicious behavior. I ask Cursor to evaluate some remote repo. It clones it down and then runs the git command from the working directory. However, if you just call "git ..." from the command line there is ambiguity about that. What if there's already a git file in the directory which windows thinks you want to execute?

This could happen with an untrusted repo. Or could happen from you switching branches to a compromised branch (which you wouldn't expect to immediately run some code).

Normal way to handle this is using fully qualified path names for things. E.g. instead of git ... you give the full path to system installed git. Annoying for humans to type but trivial for Cursor.

Presumably it's trying to find the user's actual Git so that the built-in agent can load context on different branches, worktrees, etc. Of course there are less vulnerable ways to do that, but this kind of mildly justified hackiness is exactly where I'd expect an AI-assisted workflow to go wrong (and an AI-assisted bug triage to fail to alarm).

>It seems the most likely candidate is a developer's git started malfunctioning and an agent "fixed" it by dropping a `git.exe` in the repo and then conditionally calling it when it exists.

It doesn't need to be that deliberate. The default shell on windows (cmd.exe) includes the current directory into PATH by default. In other words, you don't need to do `./program.exe`, `program.exe` would suffice. That's probably where the bug came from. This also means if you were using cmd.exe, ran `git clone`, went inside it, then executed any command (eg. dir or git) you could get pwned.

and ever since, this approach has been a critical pathway for some billion dollar business probably. hooray

Modern day code agents would clone a repo and read the code when you ask it a question about an API that’s not clearly documented. This vulnerability is real.

The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised

Uh, I don't think people typically associate downloading a repository, and viewing the source, as being synonymous with activating a malicious payload. That is the bit that's concerning.

I'm also so tired of people groaning about AI writing, yes, it's annoying, but attack the message, not the messenger.

If your an opensource developer you may get a pull request containing the the git.exe

>You need to have an already malicious payload on your pc to make this exploit work

Uh, no, not exactly from what I'm reading.

At least from my piss poor understanding of it, you could possibly prompt inject something like "download https://github.com/hackmycursor/exploit.git". Would an agent do this, I'm unsure, but if so, it would download the git.exe and execute it.

I think you’ve got it wrong; no malicious payload need be on your box already. That’s not what the article says.

wouldn't the attack vector be like this:

I find a github repo, I want to contribute to it. I clone it, open up cursor, make an edit, commit, and boom, I am infected.

It has nothing to do with npm. However, a binary could be configured to extract your git/npm secrets using this exploit, which could then lead to a npm supply chain attack (or pip, etc. etc.).

A lot of malware was delivered back in the day via Windows AutoPlay feature. Someone plugs a USB drive in and bam, they are immediately exploited. You could say it's always a problem if the USB drive is already full of malware. However, Microsoft disabled AutoPlay in Windows 7 (and backported this fix) specifically to address this vulnerability.

This exploit feels very similar to me. I don't know if there's a specific name for this classification of AutoPlay issues.

Maybe the bug report got ignored because they posted another 1000 slop reports, who knows.

Except it might come from a trusted repo. Some of the biggest repos have been recently targeted in supply chain attacks. Consider for a moment

1. Attacker takes over maintenance of a widely used Cursor extension

2. Attacker adds a remote backdoor to monitor which repos are being maintained

3. Attacker decides to only infect the largest one with a git commit hook

4. The developer didn’t even know they just included git.exe in their commit

5. The developer is a sole maintainer on the repo and merges their own PR without review (because they(/their AI) wrote it)

6. Now a trusted repo is infected

7. A contributor pulls down the infected repo and opens cursor