Critical Cursor IDE Flaws Let Prompt Injection Escape the Sandbox and Run Code

Security researchers have disclosed two critical Cursor IDE vulnerabilities that could allow a malicious prompt injection to escape the editor’s sandbox and achieve remote code execution on a developer’s machine.

The flaws, tracked as CVE-2026-50548 and CVE-2026-50549, affect Cursor versions before 3.0. Cato AI Labs named the vulnerability pair DuneSlide and said either bug could let an attacker turn sandboxed agent commands into unsandboxed code execution.

Developers using older Cursor builds should update immediately. The Cursor 3.0 changelog confirms that Cursor 3 was released on April 2, 2026, and the vendor advisories list version 3.0 as the patched release.

What DuneSlide Does

DuneSlide targets Cursor’s agent workflow, not the traditional code editor surface. In Cursor 2.x, agent terminal commands could run inside a sandbox by default, a design intended to reduce approval prompts while limiting damage from unsafe commands.

The problem is that both vulnerabilities let attacker-controlled instructions influence paths that the sandbox trusted. Once a malicious prompt causes the agent to write outside the intended workspace, the attacker can overwrite sensitive files, including Cursor’s sandbox helper.

The GitHub advisory for CVE-2026-50548 says a malicious agent could set a working directory to a sensitive location and write arbitrary files outside the workspace. The GitHub advisory for CVE-2026-50549 describes a separate path-resolution flaw involving symlinks and failed canonicalization.

Vulnerability	Issue	Affected versions	Fixed version	Severity
CVE-2026-50548	Agent-controlled working directory can expand sandbox write access	Cursor before 3.0	Cursor 3.0	Critical
CVE-2026-50549	Symlink canonicalization failure can allow writes outside the workspace	Cursor before 3.0	Cursor 3.0	Critical

How a Prompt Injection Can Trigger the Attack

The attack starts when Cursor’s agent reads attacker-controlled content while handling a normal user request. That content could come from a poisoned web result, a malicious MCP server response, documentation, a ticket, or another untrusted source that the agent processes as context.

The user does not need to approve an obvious dangerous command. According to Cato AI Labs, an ordinary prompt can accidentally pull in the malicious instructions, after which the agent follows them through trusted tool parameters or file operations.

This is why the issue matters beyond Cursor alone. It shows how prompt injection can move from manipulating an AI response to reaching ordinary software logic, including filesystem checks, sandbox policy generation, and path validation.

• An attacker hides instructions in content the coding agent may read.
• The developer asks Cursor a normal question or gives a normal coding task.
• The agent ingests the malicious content as part of its work.
• The hidden instructions steer the agent toward unsafe file writes.
• The attacker can neutralize the sandbox and run later commands without it.

CVE-2026-50548: Working Directory Manipulation

CVE-2026-50548 stems from the way Cursor built sandbox permissions around a command’s working directory. The sandbox granted write access to the current working directory, but the agent could influence the optional working_directory parameter.

If prompt injection caused the agent to set that value to a sensitive path outside the project, the sandbox could add that external path to the allowed write list. The NVD entry for CVE-2026-50548 says this could allow arbitrary file writes outside the workspace under the user’s privileges.

One high-impact target is Cursor’s cursorsandbox helper. If that helper gets overwritten, later terminal commands can run without the sandbox boundary, giving the attacker non-sandboxed remote code execution.

CVE-2026-50549: Symlink Canonicalization Bypass

CVE-2026-50549 is independent from the working directory bug. It involves how Cursor handled symlinks before writing files through the agent.

Before a write operation, Cursor tried to resolve the real target path to confirm that it stayed inside the workspace. The NVD entry for CVE-2026-50549 says the flaw appeared when canonicalization failed, such as when the target did not exist or a path lacked read permissions.

In that failure state, Cursor could fall back to the original in-workspace symlink path and write through it. A malicious agent could therefore create a symlink inside the project that points outside the project, then use that link to overwrite files the sandbox should not touch.

Attack path	What the attacker abuses	Possible result
Working directory manipulation	Agent-controlled working_directory parameter	External paths become writable by sandboxed commands
Symlink bypass	Failed path canonicalization and fallback behavior	Writes escape the workspace through a symlink
Sandbox helper overwrite	Write access to sensitive Cursor files	Later commands run without sandbox restrictions
Post-exploitation access	User-level permissions and connected developer tools	Compromise can extend to source code, credentials, and SaaS sessions

Why Developers Should Treat This as Urgent

The official records describe both issues as critical. The CVE-2026-50548 record lists a CVSS v3.1 score of 9.8 and says the vulnerability can lead to non-sandboxed remote code execution with no interaction beyond a benign prompt.

The CVE-2026-50549 record also lists a CVSS v3.1 score of 9.8 and describes a path that can let a malicious agent write arbitrary files outside the workspace.

CISA’s enrichment data in the NVD records also marks the technical impact as total and the issue as automatable, while noting no known exploitation at the time of analysis. That lowers panic, but it does not lower the need to patch.

Cursor 3.0 Fixes the Vulnerabilities

Both advisories list Cursor 3.0 as the patched version. The CVE-2026-50548 advisory says Cursor no longer grants write access based on an agent-controlled working directory.

The CVE-2026-50549 advisory says Cursor now treats failed canonicalization as untrusted and blocks the write instead of falling back to the original path.

Cursor users should update to version 3.0 or later, then review any systems where older Cursor versions ran agent tasks against untrusted content. Teams should also check whether Cursor had access to repositories, cloud credentials, package registries, issue trackers, or SaaS workspaces during affected usage.

Recommended Actions for Teams

The immediate fix is to update Cursor, but organizations should also look at how AI coding agents interact with untrusted input. Sandboxes help, but DuneSlide shows that a sandbox can fail when the agent controls parameters that shape the sandbox boundary.

Security teams should treat coding agents as privileged developer tools. They can read source code, write files, run commands, access secrets, and connect to external services, so they need the same governance applied to build systems, CI runners, and developer endpoints.

• Update all Cursor installations to version 3.0 or later.
• Audit developer machines that used Cursor 2.x with MCP servers, web search, or untrusted repositories.
• Review recent modifications to shell startup files, launch agents, Cursor helper files, and project symlinks.
• Limit agent access to secrets, production credentials, and sensitive SaaS integrations.
• Use least-privilege accounts for development environments where possible.
• Monitor agent-driven terminal commands and file writes in high-risk repositories.

What This Means for AI Coding Tools

DuneSlide adds to a growing list of security problems where AI coding agents turn indirect instructions into real system actions. The key issue is not only whether an LLM follows bad instructions, but whether the surrounding product gives those instructions access to dangerous tools.

The Cursor 3.0 release moves the product further toward an agent-first interface, which makes agent security even more important. As coding agents become more autonomous, product teams need stronger validation around tool parameters, filesystem boundaries, external context, and approval flows.

For developers, the practical lesson is simple: update Cursor, restrict agent access where possible, and assume that any content an AI agent reads can contain hostile instructions.

FAQ