5 ms·
Cursor 0day: When Full Disclosure Becomes the Only Protection Left
- DaWe01 2mo ago[flagged]
- sieabahlpark 2mo ago[dead]
- aliasxneo 2mo agoI'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.
- conartist6 2mo agoand ever since, this approach has been a critical pathway for some billion dollar business probably. hooray
- pixl97 2mo agoI see you also work in enterprise software.
- gruez 2mo 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 2mo agoWindows doesn’t really have a default login shell like Unix. Windows Terminal defaults to PowerShell which does not suffer from this issue.
- inigyou 2mo agoWindows has a default login shell which is explorer.exe. Windows also has a system(const char*) which certainly does something.
- varenc 2mo agoI 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.
- nubg 2mo 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 2mo agoMaybe the bug report got ignored because they posted another 1000 slop reports, who knows.
- dakolli 2mo agoThe 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.
- mike_hock 2mo agoYes, the question is whether it drowned in a myriad of other LLM "assisted" reports, because that would be a way in which a simple straightforward report could be missed.
- skeledrew 2mo agoWonder who's fault it is when a critical security issue goes unresolved because "slop" report (sure ain't the reporters').
- nosefrog 2mo agoWould be nice if the timeline matched up with the text of the blog post (missing "HackerOne provides disclosure guidance").
- ajhenrydev 2mo agoThis 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
- AntonyGarand 2mo agoThe malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised
- 4ndrewl 2mo agoIt's curious the number of people here who can't link these two things.
- dev_daftly 2mo agogit clone a repo, cd into the directory, git checkout ..., and you're compromised
- JMKH42 2mo agowouldn'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 2mo agoFrom my reading, boom happens at "open up cursor".
- Illniyar 2mo agoyou would only need to open it to be exploited, not edit or prompt. Allegedly
- dalemhurley 2mo ago
- minraws 2mo agoWhy 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 2mo agoPresumably 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).
- evolve-maz 2mo agoHere's a common workflow: - 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.
- Illniyar 2mo agoIt'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.
- shitter 2mo agoAnd 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.
- jofzar 2mo agoI'm not a windows developer or a ide developer, but I would check the hash against known good git.exe and then only run if it matches it.
- Illniyar 2mo agoOstensibly you've ran git before and never saw something like that, seeing a security warning on running git should raise some eyebrows.
- x3n0ph3n3 2mo agoSame thing happens if I have a: 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?
- jwolfe 2mo agoIf bash placed the current directory in your PATH by default, then yes.
- chrisjj 2mo ago> Until the IDE is patched, open untrusted repositories only in an isolated VM, Windows Sandbox, or other disposable environment. Got to wonder why trusted repositories are excluded...
- dalemhurley 2mo agoExcept it might come from a trusted repo. Some of the biggest repos have been recently targeted in supply chain attacks. Consider for a moment 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
- chrisjj 2mo ago> The most obvious question is also the simplest: Why hasn't this been fixed? Obvious answer is obvious. The devs do not consider it a bug.
- firer 2mo agoAll 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.
- orphereus 2mo agoThis comment is so weird. It is so vague to me and feels so off, like an alien from Men in Black trying to pass as a human. How do they not truly care about helping? Also what sunk cost? What does that mean?
- firer 2mo agoHah, 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.
- undecisive 2mo agoWe'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.
- dclowd9901 2mo agoThis 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?
- shitter 2mo agoSince 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.
- alansaber 2mo agoStartups historically are not the most security oriented
- hack1312 2mo agoCursor, being based on VSCode, does have the Workspace Trust feature. They ship it disabled. https://cursor.com/docs/agent/security#workspace-trust https://cursor.com/docs/agent/security#workspace-trust
- dclowd9901 2mo agoAh, guess I was conflating the two (they are quite similar after all). From their documentation (the link you posted): > For untrusted repos, use a basic text editor instead. Is that really our options here? How shitty.
- vanyaland 2mo agoDoes the git lookup run before the trust check, or ignore it?
- 827a 2mo agoFrankly, 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.
- beart 2mo agoA 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.
- 827a 2mo agoThey 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.
- awongh 2mo agoI guess this is only specific to a file in the root of the repo, so it doesn't allow for an NPM supply chain attack?
- beart 2mo agoIt has nothing to do with npm. However, a binary could be configured to extract your git/npm secrets using this exploit, which could then lead to a npm supply chain attack (or pip, etc. etc.).
- jjcm 2mo agoI'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.
- libeclipse 2mo agoBro thinks cloning a repo means you're already compromised
- shitter 2mo agoThe 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.
- taneq 2mo agoI’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.
- petalmind 2mo ago> 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 ?
- 2mo ago
- aniceperson 2mo agodamn those ai written Blogs are tiring. o a single paragraph saying that "cursor o windows loads ./git.exe with higher precedence" would be enough.
- bragr 2mo agoI 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.
- shitter 2mo agoYeah, but you can easily mitigate it by searching for the real git in known system locations and using whatever you find there (or allowing the user to configure the path). I believe that's how VSCode does it
- Chu4eeno 2mo agoYes, but it's an old known security gotcha people developing for Wintendo have to guard against.
- whateveracct 2mo agothat sounds like Cursor has a bug and vuln on Windows to me
- ncruces 2mo agoStuff that cares about security fixes this, though: https://go.dev/blog/path-security https://go.dev/blog/path-security The functions Command and LookPath look for a program in the directories listed in the current path, following the conventions of the host operating system. Operating systems have for decades included the current directory in this search, sometimes implicitly and sometimes configured explicitly that way by default. Modern practice is that including the current directory is usually unexpected and often leads to security problems. https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_directory https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
- deleted 2mo ago[deleted]
- wxw 2mo ago> 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.
- sofixa 2mo ago> 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.
- koolba 2mo agoIs it though? Cause you can have an agent analyze the reports to filter out the wheat from the chaff.
- thayne 2mo agoI suspect that is exactly what cursor did, and the agent (incorrectly) categorized this as chaff.
- iainmerrick 2mo agoIdeally, 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.
- hmokiguess 2mo agoThe 0 day vulnerability is actually a developer is using Windows
- imglorp 2mo agoThis is exactly why Unix PATH (and offspring) does not contain "." by default. If you unpack an untrusted archive and run "ls" you could get popped. Agents should be no different.
- nickelpro 2mo agoThey 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.
- deleted 2mo ago[deleted]
- paxys 2mo agoClone 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?
- AussieWog93 2mo agoThe 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.
- paxys 2mo agoIDEs 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.
- jeremyjh 2mo ago> syntax highlighting, typechecking, linting, automatic git refreshes 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.
- AussieWog93 2mo agoI'm a Python dev so don't do much typescript, this sounds crazy too!
- tom_ 2mo agoVisual 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?
- jeremyjh 2mo ago
- deleted 2mo ago[deleted]
- physix 2mo agoWouldn't this be something a virus scanner would detect and quarantine? Not an active Windows user, but I can't imagine any sane person working on Windows OS without malware protection.
- psd1 2mo agoThe 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.
- redwood 2mo agoCrazy 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?
- yieldcrv 2mo agoWhy do you guys write essays to justify doing the leak Have you all drunk too much psyop koolaid? Three things are obvious: 1 - “Responsible disclosure” by a unilaterally proscribed process only benefits an abuser 2 - The abuser sets a price for the disclosure that is arbitrary and parallel to its market value, the attractiveness is based solely on your vulnerability to how much the abuser can abuse you with the state 3 - The vulnerability’s continued existence isn't necessarily a breakdown of disclosure processes, it could literally be malice. congratulations you found the honeypot, it wont be confirmed by the state for 70 years
- dhosek 2mo agoIsn’t this a Windows flaw where it effectively treats the current directory as the head of the path? (I remember the naïve olden days of people’s Unix Path starting with .) Or is Cursor going out of its way to execute a git.exe in the current directory?
- iririririr 2mo agothis attack vector is part of the spec in all Java build systems. you don't even need ai slop ide. Java Devs will happily execute your malicious maven/gradle/Grovy/whatever that you push to any public repo. bonus point ofy commit message is complaining about some build plugin version compatibility
- dhpe 2mo agoThere's discussion whether this is a vuln. While some responsibility should be on the user to already having downloaded a malicious binary, I think it's poor default behavior from cursor to run git from the repo root. Is it really a use case to have git.exe in a git repo — more like a red flag.
- cute_boi 2mo ago> While some responsibility should be on the user User should always be responsible before downloading pdf, excel and its macros. There are so many way things can get infected..
- iainmerrick 2mo agoIf it happens out of the box with fresh installations of both Windows and Cursor, I’d say it’s a serious vulnerability in at least one of those. Sounds like this is a golden oldie bug on Windows/DOS, which I assume is now patched by default. If so it’s Cursor’s problem.
- varenc 2mo agoOn Windows, if your shell was in a malicious repo's directory and you ran any "git" command, wouldn't the behavior be the same? Binaries in the current directory are considered before PATH. This seems like a broader issue. That said, Cursor should at least have some "trust this directory?" dialogue.
- psd1 2mo agoNot in powershell, no, because . is not in PATH (unless you put it there). If you tab-complete `git` it will resolve to `.\git.exe` but it you merely hit enter then it will search PATH and not the CD.
- varenc 2mo agogreat point! Though what about the default windows APIs for 'calling out to shell'. Like using `subprocess.run(...)` in Python. My suspicion is that works like cmd.exe? edit: answered myself. Seems like subprocess.run works like PowerShell, unless you pass in 'shell=True', then it passes it directly to CMD.exe. And I'm guessing that's what Cursor is doing.
- Aperocky 2mo agoAs 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 2mo agoOpening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
- romanovcode 2mo agoWe're back to autorun.exe times
- username135 2mo agoTime is a flat circle it seems
- nicman23 2mo agobut it is just a agents.md file lol
- mort96 2mo agoThis has nothing to do with any language model or agent, this is just traditional deterministic code in the Cursor program.
- dools 2mo agoGiven the fact that people frequently give their coding agents permission to pull and push from git, this is a massive vector for supply chain attack. Some cursor instance you left running on a project has an agent that wants to grab the latest project files, some attacker has compromised some project and put their exe into it and X00,000 of people are all of a sudden running random EXE as the primary user
- 3plefly 2mo agoHas anyone tried to replicate this? I copied my calculator app and renamed it to git.exe, put it in a few repositories, openned cursor with those repositroies loaded, even prompted cursor to scan the repository, to which it said it saw the git.exe ("Accidental binary — delete it, don’t commit"), but nothing was executed to my knowledge
- SV_BubbleTime 2mo agoI mean… is our idea of repeatability really ready for subjective actions from LLMs? We spent like ALL the years making sure computer would always give repeatable objective deterministic answers… then one day we’re nah fuck that I want a slot machine!! With tightly coupled agents, how could you ever really prove that it is or isn’t a problem? Try and fuzz I guess? But in a many billion parameter model that seems like you could never really be sure either. One day the LLM could just decide, “oh, I’ll run this git.exe!”
- deleted 2mo ago[deleted]
- brookst 2mo agoThe vuln is supposedly in the cursor IDE, not an LLM-mediated iteraction
- TZubiri 2mo ago>This bug is simple. A developer opens a repository in Cursor on Windows, and if that repository contains a malicious git.exe in the project root, A vuln that requires an existing malicious executable to have already been downloaded and have it executable bit set to true? Doesn't sound like a vuln >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. It's probably 3 factors: - Lots of bounty begs powered by vibecoding. This gets lost in the noise (like this report) - Cursor is itself vibecoded so they ship features faster than they care to fix issues. - don't know if it's me or the way Mindgard is putting this, but it's presented as a critical bug, and upon reading it, it's very hard to see the subtle low priority security issue. Here's a rough unbiased summary of the 'issue': Cursor loads the 'git' dependency at runtime. If the user has downloaded a malicious repository, they will get pwned when they open cursor even if they don't run any prompts. The author seems to suggest that either git should be looked for in the 'proper dependency' folder to mitigate this risk. This would mean that attackers would pwn the victim when a the user opens cursor and runs 1 prompt that executes a vulnerable file called runme.exe instead of being pwned just by the user opening cursor on the malicious repo.
- Shorel 2mo agoIsn't this the oldest kind of vulnerabilities corrected on UNIX several decades ago? The current directory is not in the PATH, period. This is also a bug on Windows only, so to me this is more a Windows issue than a Cursor issue, unless there's some logic in Windows that is doing the same as UNIX has done for decades. Given the "fix" involves ACL and a complex workaround that's not really a fix, I stay in my position this is more a Windows fuckup than something particular to Cursor.
- throwitaway222 2mo agoUh, you're already beyond fucked if git.exe (or equivalent in *nix) is a hacked one and on your system. And similarly the same doomsday article does not exist for VSCode, Zed, GitKraken, and a billion other tools that run git without caring to ask..
- UnwrapComment 2mo agoIn this case, simply cloning a repository containing such an executable is enough. This isn’t a common bug or a gotcha.
- ralferoo 2mo agoAlthough on Windows, the current directory is checked before PATH, unlike UNIX-based systems that require the current directory to be explicitly included in the PATH if that's the behaviour you want. So for any repository with git.exe in the root, if you then ran another git command from a DOS prompt with the repo as your current directory then it would give the same bad outcome of running the git.exe from the repo. I'm not saying that it's good that it's happening, but it doesn't seem like it's their bug to solve per se, it's just a feature of using Windows. Of course, they probably could work round it by parsing the PATH themselves and locating a git.exe that isn't in the current directory.
- lemagedurage 2mo agoThe problem seems to be deeper rooted. Cursor doesn't see cloning a repo with Cursor and code execution as separate security boundaries. Cursor ships with Workspace Trust disabled by default [0]. A repo that includes .vscode/tasks.json with "runOn": "folderOpen" will already run arbitrary code [1]. [0] https://cursor.com/docs/agent/security#workspace-trust https://cursor.com/docs/agent/security#workspace-trust [1] https://www.oasis.security/blog/cursor-security-flaw https://www.oasis.security/blog/cursor-security-flaw
- noisy_boy 2mo agoI am not certain about Windows but on Linux, aren't applications supposed to use PATH based resolution provided by shell for this? Why go to the root of the project directory at all looking for binaries? Because it has been become their favorite place due to readme / skills etc being there?
- charcircuit 2mo agoSuspiciously the authors do not say if this works in restricted mode. This is not considered a vulnerability outside of restricted mode.
- jyswee 2mo ago[flagged]
- theaniketmaurya 2mo agoFirst grok cli and now this
- fatmacelik6894 2mo ago[flagged]
- glasffordd 2mo ago[dead]
- dublecc 2mo ago[flagged]