Your AI Coding Agent Will Run This Exploit For You: How We Found a High-Severity CVE in Cursor

This research was conducted under responsible disclosure principles and in full cooperation with Cursor. Coordination and remediation efforts were completed with the vendor prior to publication. Cursor published CVE-2026-26268 in February, 2026.

Don’t test systems you don’t own or have explicit permission to access.

The IDE Is Not a Safe Zone

Novee’s research team identified a high-severity arbitrary code execution vulnerability in Cursor, the popular AI-powered IDE. Cursor has published the vulnerability as CVE-2026-26268.

The root cause is not a flaw in Cursor’s core product logic, but rather a consequence of a feature interaction in Git, one that becomes exploitable the moment an AI agent starts autonomously executing Git operations inside a repository it doesn’t control. The end result is attacker code execution directly on a developer’s machine.

This research emphasizes a critical gap in modern security testing focus: when a security team audits an application’s external attack surface (APIs, authentication flows, user-facing inputs) the development environment itself rarely comes under scrutiny. The assumption is that the tools developers use to build software are themselves secure. That assumption is worth revisiting, especially when those tools are AI-powered agents, operating autonomously inside a developer’s local environment on code from any source on the internet.

How Git Features Work (And How They Leave Room for Exploits)

To understand the vulnerability, it helps to understand two legitimate Git features that, when combined, produce an exploitable condition.

(1) Git Hooks are scripts that execute automatically in response to specific Git events, such as pre-commit and post-checkout. They’re a standard tool for automating repetitive tasks in software development workflows. Hook scripts live in the .git directory of a repository, which is generally excluded from tracked Git repo contents. 

(2) Bare repositories are another standard Git construct: repositories that contain only version control data (the .git directory contents) without a working directory. They can be embedded inside a larger repository. This is where the exploit starts.

A malicious actor can embed a bare repository inside a legitimate-looking repository. That embedded bare repository includes a malicious pre-commit hook. Whenever a commit operation runs within the embedded repository context (for example, triggered by the Cursor agent executing git checkout, as instructed by the repository’s Cursor Rules), the malicious hook fires automatically.

No user prompt required. No warning displayed.

The impact is auto-approved arbitrary code execution on the end-user’s machine, triggered by ordinary use of the IDE on a cloned repository.

Why AI Agents Change the Threat Model for Developer Tools

This vulnerability is not new in the sense that the underlying Git behavior is well-documented. What makes it newly dangerous is the context in which it operates.

Traditional IDE usage is largely passive. Developers open repositories, read and write code, and manually execute commands. The IDE simply follows instructions.

Cursor’s AI agent fundamentally changes that model. The agent interprets a high-level user prompt and autonomously decides which operations to run. Including Git operations. This is what makes the product powerful, yes, but it’s also what makes this vulnerability exploitable at scale.

When the agent runs git checkout as part of fulfilling a routine request, it is not doing anything the user didn’t implicitly authorize. But neither the user nor the agent has visibility into what the repository’s Cursor Rules have set in motion. A malicious pre-commit hook embedded in a nested bare repository executes silently, outside the agent’s reasoning chain and outside the user’s field of view.

The attack requires no social engineering beyond what’s inherent in the act of cloning a public repository; something developers do constantly, and something AI-assisted workflows are increasingly automating. As agents take on more autonomous capability, the scope of what they can be made to execute grows, and the attack surface of the underlying environment they operate in becomes directly relevant to security.

Expanding Security Testing to the Agentic Attack Surface

In traditional pentesting, “client-side” attacks targeting developer machines have always been a known vector. But they relied on user error or a lapse in vigilance, typically requiring a degree of deliberate action on the part of the victim: opening a malicious file, executing a script, clicking a link. The assumption not only of a trustworthy IDE, but of required human action, is a meaningful constraint on exploitability. AI agents do away with that constraint.

When the agent automatically executes Git operations in response to a natural-language prompt, the step between “clone a repository” and “execute attacker-controlled code” is reduced to a single, unremarkable user action. The attack surface of any AI-powered tool now includes the untrusted content that tool operates on. And, as this finding illustrates, the execution environment of the software those tools interact with.

How Novee Found It

The Novee research team set out to find multi-step exploit paths that emerge specifically from the interaction between AI agent behavior and untrusted inputs. The question is not just “what can go wrong in Cursor?” but “what can an attacker cause to happen by controlling what a Cursor agent operates on?”

Pushing the boundaries of traditional vulnerability research requires our team to search not just for individual vulnerabilities, but for complex vulnerability patterns. This allows us to keep improving our AI agents based on those unique patterns, which in turn leads to a deeper understanding of how individual components of a software system interact under adversarial conditions. In this case: how does Git’s hook execution model interact with Cursor’s agentic Git behavior? What happens when a repository is specifically designed to exploit that interaction? The answer to that question is CVE-2026-26268.

The reasoning that uncovered this vulnerability (identifying trust boundary violations in multi-step workflows involving AI agent behavior) is the same class of reasoning Novee encodes into its autonomous pentesting agents. 

When a researcher understands how to exploit agentic behavior at the application layer, that understanding becomes a capability the platform can exercise at scale. It’s how we turn research like this into our latest product: AI Red Teaming for LLMs.

Final Thoughts for Security Teams

Developer machines are production-equivalent targets. Credentials, tokens, source code, and internal tooling are routinely accessible from developer environments. Arbitrary code execution on a developer machine is often a meaningful step toward broader compromise.

The attack surface of AI-powered tools includes the content they process. Security reviews of AI coding assistants should account not just for the tool’s own code, but for how the tool behaves when operating on attacker-controlled inputs.

Cursor rules and agent instructions are an attack surface. Repositories can include configuration that shapes agent behavior. The security implications of that configuration, and what it can cause an agent to execute, deserve scrutiny.

The attack surface is changing because the environments defenders need to protect now include AI agents that operate autonomously, respond to external inputs, and execute system-level operations without explicit per-action approval.

CVE-2026-26268 is high severity because the path from “clone a repo” to “attacker runs code on your machine” is now a single routine action. The only way to stay ahead of attackers who reason that way is to think like them – continuously.

That’s what Novee’s researchers do. And it’s what the platform is built to replicate.
See it in action → Book a demo.