It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months.
But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, unsigned app for the first time.
You'll have to have ACL disabled completely for this to be exploitable.
ajhenrydev 59 minutes ago [-]
This report reads a bit like AI writing :/
You need to have an already malicious payload on your pc to make this exploit work (via clone/download/magic). I can understand the severity of the exploit but at the same time I’d hope to not have to run into this situation for it to happen in the first place
gene91 48 minutes ago [-]
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.
AntonyGarand 57 minutes ago [-]
The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised
JMKH42 57 minutes ago [-]
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.
skeledrew 4 minutes ago [-]
From my reading, boom happens at "open up cursor".
Illniyar 8 minutes ago [-]
you would only need to open it to be exploited, not edit or prompt. Allegedly
pixl97 53 minutes ago [-]
>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.
trollbridge 52 minutes ago [-]
This has been a problem with agent harnesses for as long as I've used them - prompting them to retrieve something often results in them going the extra mile and running and installing it.
19 minutes ago [-]
minraws 31 minutes ago [-]
Why is cursor subsequently executing anything? Like what is this black magic they want to do? I want to know the decision tree here? Was this cursor coded?
I do not understand the point, btw vim has had similar issues with it executing stuff you might not expect by loading a file but it was obviously a vim feature with %{expr}. But why specifically git.exe , this seems like the most redundant bug cve which could have been trivially patched, who does this feature help exactly?
I am not really a user of cursor never used it for even a single day, but at this point I am curious why this exists...
SpicyLemonZest 19 minutes ago [-]
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).
aliasxneo 1 hours ago [-]
I'm struggling to understand the process that went into this "feature" existing. 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.
gruez 52 minutes ago [-]
>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.
drdexebtjl 41 minutes ago [-]
Windows doesn’t really have a default login shell like Unix.
Windows Terminal defaults to PowerShell which does not suffer from this issue.
conartist6 1 hours ago [-]
and ever since, this approach has been a critical pathway for some billion dollar business probably. hooray
pixl97 52 minutes ago [-]
I see you also work in enterprise software.
chrisjj 4 minutes ago [-]
[delayed]
nosefrog 60 minutes ago [-]
Would be nice if the timeline matched up with the text of the blog post (missing "HackerOne provides disclosure guidance").
chrisjj 9 minutes ago [-]
[delayed]
nubg 1 hours ago [-]
> Most coordinated disclosures follow a familiar pattern:
> 1. A vulnerability is reported.
> 2. A dialogue begins.
> 3. Severity is discussed.
> 4. Engineering teams investigate.
> 5. Fixes are developed.
> 6. Users are protected.
> 7. Public disclosure follows.
8. The author prompts an LLM to write a blog post.
9. HN users are wasting time, unsure which parts of the post come from the actual prompt, and which are hallucinated world knowledge slop.
mike_hock 21 minutes ago [-]
Maybe the bug report got ignored because they posted another 1000 slop reports, who knows.
skeledrew 7 minutes ago [-]
Wonder who's fault it is when a critical security issue goes unresolved because "slop" report (sure ain't the reporters').
dakolli 8 minutes ago [-]
The disclosure seems pretty straight-forward, definitely some LLM assisted writing here, but not nearly as bad as most of the other stuff on this site.
DaWe01 1 hours ago [-]
[flagged]
sieabahlpark 1 hours ago [-]
[dead]
Rendered at 20:59:35 GMT+0000 (Coordinated Universal Time) with Vercel.
But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, unsigned app for the first time.
You'll have to have ACL disabled completely for this to be exploitable.
You need to have an already malicious payload on your pc to make this exploit work (via clone/download/magic). I can understand the severity of the exploit but at the same time I’d hope to not have to run into this situation for it to happen in the first place
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.
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 do not understand the point, btw vim has had similar issues with it executing stuff you might not expect by loading a file but it was obviously a vim feature with %{expr}. But why specifically git.exe , this seems like the most redundant bug cve which could have been trivially patched, who does this feature help exactly?
I am not really a user of cursor never used it for even a single day, but at this point I am curious why this 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.
Windows Terminal defaults to PowerShell which does not suffer from this issue.
> 1. A vulnerability is reported.
> 2. A dialogue begins.
> 3. Severity is discussed.
> 4. Engineering teams investigate.
> 5. Fixes are developed.
> 6. Users are protected.
> 7. Public disclosure follows.
8. The author prompts an LLM to write a blog post.
9. HN users are wasting time, unsure which parts of the post come from the actual prompt, and which are hallucinated world knowledge slop.