Is Cursor Safe? Not Entirely, Here's Every Real Cursor Security Risk

Is Cursor safe? Not entirely, but not for the reason most people assume. Cursor has shipped three critical, disclosed vulnerabilities since 2025: CurXecute (CVSS 9.8), MCPoison (CVSS 8.8), and a path-traversal flaw (CVE-2025-32018, CVSS 8.0). All three were patched quickly once reported, and Cursor runs a public security program and bug bounty. That's the good part. The part that doesn't go away with an update: Cursor changes the economics of software creation. It does not change the economics of security failure. Even on a fully patched install, the code Cursor generates for your app carries a separate, ongoing risk that no version bump fixes.

This guide covers both layers: the real CVEs Cursor has patched, and the code-generation risk that persists regardless of which version you run.

Cursor's Real, Disclosed Vulnerabilities

Two of these three target the same file: .cursor/mcp.json. That's not a coincidence, it's the highest-value attack surface in Cursor right now, because it controls which tools your AI agent can invoke. Writing to it is a form of MCP impersonation: once an attacker controls that file, they control what your agent can execute, silently.

What this means in practice: if your team is running any Cursor version before 1.3.9, you are exposed to a critical, actively-documented RCE path. Updating is the fix, and it's the single highest-leverage action on this page.

The Risk That Doesn't Go Away With an Update

Here's the part patching doesn't solve: Cursor produces code that works before it produces code that's authorized correctly, and that gap exists on every version, patched or not.

The failure mode in Cursor-assisted apps is rarely bizarre code. It's reasonable-looking code, accepted too quickly. That matters most in exactly the areas our Cursor security checklist tells you to slow down for: authorization, JWT handling, and environment variable boundaries, the parts of an app where "looks right" isn't good enough.

The common Cursor edge case

One pattern we keep seeing: a generated helper that centralizes access to "make auth easy," but accidentally normalizes unsafe trust in client-provided identity.

export async function updateWorkspace(input: {
  workspaceId: string;
  name: string;
}) {
  const session = await getSession();

  if (!session) throw new Error("Unauthorized");

  return db.workspace.update({
    where: { id: input.workspaceId },
    data: { name: input.name },
  });
}

The code checks authentication. It does not check ownership. Any authenticated user can update any workspace by ID, a textbook case of broken access control introduced by well-intentioned automation, not malice.

This gets worse across a larger refactor. One prompt touching four files can silently remove the check from three of them while leaving the fourth intact, and every test still passes because the tests never covered the wrong-user case in the first place.

Review the Places Cursor Helps the Most

The more Cursor accelerates a workflow, the more carefully that workflow needs security review:

• Route handlers and Next.js Server Actions
• SQL and Prisma mutations
• Auth middleware and session validation
• Vendor SDK setup (Stripe, Supabase, auth providers)
• File upload flows and storage access
• .cursor/mcp.json and any MCP tool definitions

These are exactly the areas where a small hallucination, or a single unpatched CVE, becomes a production flaw.

The Entities to Care About

When reviewing Cursor-generated code, don't over-focus on the phrase "AI security." Focus on the actual entities that decide whether access is authorized:

• JWT payloads, especially forged or unvalidated claims
• RLS policies, if the app runs on Supabase
• Environment variable injection and exposed API keys in frontend code
• Client-side hydration and trust boundaries
• Storage buckets and signed URL enforcement
• Admin-only routes and privilege escalation paths

These are the places real access models live or fail, regardless of which Cursor version generated them.

Cursor Security Risks: Complete Pre-Launch Checklist

Critical (Ship Blockers)

• Cursor is updated past version 1.3.9 (closes CurXecute and MCPoison)
• .cursor/mcp.json reviewed for tool definitions you did not explicitly add
• Every mutation has an ownership check, not just an authentication check
• No secrets pasted into Cursor chat history remain unrotated

High Priority

• Auth middleware re-verified after every agent-assisted refactor
• Every generated abstraction tested against an adversarial (wrong-user) case
• Admin flows isolated from standard user mutation paths
• Dependency suggestions checked for typosquatting before install

Production Hardening

• Workspace Trust enabled, untrusted repos never auto-trusted
• Every secret classified correctly (server-only vs. safe to expose)
• Every auth claim traced back to a server-verified source, not a client-supplied one

Cursor can absolutely be part of a secure workflow. It just can't be the reviewer of its own assumptions, and as of 2026, it's had three confirmed reasons why.

Cursor is one of many AI builders that ship this class of flaw. For the full picture across every AI-built stack, see our AI code security guide.

Run a free URL scan, no signup required. You only pay if it actually finds something, and if it does, paid plans unlock the full report, exact AI fix prompts, PDF export, and deeper audit coverage.