← Back to Feed CACHED · 2026-07-03 10:12:51 · CACHE_KEY CVE-2026-50548
CVE-2026-50548 · CWE-22 · Disclosed 2026-06-25

Cursor is a code editor built for programming with AI

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

The AI assistant treats an attacker-controlled note like a boss's memo and quietly rewrites the guardrails around it

CVE-2026-50548 is a path-traversal / sandbox scoping bug in the Cursor AI code editor's run_terminal_cmd tool. When the agent invokes a shell command, it can pass an optional working_directory parameter. Cursor's automatic terminal sandbox blindly appends that path to the *allowed write list*. If an attacker plants an indirect prompt-injection payload — via a poisoned MCP server response, a search-result blob, a README the agent reads, or a compromised dependency doc — the LLM can be steered to set working_directory to a sensitive path (e.g. the folder holding the cursorsandbox helper binary) and then overwrite that helper. Subsequent shell invocations execute *outside* the sandbox as the developer's user. Every Cursor build prior to 3.0 (released 2026-04-02) is affected; the fix stopped adding arbitrary agent-supplied paths to the allowlist.

The vendor label of CRITICAL / 9.8 (AV:N/AC:L/PR:N/UI:N) is the CVSS treatment you get when a scoring team assumes 'network-reachable code execution with no interaction.' In reality the attacker must (a) get untrusted content in front of the agent, (b) win a prompt-injection race against Cursor's guardrails, and (c) rely on the victim actually running an AI-assisted session. And when it lands, it lands on one developer workstation — not a server tier, not a domain controller. This is a real bug worth patching, but 9.8 misreads it. Reassessed as MEDIUM (6.2): unauthenticated conceptually, but the exploitation surface is a running IDE session and the blast radius is a single user's endpoint.

"Prompt-injection RCE on a developer laptop — real, but blast radius is the dev's own machine, not the fleet. Vendor's 9.8 is inflated."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Stage the prompt-injection payload

Attacker plants malicious instructions in a resource the Cursor agent will ingest — a rogue MCP server, a poisoned web page returned by an in-agent search, a crafted README, GitHub issue body, or package documentation. Weaponized delivery vehicles observed in the DuneSlide research include hostile MCP tool descriptions and prompt-injection-laced search results.
Conditions required:
  • Target developer uses Cursor <3.0 with agent mode / auto-run enabled
  • Attacker controls or taints a data source the agent reads
Where this breaks in practice:
  • Requires the developer to point the agent at attacker-influenced content
  • Enterprises restricting MCP servers to an allowlist cut this off
Detection/coverage: No CVE-specific IDS signature; EDR sees Cursor as a normal Electron app. DLP/egress monitoring may flag unusual MCP endpoints.
STEP 02

Coerce the agent to invoke run_terminal_cmd with a rogue working_directory

The injected instructions direct the LLM to call the run_terminal_cmd tool with working_directory pointed at a sensitive path — typically the directory containing the cursorsandbox helper binary or another auto-executed launcher. Cursor's sandbox layer adds that path to the allowed-write list without validating that it is inside the workspace root.
Conditions required:
  • Agent has terminal tool enabled
  • Auto-approve / YOLO mode active, or user clicks Allow
Where this breaks in practice:
  • Users who leave manual command approval on will see the odd path and reject
  • Cursor's default policy in later 2.x asked for approval on non-workspace paths
Detection/coverage: Cursor's own audit log records tool invocations; no external scanner covers this.
STEP 03

Overwrite the cursorsandbox helper

With the extended write allowlist, the agent's next shell command drops attacker-controlled bytes over cursorsandbox (or an equivalent trusted launcher). The DuneSlide PoC by Cato AI Labs (Itay Ravia) demonstrated this replacement in seconds via a single tool call.
Conditions required:
  • Write permission on the helper's install location under the user's UID
  • Helper path predictable across installs
Where this breaks in practice:
  • Per-user install locations vary slightly across OS; MDM-managed installs owned by root/Admin block user-writable replacement
Detection/coverage: File integrity monitoring on developer endpoints (rare) would catch the write. EDR behavioral rules on .app or install-dir modification by an Electron helper are effective.
STEP 04

Escape the sandbox on next invocation

The next agent-issued terminal command runs the *replaced* helper — which no longer enforces the sandbox. From there the payload runs with the developer's full user privileges: read SSH keys, cloud creds in ~/.aws, source in private repos, git credentials, browser session cookies, and any locally-cached SSO/OIDC tokens.
Conditions required:
  • Agent issues another terminal call in the same session
Where this breaks in practice:
  • Closing/restarting Cursor before the second call defuses the chain if the write hasn't been read yet
Detection/coverage: EDR sees a child process of Cursor with anomalous exec — this is where XDR/behavioral detection usually catches it.
STEP 05

Pivot from developer workstation

Attacker uses harvested credentials to reach cloud consoles, private git, artifact registries, or internal apps that trust the developer's SSO. In the worst case, if the victim is a maintainer of a widely-consumed package or holds CI push rights, this becomes a supply-chain incident. This is the pivot that makes this bug matter for a defender running 10,000 hosts.
Conditions required:
  • Long-lived cloud creds on disk
  • SSO cookies unlocked
  • Git push rights without hardware-token signing
Where this breaks in practice:
  • Short-lived STS creds, WebAuthn/hardware-key signing on commits, and PAM-mediated cloud access break the pivot
Detection/coverage: Identity provider anomaly detection (impossible travel, new device); cloud CSPM/CIEM alerts on credential misuse.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation as of 2026-07-03. Public PoC exists via the DuneSlide research; no KEV listing.
Proof-of-conceptCato Networks blog *DuneSlide* by Itay Ravia demonstrates the working_directory sandbox escape end-to-end. No Metasploit module.
EPSS0.00637 (~0.6%) — bottom quartile, consistent with a client-side, session-dependent bug
KEV statusNot listed by CISA as of 2026-07-03
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — the AV:N/UI:N scoring is generous; realistic exposure requires the agent to ingest attacker content
Affected versionsAll Cursor releases < 3.0 (2.x branch and earlier)
Fixed versionCursor 3.0 (released 2026-04-02); no distro backports — Cursor is a self-updating Electron app
Exposure telemetryGreyNoise/Shodan/Censys not applicable — Cursor is an endpoint IDE, no listener. Population = users of Cursor <3.0 with agent mode enabled.
Disclosure timelineReported 2026-02-19, fix confirmed 2026-04-01, CVE assigned 2026-06-05, published 2026-06-25
ResearcherItay Ravia, Head of Cato AI Labs (Cato Networks)
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.2/10)

Downgraded from CRITICAL to MEDIUM because the decisive factor is blast radius: the bug executes on a single developer workstation inside a live IDE session, not on a server, hypervisor, or identity plane. It is a real RCE, but the CVSS AV:N label misrepresents a client-side, prompt-injection-triggered chain as if it were network-reachable service exploitation.

HIGH Technical mechanism and affected-version range
HIGH Patch availability in Cursor 3.0
MEDIUM Real-world exploitation prevalence — client-side bugs rarely surface in public telemetry

Why this verdict

  • Client-side scope: The affected component is an IDE running on developer laptops. Blast radius is one user's endpoint per successful chain, not a shared service. This removes the AV:N assumption baked into the 9.8.
  • Requires agent-mode session + tainted input: Exploitation is impossible unless a Cursor agent session is actively running AND the agent is fed attacker-controlled content (MCP, search result, poisoned repo). This is post-social-engineering-adjacent friction, not drive-by.
  • Approval-gate friction: Users who did not enable YOLO/auto-run see the anomalous working_directory in an approval prompt and can reject. That kills the chain before the sandbox write.
  • Fully patched, no listener, no fleet-wide scan target: Cursor auto-updates; the population on <3.0 shrinks weekly. GreyNoise/Shodan cannot enumerate it because there is no listening service.
  • Role multiplier — developer workstation: Typical role. Chain succeeds with outcome = credential/source theft on one endpoint. Serious for that user, but does not escalate to fleet takeover by itself.
  • Role multiplier — maintainer / release-engineer workstation: Chain succeeds; outcome escalates to supply-chain pivot if the victim pushes signed releases or has CI publish rights. This is the reason the verdict is not LOW — but this cohort is <5% of a typical Cursor install base, so it sets pressure toward HIGH without breaking the MEDIUM floor.
  • Role multiplier — CI/CD build agent running Cursor: Not a canonical deployment. Cursor is not typically installed on shared build infrastructure, so this role does not apply.

Why not higher?

Not HIGH because the affected component is not a canonical high-value-role component (not a hypervisor, IdP, PAM, CA, backup server, or kernel-mode agent). The chain requires an active agent session ingesting attacker-tainted content, and outcome is per-endpoint compromise rather than fleet or identity-scale impact. Supply-chain escalation is possible for a narrow maintainer cohort but does not represent the installed base.

Why not lower?

Not LOW because a working PoC exists, exploitation requires no privileged position (unauthenticated content injection through MCP/search is realistic), and post-exploitation on a developer machine yields SSH keys, cloud creds, and git push rights that DO give attackers a foothold into higher-value systems. Developer endpoints are a well-known pivot target.

05 · Compensating Control

What to do — in priority order.

  1. Force-upgrade Cursor fleet to ≥3.0 — Roll the upgrade through MDM (Jamf, Intune, Kandji) or block launch of older builds via app control. This is the fix — every other control is a workaround. Deploy within the noisgate remediation SLA of 365 days, but realistically finish within 30 days because the population is self-updating anyway.
  2. Disable Cursor auto-run / YOLO mode via managed policy — Require manual approval for run_terminal_cmd. This forces the anomalous working_directory value in front of the user before the sandbox is expanded. Push via Cursor's enterprise settings JSON deployed by MDM immediately — no mitigation SLA under MEDIUM, but this is a same-week config change.
  3. Restrict MCP servers to an enterprise allowlist — Untrusted MCP servers are the primary indirect-prompt-injection vector. Publish an internal registry and block outbound to arbitrary MCP endpoints at the proxy. Ties into your existing egress controls.
  4. Rotate developer cloud credentials to short-lived STS / OIDC-federated tokens — Assume any developer endpoint may be compromised via a client-side RCE class of bug. Killing long-lived AWS keys, GCP service account JSON, and static Azure secrets on disk breaks the pivot from stage 5.
  5. Require hardware-key commit signing for release-authority repos — Prevents the maintainer-cohort escalation into supply-chain compromise even if the workstation is popped.
  6. EDR behavioral rule: alert on Cursor helper writing to its own install directory — The cursorsandbox overwrite is the observable IOC. A single behavioral rule on 'Electron IDE modifies own launcher' catches this exploit and future variants.
What doesn't work
  • Perimeter WAF / IDS — this is a client-side bug over TLS to LLM APIs; the network sees only encrypted OpenAI/Anthropic traffic.
  • Standard AV signatures — the malicious payload is prose in a prompt, not a binary; no signature will match.
  • Blocking run_terminal_cmd outright — kills the product's utility and developers will side-load older builds or personal copies.
  • Network segmentation of developer VLAN — the attacker doesn't need inbound reachability; the exfil rides the developer's normal outbound path.
06 · Verification

Crowdsourced verification payload.

Run on each macOS/Linux developer endpoint (via your MDM's shell-execution feature, e.g. Jamf policy, Intune script, or Kandji script). Invoke as bash check-cve-2026-50548.sh under the target user's account. No elevated privileges required — Cursor lives in the user's Applications / ~/.local dir.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2026-50548.sh
# Detects vulnerable Cursor IDE installs (<3.0) — DuneSlide working_directory sandbox escape.
# Exit: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN

set -u

found=0
vulnerable=0

version_lt() {
  # returns 0 if $1 < $2
  [ "$1" = "$2" ] && return 1
  printf '%s\n%s\n' "$1" "$2" | sort -V -C
}

check_version() {
  local ver="$1" src="$2"
  found=1
  if [ -z "$ver" ]; then
    echo "UNKNOWN: could not read version from $src"
    return
  fi
  local major="${ver%%.*}"
  if ! [[ "$major" =~ ^[0-9]+$ ]]; then
    echo "UNKNOWN: unparsable version '$ver' from $src"
    return
  fi
  if [ "$major" -lt 3 ]; then
    echo "VULNERABLE: Cursor $ver at $src (<3.0)"
    vulnerable=1
  else
    echo "PATCHED:    Cursor $ver at $src"
  fi
}

# macOS system-wide install
MAC_PLIST="/Applications/Cursor.app/Contents/Info.plist"
if [ -f "$MAC_PLIST" ]; then
  v=$(/usr/bin/defaults read "${MAC_PLIST%.plist}" CFBundleShortVersionString 2>/dev/null || true)
  check_version "$v" "$MAC_PLIST"
fi

# macOS per-user install
USER_PLIST="$HOME/Applications/Cursor.app/Contents/Info.plist"
if [ -f "$USER_PLIST" ]; then
  v=$(/usr/bin/defaults read "${USER_PLIST%.plist}" CFBundleShortVersionString 2>/dev/null || true)
  check_version "$v" "$USER_PLIST"
fi

# Linux AppImage / extracted
for cand in \
  "$HOME/.local/share/cursor/resources/app/package.json" \
  "/opt/cursor/resources/app/package.json" \
  "/usr/share/cursor/resources/app/package.json"; do
  if [ -f "$cand" ]; then
    v=$(grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' "$cand" | head -1 | sed -E 's/.*"([^"]+)"$/\1/')
    check_version "$v" "$cand"
  fi
done

# CLI on PATH as last resort
if command -v cursor >/dev/null 2>&1; then
  v=$(cursor --version 2>/dev/null | head -1)
  check_version "$v" "$(command -v cursor)"
fi

if [ "$found" -eq 0 ]; then
  echo "UNKNOWN: Cursor not detected on this host"
  exit 2
fi
if [ "$vulnerable" -eq 1 ]; then
  exit 1
fi
exit 0
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: push the Cursor 3.0 upgrade through MDM to any developer laptop still on 2.x and flip the enterprise policy to require manual approval for run_terminal_cmd. Per the noisgate mitigation SLA for MEDIUM there is no formal mitigation deadline — go straight to the noisgate remediation SLA of ≤365 days, but be honest: Cursor auto-updates, so realistically this vanishes from your fleet within 30 days if you just get out of the way. Prioritize *maintainer, release-engineer, and CI-adjacent developer* endpoints first — that's the cohort where a compromised workstation escalates into supply-chain risk. Do NOT treat this as a 9.8 fire drill at the expense of your KEV-listed edge appliance backlog; the vendor CVSS is miscalibrated for a client-side IDE bug.

Sources

  1. NVD — CVE-2026-50548
  2. Cato Networks — DuneSlide research (Itay Ravia)
  3. The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox
  4. CSO Online — Sandbox bypass flaws in Cursor IDE
  5. Hard2bit — Prompt injection as an RCE vector in AI editors
  6. Mallory — DuneSlide Flaws in Cursor IDE
  7. Tenable — Cursor <3.0 Multiple Vulnerabilities
  8. OpenCVE — CVE-2026-50548
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.