Hacker News Reader

Comment by jjcm | Hacker News Reader

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 vuln".

Yes it's a vector, but if they've placed something in your filesystem like that already, you've already been compromised.

View on HN

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’ve never got my head around how it’s apparently the done thing these days to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. I somewhat naively hope that this is because everyone is pushing single purpose VMs for that kind of install, but really I know better.

> to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software.

how is that different from the good old days of

    wget ftp://ftp.something.org/software-2.10.tar.gz
    tar zxfv 
    ./configure
    make
    sudo make install

?

Training people (esp. what passes for non-techies on Linux) to regularly copy-paste into the terminal is massively riskier than "click this URL". Just for starters, consider how easily you can make a web-page where you highlight X to copy it, but instead Y is delivered to your clipboard. Then on execute it could even redraw the terminal to pretend you pasted X all along.

Also, there's a convention or social-contract that everyone who downloads 2.10 ought to get precisely the same thing. This provides a foundation for other facets of security, like "it must have an expected hash" or "it must validate as signed by this public key". Also investigative actions like discovering when something suspicious got added, or detecting that the installer is trying to access the internet when it really shouldn't be.

> Then on execute it could even redraw the terminal to pretend you pasted X all along.

Diabolical idea. Anyone know if there's been anything in the wild that did this?

Agreed, don't train fellow human beings (users) to follow, educate them.

"Make things as simple as possible, but no simpler." - commonly known quote.

We're making things so simple, the users don't get to have a proper chance at learning what's happening. Training people away from giving programs access, makes it opaque and dangerous. Unfortunately at the same time for non technology inclined users even Windows approach of file->Properties->Security visual UI proves challenging.

They’re both executing unknown code, but hopefully the ftp site here is at least a trusted one, and if you feel paranoid you can verify the archive’s hash to help verify it hasn’t been monkeyed with.

Also the archive probably won’t go and fetch a bunch of other scripts and run them (probably…) while doing so is usually the script’s primary purpose. So you’re not just trusting the people who published the script, at the time they published it. You’re trusting them and everyone they trust to still be good actors now.

That’s different to it being the standard way to install self-published bundles of scripts from all over the internet.

Not much, and people also should not to do this. One should at least have a check of hash of the download vs some document signed with a key.

In any case, the curl|bash from a website is way worse as it leaves no trace. Here, you have an artifact, and multiple steps, so the probability that an issue can be detected is higher and when someone gets compromises one has a change to figure out what happened and warn others. (so good practice to copy the file somewhere else). People look at this only from purely "can I get compromised" perspective, but overlook this community aspect.

How is it different from downloading and running the application itself from that website?

The illusion of security.

The entire point of Cursor is to run autonomous coding agents. You are giving it a random untrusted repo, saying "hey it might have a virus, go crazy" and then getting mad that it caused harm?

Check (and double check and triple check) your sources. If a malicious executable made it to your computer it is already too late.

? Doesn’t the code exec happen upon merely launching Cursor against a repository, without giving an agent any tasks? That’s clearly an issue at the Cursor application level, not some inevitable risk caused by the non-deterministic nature of LLMs. You can’t use the latter fact to excuse the former mistake

Not to mention that Cursor has an agent permissions model that this presumably sidesteps!

I agree cursor can fix the issue, but the main issue is downloading anything from untrusted source. The repo may have AGENTS.md which can tell please install npm package from random repo and run pnpm start etc...

We should never ever download any pdf or excel macros etc.. from untrusted source.

If you can’t download anything safely, the web can’t exist.

If we take your logic to the extreme, then there are never any legitimate code execution vulnerabilities in web browsers since the user is not supposed to visit untrusted websites.

Correct, we shouldn't visit untrusted website unless it is from trusted source like banks etc.. There is reason why scamming is billion dollar industry.

Cursor is used for vibe coding. There are people who used Cursor to build a webapp where passwords are printed on the front page

So yeah, this is a major issue

Different layers, different risks.

You do not expect an agent-level app to run untrusted binaries. You expect prompt injection, etc.

And I don't at all agree that a malicious executable landing in some directory is already game over. Plenty of zip files have malicious executables, it doesn't mean you say "oh, my zip extractor should just run every executable because if one's bad I'm already toast".

Ok, so you download the repo, launch Cursor, it compiles code and run it (if not, why do you even use Cursor at the first place?). Same effect.

These days I run absolutely everything dev related inside of podman containers, no node or anything on my host. But even that's not enough, because the IDE support for that is lacking and those tools expect host binaries to be available. I can largely get around it with ro mounts and such but it's very annoying.

Containers are really good now, there's zero reason why every extension and LSP isn't containerized.

Also agents inside a container. It's very nice because I have zero trust for harness permission systems. But again, why aren't the tools designed from the ground up to be containerized?

The very first paragraph of text presented to the reader on the page start with:

    After loading a project, Cursor attempts to find git binaries
    at various locations including the current workspace.
    By creating a repository with a planted malicious git.exe
    in the root, the IDE will execute it with no user interaction
    and no prompting of the user.

This is a remarkably straightforward 2 sentence explanation of the issue (the "what"). They're not exactly hiding it.

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.

I clone some repo from github, open it with default code editor which happens to be Cursor. I am cooked. That is it.

It is the same as autorun.exe on some CD - I put some CD in my CD-ROM and my Windows are compromised.

You can argue that I should not clone unknown repos, I should inspect each and any file in the repo, look for git.exe or any other suspicious binary and etc. I should not put untrusted CDs or USB sticks into my computer.

However the reality of it is that it will not be the user who inspects USB stick in some contained environment, it will be security policy which disables autorun. Same as Cursor should disable this.

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).

It’s Windows autorun all over again. What was old is new again.

It is a very obvious thing in UNIX world. This should not happen, no matter if it's Cursor or VIM or whatever program you are using. So, yes, it is a serious issue, and it's more of a Windows fuckup than Cursor itself. It's basic OS behaviour that's been fixed in UNIX for decades. You want to run a program in the current folder, you write ./program, everyone know this.

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

That's not what's happening.

Using AI tool over that repo does, but you have to launch it before the AV kicks in.

Only if you think opening Cursor.app counts as “using an AI tool”. Most reasonable people wouldn’t expect an AI-enabled text editor to hack their machine right away -- it should have the common decency to wait until you type something into the AI agent panel, then hack you!

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

That is a very recent addition. The exact behavior they are describing was in VS Code for almost a decade.

Trusted locations were added to VSCode in 2021.

https://code.visualstudio.com/updates/v1_57

And VS Code was released in 2015.

And this is 2026

I think many people gets tired so much they will simply trust all the 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.

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.

In this case, if you just run a git command yourself it executes the file as well.

On windows I guess?

On Linux and MacOS you'd need to run ./git to execute a malicious binary in the cloned repo.

Okay... but when "you" is a junior engineer on your team and now you are suddenly spending your entire weekend dealing with malware, it's kinda on you as well.

People are offloading a lot of responsibilities to tools. If you pull a repository from Github without doing due diligence then you can't blame Cursor for getting compromised

What’s due diligence? Reading all the code on GitHub?

That’s not a great interface, you probably want to clone it and open in your IDE so you can inspect the code properly...

So I clone a repo from Github and try to do due diligence before compiling and executing the code. I open the project with my IDE/text editor, and boom, I get pwned while doing the due diligence.

Unless it's Cursor's stance that people should use Emacs or whatever to check the repo before opening it, this is "you're holding it wrong" level stupid gaslighting.

Bro thinks cloning a repo means you're already compromised

I agree, this isn't a vulnerability at all. Now that it's public, I'm not even sure I would do anything about it if I were them.

You think opening a git repo I just cloned should execute code in that repo?

Maybe powershell shouldn't include the current directory in the PATH.

Reply on news.ycombinator.com