Cursor Vulnerability (CVE-2025-59944): How a Case-Sensitivity Bug Exposed the Risks of Agentic Developer Tools | Lakera – Protecting AI teams that disrupt the world.

Cursor Vulnerability (CVE-2025-59944): How a Case-Sensitivity Bug Exposed the Risks of Agentic Developer Tools

AI Security

3

min read

October 10, 2025

Lakera researcher Brett Gustafson discovered and responsibly reported a vulnerability in Cursor, an AI-powered IDE that lets developers write code through natural language.

The flaw, later assigned CVE-2025-59944, allowed attackers to bypass file protections through a subtle case-sensitivity mismatch. In the right conditions, this could let untrusted content modify configuration files and, in some cases, lead to remote code execution.

There’s something oddly poetic about it: a single misplaced capital letter quietly turning automation into a security risk. The incident highlights how even small implementation details can become serious vulnerabilities once coding assistants start reasoning and acting on their own.

TL;DR

AI tools now write code and change the environment that runs it

Cursor’s agentic features let you type something like:

“Create a Python script that prints ‘Hello, world.’”

…and the IDE does it automatically. That feels magical, until you realize the same system can modify files that define what runs, what loads, and what executes on your machine.

Cursor tried to prevent that by showing confirmation prompts whenever an AI-generated action targeted special configuration files. These prompts were the guardrails between automation and potential chaos.

Restricted File Edit Confirmation for .cursor/mcp.json

But a few letters slipped through.

The vulnerability: case sensitivity meets case insensitivity

Cursor’s protection logic matched file names case-sensitively, requiring an exact pattern such as .cursor/mcp.json.

Most consumer operating systems in their default configuration (macOS and Windows) ignore case. So if an attacker or malicious prompt asked Cursor to create .cUrSoR/mcp.json or .vsCoDe/tasks.json, the IDE treated them as new files and skipped the confirmation prompt.

Edit Confirmation Bypassed Through Case Modification

To the OS, those new files were the same as the protected ones. Cursor then loads that configuration, now containing whatever the attacker wanted.

Path variations like .cursor/./mcp.json achieved the same result, creating a quiet overwrite channel hiding in plain sight.

From bypass to execution: why this wasn’t just a minor bug

At first glance, it’s just a filename check gone wrong. But in an agentic IDE, that check decides which commands can run, which plugins start, and what happens when a folder opens.

A crafted payload could:

That’s where this becomes more than a curiosity. A prompt injection could trigger indirect, chained behavior that leads to remote code execution, exactly what the GitHub advisory confirmed.

💡 Indirect prompt injections matter too.

In many real-world scenarios, the developer isn’t the one entering the malicious prompt. The attack can originate indirectly such as through a connected MCP server.

In that case, the IDE interprets untrusted content as an instruction without any user involvement. That’s what makes this class of vulnerabilities particularly risky for agentic tools: they act on behalf of the user, but often without the user’s explicit awareness.

Discreet Injection of Instructions from MCP Server Modify mcp.json Configuration

The bigger insight is how this kind of bug can play out. Once an MCP server or another external process integrates into an agentic IDE, an attacker doesn’t even need to compromise the developer directly. A third-party component could unknowingly execute malicious behavior through the IDE’s automation layer.

👉 For a deeper look at that kind of chain, see Lakera’s analysis of zero-click RCE in agentic IDEs.

A quick fix and a bigger lesson

Cursor’s team responded fast. Version 1.7 closed the loophole by normalizing file paths and comparing them case-insensitively.

But the patch isn’t the real story here. What matters is what this says about where software security is headed.

Once an IDE can reason and act, its attack surface expands from what you code, to what the IDE ingests as data but interprets as instruction, to what the tool can do on your behalf.

Checks built for static inputs don’t always hold up when the actor is an AI.

This isn’t just about case sensitivity. It’s about how automation changes the boundaries of trust.

Rethinking security in the age of agentic development

The Cursor bug was small but the lesson isn’t.

Even the smartest assistants need supervision.

Here’s what security teams and builders should take away:

The broader shift: from safe prompts to secure autonomy

What looks like a one-line oversight actually points to the next frontier of application security.

As agentic tools take on more autonomy, static validation must evolve into behavioral and contextual defense.

Because in a world where an AI can write, move, and execute code, the most dangerous bug might not be malicious code at all.

It might just be a missing case validation.

Responsible Disclosure Timeline

🟠

September 2, 2025

Cursor team privately informed of vulnerability.

🟢

September 29, 2025

Vulnerability patched in Cursor 1.7 release.

CVE-2025-59944 — “Cursor IDE: Sensitive File Overwrite Bypass.” Discovered and responsibly reported by Brett Gustafson of Lakera and others. Fixed in Cursor 1.7. View advisory →