71–80 of 222 posts
I think this is slightly less of a Cursor bug than a bit of a Windows quirk: Windows searches the current working directory for executables before resorting to the path variable. I imagine a lot of stuff is vulnerable to such an "attack" on Windows.
I'm not sure I fully agree with this being a major vuln. There's a lot of up front scary text which was raising a lot of red flags until it actually discussed the "what". An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place. I see this akin to something like saying "replacing their .bashrc with an alias that says `ls` instead executes `/tmp/mega-big-virus.sh` is a vu…
I'm not sure I fully agree with this being a major vuln. There's a lot of up front scary text which was raising a lot of red flags until it actually discussed the "what". An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place. I see this akin to something like saying "replacing their .bashrc with an alias that says `ls` instead executes `/tmp/mega-big-virus.sh` is a vu…
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.
> The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ new versions later, the issue remains present in the latest tested version of Cursor. > The report was initially closed as Informative and out of scope. After we challenged that determination, HackerOne reopened the report, reproduced the issue, and confirmed t…
> The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ new versions later, the issue remains present in the latest tested version of Cursor. > The report was initially closed as Informative and out of scope. After we challenged that determination, HackerOne reopened the report, reproduced the issue, and confirmed t…
[flagged]
I'm not sure I fully agree with this being a major vuln. There's a lot of up front scary text which was raising a lot of red flags until it actually discussed the "what". An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place. I see this akin to something like saying "replacing their .bashrc with an alias that says `ls` instead executes `/tmp/mega-big-virus.sh` is a vu…
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.
Earlier quoted context omitted.
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.
I'd say checking out a malicious branch is in the same category as downloading a malicious attachment. By which I mean, it's kinda on you.
Earlier quoted context omitted.
I'd say checking out a malicious branch is in the same category as downloading a malicious attachment. By which I mean, it's kinda on you.
Downloading this attachement doesn't executes it. Checking out a branch in this case executes the file in the branch. Thats a big difference.
> The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ new versions later, the issue remains present in the latest tested version of Cursor. > The report was initially closed as Informative and out of scope. After we challenged that determination, HackerOne reopened the report, reproduced the issue, and confirmed t…
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?
https://www.reddit.com/r/programming/comments/zes1co/visual_... (2022)
I'm not sure I fully agree with this being a major vuln. There's a lot of up front scary text which was raising a lot of red flags until it actually discussed the "what". An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place. I see this akin to something like saying "replacing their .bashrc with an alias that says `ls` instead executes `/tmp/mega-big-virus.sh` is a vu…