# AI Coding Tools Expose You via git.exe — Vendors Won’t Fix > Source: > Published: 2026-07-15 17:12:49+00:00 Security firm Mindgard publicly disclosed today — after seven months of silence from Cursor — that the popular AI IDE executes malicious code simply by opening a cloned repository. The flaw, a binary planting attack where a fake `git.exe` in a repo root gets executed on project open, affects 7 million Cursor users. But Cursor is not the full story. Cymulate separately found the same attack class in [GitHub Copilot CLI (CVE-2026-29783)](https://github.com/advisories/GHSA-g8r9-g2v8-jv6f), Gemini CLI, and OpenAI Codex. Not one vendor has shipped a patch. GitHub downgraded its report to “low severity.” OpenAI closed it as “Not Applicable.” Google acknowledged it and went quiet. Only AWS, for its Kiro IDE, patched promptly and published a security bulletin. The others made a choice. ## One Flaw, Four AI Coding Tools Binary planting exploits a Windows behavior that developers rarely think about: when an application resolves an executable by name, the current working directory is searched before `%PATH%` . Plant a malicious binary named `git.exe` in a repository root, and any AI coding tool that naively searches for Git during initialization will execute it. The attack requires no privileges, no social engineering, and no complex exploit chain. Clone a repo, open it in your AI IDE, and the malicious binary runs with your full user privileges — granting access to your SSH keys, cloud credentials, source code, and anything else on your machine. Mindgard demonstrated this against [Cursor using a renamed copy of Windows Calculator](https://thehackernews.com/2026/07/cursor-flaw-lets-malicious-cloned.html). The binary executed repeatedly while the project stayed open. Cymulate’s broader research found identical behavior in GitHub Copilot CLI, Gemini CLI, and the Codex desktop app. All four tools share the same root cause: they resolve Git binaries using unsafe Windows search order automatically on folder open, without user approval. ## The Vendor Response Hall of Shame Mindgard first reported the Cursor flaw on December 15, 2025. [Cursor shipped 197 new versions](https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left) between that date and today’s public disclosure. None addressed the vulnerability. The researchers put it plainly: “Seven months after initial disclosure, we have no indication that users are being protected, that remediation is underway, or that affected organizations have been informed.” Cursor has published no security advisory covering this issue. GitHub and OpenAI’s responses deserve particular scrutiny. GitHub accepted Cymulate’s Copilot CLI report, paid a bug bounty, then downgraded severity to low with the note that “behavior may not be changed immediately.” OpenAI’s reasoning was bolder: the company closed the Codex report as “Not Applicable,” arguing that an attacker who can plant a `git.exe` already has system access. This logic is wrong. Cloning a repository IS the mechanism that delivers the malicious binary — that is the attack vector, not a precondition. Developers clone repositories constantly, and AI agents do it on their behalf even more frequently. Google acknowledged Gemini CLI’s exposure and offered no remediation timeline. ## AWS Kiro Fixed It — And Exposed Everyone Else AWS Kiro had an analogous flaw: its LLM-driven file writing tool would write to `.vscode/tasks.json` without user approval, and VS Code would then automatically execute those tasks on folder open. [Cymulate reported it to Amazon](https://cymulate.com/blog/zero-click-rce-prompt-injection-ai-tools/). AWS assigned CVE-2026-10591 (CVSS 8.8 High), credited the researchers, patched it in Kiro 0.11, and published Security Bulletin 2026-037-AWS requiring explicit user approval for all file writes. The entire response took weeks, not months. This is what responsible vulnerability handling looks like. AWS Kiro’s response makes every other vendor’s inaction impossible to explain as technical difficulty. The fix exists. It is not complex. Cursor, GitHub, Google, and OpenAI chose not to ship it. Related:[99.9% of AI Vulnerabilities Are Fixable. No One Is Fixing Them.] ## What Developers Should Do Now Patches are not coming on any clear timeline for most of these AI coding tools. Until they arrive, the mitigation burden falls on developers: - Open untrusted repositories in Windows Sandbox, WSL, or an ephemeral VM — never directly on your host machine - Before opening any cloned repo in an AI IDE, scan for suspicious executables in the root and subdirectories: `git.exe` ,`npx.exe` ,`node.exe` ,`where.exe` - Deploy AppLocker or Windows App Control policies that block executable files located under workspace directories - For CI/CD pipelines using AI agents, run them inside devcontainers with locked-down execution policies that prevent workspace-local binaries from executing None of these workarounds are adequate substitutes for vendor patches. Developers should not need to manually audit every repository they open in their IDE. That responsibility belongs to the tool vendors. Until they treat this as a genuine security issue rather than a paperwork inconvenience, the burden sits with you. ## Key Takeaways - Binary planting — placing a malicious `git.exe` in a repo root — triggers automatic code execution in Cursor, GitHub Copilot CLI, Gemini CLI, and OpenAI Codex on Windows, with no user interaction beyond opening the project - Mindgard disclosed Cursor’s flaw today after seven months of vendor silence; the same attack class affects three additional major AI coding tools, all unpatched - Vendor response is the variable that determines whether vulnerabilities get fixed, not technical complexity: GitHub downgraded to low, OpenAI rejected it, Google went quiet — AWS patched promptly and set the standard - Protect yourself by isolating AI IDE sessions in sandboxed environments and using AppLocker or Windows App Control to block workspace-local executable resolution until patches ship - This is not a Cursor problem — it is an AI coding tool ecosystem problem, and every vendor should be held to AWS Kiro’s standard