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.
>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.
I doubt it. This is just normal Windows behavior. If you call out to a shell and have it run a
`git` command the system has to decide where the git binary is. A quirk of Windows is that first it searches the current directory for a `git` executable, and then it searches directories defined in PATH. If there's an executable git.exe in the current dir, that gets ran. I assume Cursor's behavior is the same across platforms but this is only a Windows vuln
because Windows picks binaries in the current directory before PATH.
A Windows
user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.
You need to have an already malicious payload on your pc to make this exploit work. 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
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.
Don't think that would trigger the bug, it needs to be at the repo root when the user opens the agent CLI, it's not like the agent is calling another agent CLI process with the new repo root as its project root.
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.
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...
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).
- 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.
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.
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.
It’s been known for decades that you should never put your current directory in your PATH. There are endless opportunities for vulnerabilities then. I learned this in college in the 80’s (by not following it and getting owned).
> cd C:\Temp
> copy "C:\Program Files\Git\bin\git.exe" .\fred.exe
> fred
fred: The term 'fred' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
All too common... It's sad yet understandable how a company would not prioritize security.
At the same time, it's also understandable how a security start-up, upon (rightly) getting fed up waiting, decide to publicly disclose, as a way to scrape some PR out of the sunk cost. Public disclosure has a place. But if you truly care about helping, you could do more than bumping on HackerOne and messaging the CISO once on LinkedIn.
Maybe I'm too cynical but it truly feels like nobody actually cares at this point.
Hah, not trying to pass off as human. Just communicating with my fellow men in black ;)
To be as explicit as possible: whether disclosing this publicly actually did more good then harm is not that clear cut. Even if accounting for all the second order effects.
Regardless, as a business you'd still be compelled to publish, because you've already poured resources into this research, there's still a chance to gain something, and there is enough plausible deniability about your true priorities.
We're in the worst of all worlds. Sometimes it feels like you only know it's a human because the AI would have over-explained.
But yeah, this security company only prodded, what, once or twice a month for 7 months? I mean, if they really truly cared, they would have found the CISO's home address, broken into their house, painted the reproduction steps on the inside of their front door (to avoid accidental disclosure), created a few "beginner friendly" repos with a git.exe that DDoS's their auth servers, got a job as a night cleaner in their offices, waited for one of the developers to leave their machine unlocked then fixed the vuln themselves.
It's just another capitalistic money grab, them posting their security concerns. Ugh.
This draws to mind the dialog that opens when you open a new project in Cursor (and VSCode too, I think), where the IDE asks the user if they trust the project they're opening. Is Cursor under the impression that this is sufficient security apparatus?
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.
Frankly, if you git clone a compromised repository, I'm not sure that a vulnerability of the class "compromised code in that repository will be executed" is all that major a concern. There are plenty of IDEs that will go autonomously run npm installs (with post-install scripts) for you when they detect a package.json. This isn't all that different than that.
They could throw up a warning like "do you trust this repository" oh wait they already do, and no one cares. Security is hard. Ultimately if you have compromised code on your machine, all bets are off.
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.
They should definitely fix it, but that's mostly because its an "unnecessary autoplay" so to speak. There's plenty of "necessary autoplays" out there, and AI is going to add more and more every day, because that's where productivity comes from. But, why Cursor would ever need to execute the git binary in your project directory is beyond me; very clearly a bug.
Their ignorance of the bug report is also very clear and concerning negligence.
But I think simultaneously, the security team is making a mountain out of a molehill. This is a classic thing security teams love doing; everything is military defcon P0. So, its important to check them regularly, and remind them that the most secure system is no system; they are but one part of a greater ecosystem.
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.
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 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.
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.
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).
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.
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!
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.
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.
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
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.
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.
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.
> 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 that the details had been delivered to Cursor. And then everything stopped. Requests for updates went unanswered, additional follow-ups received no response, escalation through HackerOne produced no meaningful engagement, and direct outreach to Cursor leadership yielded the same result: no response.
Really unfortunate. I don't understand why there's such a lack of response on the Cursor side.
Ideally, they’ll be able to look back through the logs and find the original analysis from when the bug was submitted, figure out why it was incorrectly filtered, and use that to improve their automation.
The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.
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.
As someone on the Blue Team side of the HackerOne brokenness, I can confirm that this effect is real but would also note that the difficulty of distinguishing is not as severe as all that, because the companies have access to the source code which the researchers do not typically have access to.
This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of producing a report in the first place. Automated triage systems should be possible, and realistically it's well within the capabilities of most companies to go further and actually automate the Red Team side of it and catch issues before they surface in the black box research. From what I've seen doing so should cost dramatically less in tokens than the bounty payouts do.
The problem is that security is woefully underfunded in most companies, so even an infosec organization that saw the deluge approaching from a distance may well not have had the resources to prep for it even if they knew exactly what actions they would take if they had them.
The token cost of a report is lower bounded by the number of tokens in the report * price per token of the cheapest model. The token cost of a good report is much higher, but sifting out the good reports is the entire problem.
In theory, yes, but are you actually seeing clearly-garbage lower-bound reports like this?
The ones we're seeing show clear evidence of being AI-generated, are often incorrect or duplicated, but they also show clear evidence of the AI having done its homework and spent a while crawling our API.
Even if we were getting reports at the lower bound you're describing, those would be even easier to triage: just add a quick step to check if the API in question even exists, then if it does that very cheap "where is this API" query becomes part of the input to the second-level triage that spends more tokens.
Should a company promoting the enterprise usability of AI, itself start with building a intake process to distinguish between the noise and signal for these reports. If you cant solve your own problems with your product then how do you expect the customers to be able to use it.
Not even that. Even before AI came along the widespread practice of CV-Enhancement was slowly strangling the reporting of actual legitimate, needs-to-be-fixed issues. When it turns into a giant shit-shovelling exercise it's not surprising that some of the shit doesn't get shovelled.
Not defending HackerOne, but pointing out that it's not a black-and-white issue.
Their CISO literally acknowledged it and then they all continued ignoring it again. This isn't just bad process, this is a broken security organization.
I think those are both different in that they require the user to say they trust this code. Additionally the first is arguably not a bug (the code in tasks.json will indeed run if you say you trust the project) and the second was reported and fixed within two months.
Yes, my point was more so the underlying behavior of automatic execution of binaries associated with/inside of a git project exists already within vscode as a pattern, and so seeing cursor doing the same wouldn't be surprising.
They aren't. This is a Windows quirk. Most IDE extensions which interface with git (or any other CLI program) from the CWD are "vulnerable" to the same attack.
This is why the upstream didn't take it seriously, this has been known for literal decades.
Clone a repo and run "npm install" and the exact same thing will happen. You can say "oh I would never run npm install on a repo I don't trust"...but then why are you cloning it and opening it in an IDE in the first place? Especially an IDE whose entire purpose is to run autonomous coding agents?
The difference is that I expect "npm install" to execute code, where I do not expect merely opening a repo to look at the files in Cursor to execute anything.
IDEs do syntax highlighting, typechecking, linting, automatic git refreshes. All of this happens in the background without you executing any code. If you open a Typescript project in VS Code and it automatically shows you a list of errors where do you think it got them from? It ran the tsc executable in your node_modules folder.
In most languages, none of those things involve execution of code in the repo. In languages that do - for example Elixir - it prompts you to trust them first.
Visual Studio Code asks you if you trust the files in the folder you open, or at least it always has done for me. Presumably this stuff stops working if you don't?
Cursor is an editor. Why is it executing untrusted code when a folder is opened? Opening a folder is not equivalent to executing a script contained in the repo. How can you think that is ok?
Waiting seven months to disclose this is seven months of exploitation opportunities across 7 million users. It is overly deferential to the publisher. Better if, lacking their engagement, the latency to this article was a few days.
But that's a quibble compared to the value of your service, thank you.
The reason you need AV on windows is because you are a granny who gets an "FBI" warning on a dodgy webpage and clicks the "pwn my shiz" button.
If you don't install trojans, you don't need AV. If you do install trojans, switching OS won't help.
I'm not sure which is the trojan in TFA - the mooted malicious git binary, or the agent. I can't imagine any sane person letting an agent near anything they care about. All your keys are belong to us.
I guess you fell into a coma before Heartbleed, so here's what you missed: desktop OS security became irrelevant when otherwise-sane people started installing npm and buying smart TVs. And, latterly, giving shells to actors that have no ethics and no consequences.
Crazy that 7 hours after this post there's no one from the Cursor team saying anything here. This is HN, your highest leverage audience, Anysphere... no one is home?
165 comments
[ 2.2 ms ] story [ 65.1 ms ] threadIt 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.
A Windows user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.
> 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.
You need to have an already malicious payload on your pc to make this exploit work. 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'm also so tired of people groaning about AI writing, yes, it's annoying, but attack the message, not the messenger.
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...
- 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.
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.
I haven't used Windows in a while so pardon if I'm missing something.
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?
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
Obvious answer is obvious. The devs do not consider it a bug.
At the same time, it's also understandable how a security start-up, upon (rightly) getting fed up waiting, decide to publicly disclose, as a way to scrape some PR out of the sunk cost. Public disclosure has a place. But if you truly care about helping, you could do more than bumping on HackerOne and messaging the CISO once on LinkedIn.
Maybe I'm too cynical but it truly feels like nobody actually cares at this point.
How do they not truly care about helping? Also what sunk cost? What does that mean?
To be as explicit as possible: whether disclosing this publicly actually did more good then harm is not that clear cut. Even if accounting for all the second order effects.
Regardless, as a business you'd still be compelled to publish, because you've already poured resources into this research, there's still a chance to gain something, and there is enough plausible deniability about your true priorities.
But yeah, this security company only prodded, what, once or twice a month for 7 months? I mean, if they really truly cared, they would have found the CISO's home address, broken into their house, painted the reproduction steps on the inside of their front door (to avoid accidental disclosure), created a few "beginner friendly" repos with a git.exe that DDoS's their auth servers, got a job as a night cleaner in their offices, waited for one of the developers to leave their machine unlocked then fixed the vuln themselves.
It's just another capitalistic money grab, them posting their security concerns. Ugh.
They ship it disabled.
https://cursor.com/docs/agent/security#workspace-trust
They could throw up a warning like "do you trust this repository" oh wait they already do, and no one cares. Security is hard. Ultimately if you have compromised code on your machine, all bets are off.
This exploit feels very similar to me. I don't know if there's a specific name for this classification of AutoPlay issues.
Their ignorance of the bug report is also very clear and concerning negligence.
But I think simultaneously, the security team is making a mountain out of a molehill. This is a classic thing security teams love doing; everything is military defcon P0. So, its important to check them regularly, and remind them that the most secure system is no system; they are but one part of a greater ecosystem.
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.
On Linux and MacOS you'd need to run ./git to execute a malicious binary in the cloned repo.
https://code.visualstudio.com/updates/v1_57
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.
Using AI tool over that repo does, but you have to launch it before the AV kicks in.
That’s not a great interface, you probably want to clone it and open in your IDE so you can inspect the code properly...
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.
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.
https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
> 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 that the details had been delivered to Cursor. And then everything stopped. Requests for updates went unanswered, additional follow-ups received no response, escalation through HackerOne produced no meaningful engagement, and direct outreach to Cursor leadership yielded the same result: no response.
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.
The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.
Conversely, running human or LLM-generated code through multiple LLMs to look for security holes is a fantastic way to increase security.
Too busy being acquired by SpaceX?
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.
This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of producing a report in the first place. Automated triage systems should be possible, and realistically it's well within the capabilities of most companies to go further and actually automate the Red Team side of it and catch issues before they surface in the black box research. From what I've seen doing so should cost dramatically less in tokens than the bounty payouts do.
The problem is that security is woefully underfunded in most companies, so even an infosec organization that saw the deluge approaching from a distance may well not have had the resources to prep for it even if they knew exactly what actions they would take if they had them.
The ones we're seeing show clear evidence of being AI-generated, are often incorrect or duplicated, but they also show clear evidence of the AI having done its homework and spent a while crawling our API.
Even if we were getting reports at the lower bound you're describing, those would be even easier to triage: just add a quick step to check if the API in question even exists, then if it does that very cheap "where is this API" query becomes part of the input to the second-level triage that spends more tokens.
Not defending HackerOne, but pointing out that it's not a black-and-white issue.
NSA/FBI puts a silent git.exe in GitHub for a target that the Github UI doesn't show. 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)
To busy porting to their new rust-backed version of Bun to do anything boring like engineering, probably.
Agents should be no different.
This is why the upstream didn't take it seriously, this has been known for literal decades.
- Use Windows
- Don't use WSL or any other abstraction, but build/run their code directly on Windows
- Routinely clone random untrusted repositories
is too small to matter. End of story.
In most languages, none of those things involve execution of code in the repo. In languages that do - for example Elixir - it prompts you to trust them first.
But that's a quibble compared to the value of your service, thank you.
Not an active Windows user, but I can't imagine any sane person working on Windows OS without malware protection.
If you don't install trojans, you don't need AV. If you do install trojans, switching OS won't help.
I'm not sure which is the trojan in TFA - the mooted malicious git binary, or the agent. I can't imagine any sane person letting an agent near anything they care about. All your keys are belong to us.
I guess you fell into a coma before Heartbleed, so here's what you missed: desktop OS security became irrelevant when otherwise-sane people started installing npm and buying smart TVs. And, latterly, giving shells to actors that have no ethics and no consequences.