Cursor AI IDE Flaws Crack Open OS-Level Code Execution

Three months after Cursor 3.0 shipped fixes on April 2, 2026, the real lesson from the Cursor DuneSlide vulnerabilities is sharper than the patch note: AI coding assistants can turn ordinary text processing into a route for OS-level remote code execution.

The two flaws, tracked as CVE-2026-50548 and CVE-2026-50549, carry a CVSS score of 9.8 and were reported by Cato Networks, according to SecurityWeek. Cato refers to them collectively as DuneSlide because they allow execution outside Cursor’s IDE sandbox.

The timing matters. Cato reported the bugs to Cursor in February 2026. Cursor patched both in Cursor 3.0 on April 2, 2026. The CVE identifiers were assigned in early June 2026. That sequence means this is no longer just a research finding. It’s now a test of whether teams know where AI IDEs run, what permissions they have, and whether they’ve actually been updated.

February 2026: Cursor's DuneSlide flaws exposed the bargain behind AI coding assistants

Cursor is built for developer convenience. It reads code, accepts natural-language prompts, and can run terminal commands inside a sandbox. That combination is exactly why developers like AI IDEs. It is also why the DuneSlide bugs matter.

The core issue is not that prompt injection exists. Security teams already know model instructions can be manipulated. The more dangerous step is what happens next: in these flaws, malicious instructions can escape the sandbox and reach the underlying operating system.

That changes the risk category. Prompt injection that alters an AI assistant’s answer is one thing. Prompt injection that leads to arbitrary code execution on a developer machine is another.

Cato said the flaws abuse Cursor’s automatic terminal command execution inside the sandbox, which does not prompt the user for approval. The attack can be triggered when a victim prompts the IDE to ingest an attacker-controlled payload. SecurityWeek’s description frames this as a zero-click prompt injection path because the vulnerable workflow does not require the user to manually approve a command once the malicious content is processed.

XOOMAR analysis: this is the fragile boundary AI coding tools now sit on. They interpret prose, inspect code, touch local files, and invoke execution tools. If the boundary between “assistant suggestion” and “local action” breaks, the IDE becomes a privileged attack surface.

April 2, 2026: How DuneSlide turns prompt injection into OS-level RCE

The first DuneSlide flaw targets Cursor’s sandbox boundary.

Cursor is supposed to restrict command execution to the current working directory. But Cato found that when the working_directory parameter is assigned a non-default value, that path gets added to an allow list. An attacker-controlled prompt can then instruct the LLM to set the working directory to a path outside the intended project scope.

That matters because the attacker can target the cursorsandbox executable itself.

“future commands run without sandbox restrictions, so future instructions within the same prompt injection lead to a non-sandboxed RCE,” Cato explains.

The second flaw is separate. It involves Cursor’s file path resolution logic and symbolic links. A malicious prompt can instruct the agent to create a symlink inside the project directory that points to a file outside it. Cursor tries to resolve the symlink and verify the location, but Cato says an edge case causes it to fall back to the original symlink path.

Cato’s explanation is blunt:

“A threat actor can then create a write-only symlink, thus forcing Cursor to assume the resolved path is the symlink path, rather than the target path. This fails its detection that the ultimate destination is out of bounds, allowing the threat actor to link to the cursorsandbox executable once more,”

The causation chain is the story:

• Input: Cursor ingests attacker-controlled content through a prompt-driven workflow.
• Automation: The IDE executes terminal commands inside the sandbox without user approval.
• Breakout: A sandbox boundary or path validation flaw lets the attacker target files outside the project scope.
• Execution: The attacker reaches non-sandboxed remote code execution on the host operating system.

XOOMAR analysis: teams should verify which Cursor workflows ingest untrusted material, including repository content, documentation, issue text, pull request text, comments, package metadata, or web content. The supplied reporting does not confirm each of those as an exploit vector, but they are the kinds of input surfaces security teams should map before assuming exposure is low.

Early June 2026: The numbers that should drive the Cursor DuneSlide vulnerabilities response

The defensive takeaway is immediate: if Cursor is in use, confirm whether installations are on Cursor 3.0 or later. If teams can’t answer that quickly, they don’t have adequate inventory for AI developer tools.

XOOMAR analysis: useful internal metrics now include the number of Cursor installations, how many have terminal access enabled, which workspaces contain sensitive repositories, and whether developer endpoints hold credentials that would make OS-level code execution especially damaging.

This is also where broader AI security budget pressure becomes concrete. Tool sprawl is hard to govern when usage expands faster than controls, a theme we’ve covered in AI Token Costs Threaten to Break Cybersecurity Budgets. DuneSlide adds a sharper question: are teams funding usage, or funding containment?

After the patch: Developers, security teams, vendors, and attackers now see different risks

Developers will see friction first. They want the assistant close to the terminal because that’s where it saves time. But DuneSlide shows why “automatic” needs limits when the assistant is processing untrusted text.

Security teams will read the same facts differently. An AI IDE is not just editor software. It touches endpoint security, source control, model behavior, local automation, and developer identity. That makes ownership messy. It also makes blind spots likely.

Vendors face the hardest credibility problem. “Sandboxed” is no longer enough as a claim. Buyers will want to know how working directories are validated, how symlinks are resolved, when users are prompted, and whether the model can steer tool execution into unsafe states.

Attackers, meanwhile, will notice the target value. XOOMAR analysis: developer machines can be attractive because they may have access to source code, build systems, API tokens, SSH keys, or deployment workflows. The supplied reporting does not say DuneSlide was exploited in the wild, but the impact category explains why this class of bug deserves fast remediation.

For related XOOMAR coverage on AI tools and code execution risk, see Claude Desktop Betrays Developers in Code Execution Attack. For a separate file-access risk thread, see One Click Lets DeepSeek Ransomware Raid Your Files.

The old pattern returns: trusted productivity tools become attack platforms

DuneSlide fits a long-running security pattern. When trusted productivity software automatically parses attacker-controlled input and connects that input to powerful local capabilities, remote code execution becomes a recurring failure mode.

The AI IDE twist is the input format. The dangerous payload does not have to look like a traditional executable. It can be ordinary prose that steers an agent toward unsafe behavior.

That puts prompt injection closer to command injection and confused deputy failures than many product teams may want to admit. The model is not merely answering a question. It is mediating access to tools. If the model can be tricked into using those tools across weak boundaries, the security model depends on validation code, permission checks, and sandbox design, not on the assistant “understanding” intent.

The next control point is local authority, not model quality

Cursor has patched the two reported DuneSlide flaws. That closes the known defects described by Cato. It does not close the broader design question.

Security teams should treat AI-powered IDEs as local agents with execution rights, not chat widgets inside an editor. Practical controls follow from that premise:

• Patch: Move Cursor installations to Cursor 3.0 or later.
• Inventory: Track where AI coding tools are installed and which repositories they can access.
• Restrict: Limit automatic terminal execution where possible.
• Separate: Keep sensitive workspaces away from experimental AI workflows.
• Monitor: Add endpoint visibility around unusual writes to sandbox binaries or tool executables.
• Review: Test how AI IDEs handle symlinks, working directories, file writes, and untrusted text ingestion.

The next evidence to watch is narrow and concrete: whether future AI IDE disclosures involve the same ingredients, prompt injection, automatic tool use, weak path validation, and sandbox escape. If that pattern repeats, DuneSlide won’t look like an isolated Cursor bug. It will look like an early warning about giving AI coding assistants local authority before containment caught up.

Impact Analysis

• The flaws show that AI coding assistants can become a path from malicious prompts to OS-level remote code execution.
• Developer machines often hold source code, credentials, and production access, making compromised IDEs high-value targets.
• Teams need to verify Cursor 3.0 or later is deployed and reassess permissions granted to AI development tools.