Vulnerability Analysis

DuneSlide (CVE-2026-50548 & CVE-2026-50549): Critical Zero-Click RCE in Cursor IDE — What It Is & How to Fix It

Executive Summary

Two critical remote code execution vulnerabilities — collectively named DuneSlide and tracked as CVE-2026-50548 and CVE-2026-50549 — were discovered in Cursor IDE, the AI-powered development environment reported to be used by over half of the Fortune 500. Both vulnerabilities score 9.8 on CVSS 3.1 (9.3 on CVSS 4.0) and allow a threat actor to escape Cursor's built-in terminal sandbox via zero-click prompt injection, ultimately achieving full, unsandboxed remote code execution on a developer's machine and any connected SaaS workspaces. A patch was shipped in Cursor 3.0 (released April 2, 2026) — if you haven't updated, do it now.

1. What Is This Vulnerability?

Cursor IDE ships with an agentic mode that can autonomously execute terminal commands inside a sandbox without prompting the user for every action. The sandbox is designed to prevent approval-fatigue while theoretically limiting the blast radius of any malicious command.

DuneSlide breaks that sandbox in two entirely independent ways. Both attack paths share the same entry point: prompt injection — hidden instructions embedded in content that the Cursor agent reads on behalf of the developer, such as a response from a connected MCP (Model Context Protocol) server or a poisoned web search result. The developer does nothing more than issue an ordinary prompt; the injected payload does the rest.

Attack Vector #1: Working Directory Parameter Manipulation (CVE-2026-50548)

When the Cursor agent executes a sandboxed terminal command via its run_terminal_cmd tool, it builds a macOS seatbelt (sandbox) policy that restricts file writes to the current working directory. By default, that directory is the project root — safe.

The flaw: working_directory is an optional parameter on the tool, and when the LLM assigns it a non-default value, Cursor blindly adds that path to the sandbox's allowed-write list without validation. A malicious prompt injection can steer the LLM to set working_directory to a sensitive system path outside the project, such as:

/Applications/Cursor.app/Contents/Resources/app/resources/helpers/

By writing to the cursorsandbox binary at that path, the attacker replaces the sandbox enforcement mechanism itself. Every subsequent command in the same injection session runs outside the sandbox — full unsandboxed RCE.

Other abusable write targets demonstrated in the disclosure:

  • ~/.zshrc / ~/.zshenv — persist malicious shell hooks across every terminal session
  • ~/Library/LaunchAgents/ — establish persistent background execution on macOS

Attack Vector #2: Symlink Canonicalization Failure (CVE-2026-50549)

Cursor attempts to validate file write targets by canonicalizing paths (resolving symlinks) and confirming the real destination stays inside the project root. The bug lies in the fallback behavior when canonicalization fails.

If the symlink target doesn't exist, or if read permission is denied on one of the directories in the path, Cursor gives up and trusts the original in-project symlink path rather than rejecting the operation. A prompt injection can:

  1. Instruct the Cursor agent to create a symlink inside the project directory pointing to the cursorsandbox binary
  2. Arrange for the canonicalization check to fail (e.g., make the target path temporarily unreadable)
  3. Use Cursor's Write tool to overwrite the binary through the symlink

With the sandbox binary replaced, the same result follows: all subsequent commands in the injection session execute without restriction.

Real-World Impact

A developer using Cursor with an MCP connector (such as the official Linear, Slack, or GitHub integrations) can be compromised by content served from those connectors if an attacker is able to embed prompt injection payloads in issues, documents, or messages the agent retrieves. Likewise, a malicious actor who can influence a web search result returned to Cursor's agent context gains the same foothold — with no interaction from the victim beyond typing a normal prompt.

Full system compromise includes:

  • Exfiltration of source code, secrets, and credentials from the developer's machine
  • Persistence via shell RC files or launch agents
  • Lateral movement into connected SaaS workspaces (GitHub, Jira, Slack, etc.) using tokens cached by the IDE

2. Who Is Affected?

Factor Detail
Affected versions Cursor IDE < 3.0 (all platforms)
Patched version Cursor IDE 3.0 (released April 2, 2026)
Operating systems macOS (primary PoC target), Linux, Windows
Risk amplifiers Using Cursor in Agentic mode with MCP connectors enabled; auto-approval of terminal commands (default in 2.x)
Not affected Cursor 3.0 and later; users who have disabled agentic terminal execution entirely

Any team where developers use Cursor for day-to-day coding — particularly with third-party MCP integrations enabled — is within the blast radius. Given Cursor's stated Fortune 500 penetration, exposure in enterprise development environments is substantial.

3. How to Detect It (Testing)

Check Your Cursor Version (First Step)

Before any testing, confirm which version of Cursor is installed:

# macOS / Linux — check application version
cat /Applications/Cursor.app/Contents/Resources/app/package.json | grep '"version"'

# Or from inside Cursor
# Help → About Cursor

Any version string below 3.0.0 is vulnerable.

Manual Testing Steps

Step 1 — Verify sandbox binary integrity (CVE-2026-50548 indicator)

# Check if the cursorsandbox binary has been modified recently
ls -la /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox
stat /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox

# Compare its hash against a known-good Cursor 2.x installation
shasum -a 256 /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox

An unexpected modification time or hash mismatch suggests exploitation has already occurred.

Step 2 — Check for suspicious symlinks in project directories

# Find symlinks pointing outside the project root (CVE-2026-50549 indicator)
find /path/to/your/project -type l | while read link; do
    target=$(readlink -f "$link" 2>/dev/null || readlink "$link")
    if [[ "$target" != /path/to/your/project/* ]]; then
        echo "External symlink: $link -> $target"
    fi
done

Step 3 — Audit shell RC files and LaunchAgents for injected code

# Check for unexpected additions to shell configuration files
tail -50 ~/.zshrc ~/.zshenv ~/.bashrc ~/.bash_profile 2>/dev/null

# Check LaunchAgents for unexpected entries (macOS)
ls -la ~/Library/LaunchAgents/
cat ~/Library/LaunchAgents/*.plist 2>/dev/null

Step 4 — Confirm auto-approval terminal setting (risk assessment)

In Cursor 2.x, open Settings and verify whether "Auto-approve terminal commands" is enabled. If it is, exposure to both vulnerabilities is maximized.

Automated Scanning

Tool: File Integrity Monitoring (AIDE / Tripwire)

# Initialize a baseline of Cursor binary files
aide --init
# Later checks
aide --check

Tool: osquery (endpoint monitoring)

-- Detect recently modified Cursor binary components
SELECT path, mtime, size, sha256
FROM file
WHERE path LIKE '/Applications/Cursor.app/Contents/Resources/app/resources/helpers/%'
AND mtime > (strftime('%s', 'now') - 86400);

-- Detect suspicious symlinks in common project directories
SELECT path, symlink
FROM file
WHERE path LIKE '/Users/%/projects/%'
AND type = 'symlink'
AND symlink NOT LIKE '/Users/%/projects/%';

Tool: Semgrep / Static Analysis (for MCP server authors)

# If you maintain an MCP server, scan your output templates for prompt injection
# patterns that could be abused against Cursor agents
semgrep --config "p/prompt-injection" ./mcp-server-src/

Code Review Checklist

For teams building or auditing MCP servers that connect to Cursor:

  • Scan all content returned to the LLM context for untrusted user-controlled strings
  • Ensure your MCP server does not reflect issue titles, document bodies, or comments directly into agent responses without sanitization
  • Review whether your connector pulls content from external URLs that could be attacker-controlled
  • Verify your MCP server's output cannot embed instructions in Markdown comments, hidden Unicode, or base64

4. How to Fix It (Mitigation)

Step-by-Step Remediation

1. Update Cursor to version 3.0 or later immediately

This is the only complete fix. Both CVE-2026-50548 and CVE-2026-50549 are patched in Cursor 3.0.

# macOS — download from the official Cursor site
# https://www.cursor.com/

# Verify you are now on 3.0+
cat /Applications/Cursor.app/Contents/Resources/app/package.json | grep '"version"'
# Expected: "version": "3.x.x"

2. If update is not immediately possible — disable agentic auto-approval

In Cursor 2.x, navigate to:

  • Settings → Cursor Settings → Features → Terminal
  • Disable: "Auto-run terminal commands" / "Auto-approve terminal commands"

With auto-approval disabled, each terminal command requires explicit user confirmation, giving you a chance to spot injected commands before they execute. Note: this is a workaround, not a fix — the sandbox bypass still exists; it simply requires user interaction to trigger.

3. Audit and disable high-risk MCP connectors

Temporarily disable MCP connectors that pull content from sources you don't fully control (public issue trackers, external documentation, open web searches) until the IDE is patched:

  • Go to Settings → MCP in Cursor 2.x
  • Remove or disable connectors that access external/user-controlled content
  • Keep only tightly-scoped connectors you trust

4. Restore the cursorsandbox binary if compromise is suspected

If you believe exploitation may have already occurred on a Cursor 2.x installation, reinstalling Cursor from scratch is the safest path. Do not simply copy-patch the binary:

# Full removal and clean reinstall (macOS)
rm -rf /Applications/Cursor.app
# Download Cursor 3.0 fresh from https://www.cursor.com

Configuration Hardening

Even after patching to Cursor 3.0, apply these hardening measures:

  • Principle of least privilege for MCP connectors: Grant each connector only the scopes it actually needs. Do not use org-admin tokens for connectors.
  • Separate profile / credentials for Cursor: Avoid storing primary SSH keys, AWS credentials, or high-privilege tokens in the same keychain accessible from Cursor's process.
  • Enable macOS System Integrity Protection (SIP): SIP prevents write access to certain system paths even if a user-land process is compromised. Verify it's enabled: csrutil status

5. How to Test the Fix (Validation)

Regression Test Scenarios

Scenario A: Confirm working_directory restriction is enforced (CVE-2026-50548 fix)

After updating to Cursor 3.0, attempt to use the run_terminal_cmd tool with a working_directory value pointing outside the project root. In the patched version, this should be rejected or the path should not be added to the sandbox allow-list.

Expected behavior: the command either fails with a permission error or Cursor ignores the out-of-scope working_directory and defaults to the project root.

Scenario B: Confirm symlink out-of-bounds write is blocked (CVE-2026-50549 fix)

Create a symlink inside a test project directory pointing to a file outside the project:

# Setup: create a symlink in a test project to an external file
mkdir -p /tmp/test-project && cd /tmp/test-project
ln -s /tmp/external-target.txt ./external-link.txt

Attempt to have Cursor's agent write to ./external-link.txt via the Write tool. In the patched version, the write should be blocked because the canonicalized destination lies outside the project root.

Expected behavior: write is rejected with a permission or security error.

Scenario C: No regression in normal file writes

Confirm that legitimate writes within the project root continue to work normally after the patch.

# Should succeed in Cursor 3.0
echo "test" > /tmp/test-project/normal-file.txt

Security Test Cases

Test Case 1: Verify working directory sandbox hardening

  • Precondition: Cursor 3.0 installed; agentic mode enabled
  • Steps: Prompt Cursor to run a terminal command with a crafted system-path working directory
  • Expected Result: Command executes in project root or is rejected; system paths are not written

Test Case 2: Verify symlink resolution enforces project bounds

  • Precondition: Cursor 3.0 installed; external symlink created in test project
  • Steps: Prompt Cursor to write to the symlink target
  • Expected Result: Write fails; no file created at external path

Test Case 3: Verify no user-visible regression

  • Precondition: Cursor 3.0 installed; normal project open
  • Steps: Ask Cursor to create, edit, and delete files within the project
  • Expected Result: All operations succeed as normal; no security dialogs for in-project paths

Automated Tests

If you are building a Cursor automation harness or security test suite:

import subprocess
import os
import tempfile

def test_working_directory_sandbox():
    """
    Ensures Cursor's sandbox does not allow writes outside the project root
    via the working_directory parameter.
    This is a behavioral check — run against a Cursor 3.0 API or log analysis.
    """
    external_path = "/tmp/canary_duneslide_test.txt"
    if os.path.exists(external_path):
        os.remove(external_path)
    
    # Simulate what an injected payload would attempt:
    # (In a real test harness, invoke Cursor's MCP interface)
    # Expected: external_path should NOT be created
    
    assert not os.path.exists(external_path), (
        "FAIL: Cursor wrote outside project root via working_directory — patch not applied!"
    )
    print("PASS: working_directory restriction enforced")


def test_symlink_canonicalization():
    """
    Ensures Cursor's Write tool does not follow symlinks to external paths.
    """
    with tempfile.TemporaryDirectory() as project_dir:
        external_canary = "/tmp/canary_symlink_duneslide.txt"
        symlink_path = os.path.join(project_dir, "external-link.txt")

        if os.path.exists(external_canary):
            os.remove(external_canary)
        
        # Create a symlink inside project pointing outside
        os.symlink(external_canary, symlink_path)
        
        # Simulate Cursor Write tool attempt through the symlink
        # Expected: write should be blocked in Cursor 3.0
        
        assert not os.path.exists(external_canary), (
            "FAIL: Cursor followed symlink to external path — patch not applied!"
        )
        print("PASS: symlink canonicalization enforced")

6. Prevention & Hardening

Best Practices

1. Keep AI coding tools updated as a first-class security obligation

DuneSlide illustrates that AI-powered IDEs now carry an attack surface previously unassociated with development tools. LLM-driven tools that can execute code must be treated with the same urgency as web browsers or runtime platforms when vulnerabilities are disclosed. Establish a policy: patch AI development tools within 24–48 hours of a critical disclosure.

2. Apply the principle of minimal MCP surface area

Each MCP connector extends the trust boundary of your IDE. A connector that reads GitHub Issues, for instance, means attacker-controlled issue body text can reach Cursor's agent context. Audit your MCP integrations regularly:

  • Remove connectors not actively in use
  • Prefer read-only scopes where possible
  • Prefer connectors from vendors with documented security disclosure processes

3. Isolate developer machines from production credentials

If an attacker achieves RCE on a developer's workstation, their first move is credential harvesting. Minimize the impact by:

  • Using separate AWS profiles / IAM roles for development vs. production
  • Not storing production database credentials or signing keys on developer machines
  • Using hardware security keys (YubiKey) for critical SaaS accounts, so stolen session tokens are insufficient for persistent access

4. Apply content security policies to internal MCP servers

If your team runs internal MCP servers (Jira, Confluence, internal wikis), output-sanitize all user-generated content before it enters agent context. Treat it the same as XSS output encoding — any user-controlled string that reaches the LLM context is a potential injection vector.

Monitoring & Detection

Detect the attack in progress (before patch is applied)

# Monitor cursorsandbox binary for unexpected writes (macOS)
# Run with launchd or a monitoring daemon
fswatch -o /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox | \
    xargs -n1 -I{} bash -c 'echo "[ALERT] cursorsandbox modified at $(date)" | tee -a /var/log/cursor_integrity.log'

# Or using auditd on Linux
auditctl -w /path/to/cursorsandbox -p w -k cursor_sandbox_write

Monitor shell RC files for unexpected modifications

# Set file integrity alerts on shell configuration files
auditctl -w ~/.zshrc -p w -k shell_rc_write
auditctl -w ~/.bashrc -p w -k shell_rc_write

# Review audit log for alerts
ausearch -k shell_rc_write

SIEM detection rule (pseudo-Sigma)

title: Cursor Sandbox Binary Modified
status: experimental
description: >
  Detects writes to the Cursor IDE sandbox helper binary, which may indicate
  exploitation of CVE-2026-50548 or CVE-2026-50549 (DuneSlide).
logsource:
  category: file_event
  product: macos
detection:
  selection:
    TargetFilename|contains: 'Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox'
    EventType: 'FileCreate'
  condition: selection
falsepositives:
  - Legitimate Cursor update installations
level: high
tags:
  - attack.execution
  - cve.2026-50548
  - cve.2026-50549

References

Latest from the blog

See all →