Cursor AI coding agent flaw lets malicious repositories run code on developer machines

A Cursor vulnerability tracked as CVE-2026-26268 can let attackers run code on a developer’s machine through a malicious repository. The issue affects Cursor versions before 2.5 and has been fixed in version 2.5.

The flaw matters because developers often clone public repositories as part of normal work. In this case, a malicious repository can abuse Git behavior and Cursor’s AI agent workflow to trigger code execution without a separate prompt from the user.

Security researchers at Novee found the issue while studying how AI coding agents behave when they operate on untrusted inputs. Cursor published a security advisory for the vulnerability in February 2026.

What happened

The vulnerability is tied to how Cursor’s AI agent interacts with Git. The issue involves improperly protected .git settings, including Git hooks, which can run automatically when certain Git actions happen.

An attacker can craft a repository that includes an embedded bare Git repository with a malicious hook. When Cursor’s AI agent performs a Git operation inside that repository context, the hook can execute code on the developer’s machine.

This changes the risk model for AI coding tools. The developer may only clone a repository and ask the agent to inspect or explain the codebase, while the agent performs the Git operation that triggers the malicious hook.

At a glance

Item	Details
Vulnerability	CVE-2026-26268
Affected product	Cursor
Affected versions	Versions before 2.5
Fixed version	2.5
Severity	High in Cursor’s GitHub advisory
Main risk	Out-of-sandbox code execution on developer machines
Core weakness	Unsafe interaction between AI agent behavior, Git configuration, and Git hooks
Attack path	Malicious repository with embedded bare Git repo and malicious hooks
User interaction	No extra confirmation after the agent triggers the Git operation

How the exploit works

The attack starts when a developer clones a malicious repository. At first glance, the repository can look like a normal public project.

Inside it, the attacker places an embedded bare Git repository. Bare repositories are legitimate Git structures that contain version control data without a normal working directory.

The attacker then adds a malicious Git hook inside that embedded bare repository. Git hooks are scripts that run automatically during certain Git events, such as checkout or commit operations.

Why Cursor’s AI agent changes the risk

Git hooks are not new, and bare repositories are not new. The danger comes from the way an autonomous coding agent can interact with them while trying to complete a normal task.

A developer might ask Cursor to explain the repository, inspect files, or help with a coding task. The agent can then follow repository instructions and run Git operations as part of its workflow.

If the agent enters the embedded bare repository context and runs the right Git command, the malicious hook fires automatically. The attacker’s code can then run outside the agent’s sandbox.

Attack chain

Step	What happens	Why it matters
1	A developer clones a malicious public repository	This looks like a normal developer workflow
2	The repository contains an embedded bare Git repository	The dangerous content can sit inside the project structure
3	The embedded repository contains a malicious Git hook	The hook can run automatically during Git activity
4	The Cursor agent follows repository instructions and runs a Git operation	The user may not directly approve that specific command
5	The Git hook executes attacker-controlled code	The developer machine becomes exposed

Why developer machines are valuable targets

A developer laptop can hold far more than source code. It can store API keys, GitHub tokens, SSH keys, package registry tokens, cloud credentials, test data, local databases, and internal access tools.

That makes local code execution on a developer machine a serious security issue. An attacker who gains access there may be able to move toward private repositories, CI/CD systems, cloud environments, or production infrastructure.

The risk grows in teams where developers frequently clone unfamiliar repositories, test open-source projects, or use AI agents to review third-party code.

What makes this different from traditional IDE risk

Traditional IDE attacks often need the user to open a file, run a script, install an extension, or accept a prompt. This flaw shows a different model.

The user can perform a normal action, such as cloning a repository and asking the AI agent to work with it. The agent then performs the action that triggers the malicious hook.

This makes the repository itself part of the attack surface. Cursor Rules, agent instructions, Git metadata, and embedded repositories all need security attention when AI coding agents handle untrusted code.

Who should take action

Developers using Cursor should update to version 2.5 or later. Teams should also check whether older Cursor versions still exist on developer machines, build workstations, or shared coding environments.

Security teams should treat public repositories as untrusted inputs, especially when AI agents can act on them. A repository may contain instructions that guide the agent toward risky behavior.

Organizations should also review their rules around AI-assisted development. Tools that can read code, run commands, change files, and perform Git operations need the same level of review as other execution-capable software.

Recommended steps for developers

• Update Cursor to version 2.5 or later.
• Avoid opening unknown repositories in AI agent mode without reviewing their structure first.
• Check repositories for embedded bare Git directories before allowing an agent to operate on them.
• Review unfamiliar Cursor Rules, agent instruction files, and automation files.
• Do not store long-lived production secrets on local developer machines.
• Use separate credentials for development, testing, and production systems.
• Rotate tokens if a suspicious repository ran in an older Cursor version.

Recommended steps for security teams

• Inventory Cursor installations across developer devices.
• Confirm all installations run version 2.5 or later.
• Audit developer repositories for embedded bare Git repositories.
• Monitor for unexpected Git hook execution.
• Review local machines for exposed GitHub, npm, cloud, and SSH credentials.
• Restrict AI agent operation on untrusted repositories.
• Add endpoint monitoring for suspicious child processes launched from developer tools.
• Create a policy for AI coding agents that handle external code.

Why this matters for AI coding tools

CVE-2026-26268 shows that AI coding agents create a new security boundary. The tool does not only display code. It can interpret instructions, move through repositories, run commands, and interact with developer workflows.

That power makes AI coding tools useful, but it also gives attackers new ways to turn normal project files into execution paths. A malicious repository can become more dangerous when an agent follows instructions inside it.

For development teams, the larger lesson is clear. AI coding environments should be reviewed as active execution environments, not just productivity tools.

FAQ