[Aperocky]

As someone who is on the other side, the amount of familiar, LLM generated reports are overwhelming and usually falls under "not familiar with product design/security scope" category. But there are also really good ones - so I can't afford to not take actual look at each, but it gets tiring and we need a solution. Spamming the former category with LLM generated "rationale" isn't that solution (yes I can tell this article is mostly LLM generated).

Unfortunately, this looks like the former case. If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software. Unless cursor commit themselves to securing the user environment, which I don't think they are in the business of.

If you are generating a CVE report with LLM, please use LLM responsibly in helping you reproduce deterministically. Then please do the write up yourself, keep it as concise as possible and strip most adjectives in any LLM generated sections as they cannot help themselves to write without mostly useless exaggerations.

[hack1312]

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

[romanovcode]

We're back to autorun.exe times

[username135]

Time is a flat circle it seems

[nicman23]

but it is just a agents.md file lol

[mort96]

This has nothing to do with any language model or agent, this is just traditional deterministic code in the Cursor program.

[himata4113]

Let me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP.

Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.

[DanielHB]

VSCode at least prompts you to trust the project folder before running anything, otherwise it will use a globally installed LSP.

[tjoff]

What repo-binary is executed for the LSP?

[hack1312]

There’s no trust system by default in Cursor because they ship that feature disabled.

https://cursor.com/docs/agent/security#workspace-trust

[andbartol]

Both jetbrains and vscode ask you if you trust the project

[nextweek2]

It isn't "a binary", it's git.exe (which has a very specific purpose). We are talking about an AI tool which wants to know the current state of the folder it is indexing, that's a reasonable thing for an AI to want to do.

You then take the default of Windows execution order of: look for the executable in the current folder otherwise check the PATHs in order. This is a Windows security issue which has been around since day one.

To me the App is preparing to do some work so it is more responsive to my requests. This is a classic trade off between security and performance, where the odds of a malicious virus being in the root of your project are very small if you are already taking best practices.

Perhaps what we really need is Microsoft to change the execution order and that the maintainers of Git add a new feature where we can block executables being in the root of a repo (or in the whole of a repo). That would prevent every app having to make the same workaround, fix the issue upstream and you'll never have to think about it again.

[mort96]

git.exe is just a name. Cursor has no reason what so ever to assume that a random binary in a random repo is a legitimate git binary just because its name happens to be git.exe.

[wongarsu]

The trivial fix is to execute not "git.exe" but "C:\Program Files\Git\bin\git.exe". With a configurable git binary

Of course that then leads you down the rabbit hole of whether the llm should exectute a known-good ripgrep, tree, etc. instead of depending on PATH resolution

[hughw]

> If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software.

What do you think PATH variables are for? Cursor just immediately adds the repo to your PATH, iiuc, without user approval.

[f311a]

> But there are also really good ones - so I can't afford to not take actual look at each, but it gets tiring and we need a solution.

There is not easy solution, the landscape has changed and if care about security, you just need to allocate more human resources. Another layer of LLM checks won't help.