← All tools

AI coding IDE security

Is Cursor secure?

We scanned nearly 2,000 AI-built apps and 1 in 8 shipped a high-severity flaw. Is your Cursor app one?Scan free β†’

Is Cursor safe is really two questions. Is the editor itself safe to run: mostly yes, if you keep it updated, since a cluster of real prompt-injection and remote-code-execution vulnerabilities found in 2025 are all patched in Cursor 2.0. Is the code Cursor writes for you secure: not automatically. Cursor optimizes for code that runs, so when an integration needs a key it tends to inline the value, and when it wires up an API route it often skips the authorization check that is not needed to make the feature work. That second question is the one that reaches your users, because a shipped vulnerability does not get closed by an update the way an editor CVE does.

From our scan data

A cluster of real 2025 CVEs in the Cursor editor (CurXecute and related bugs) are all patched in Cursor 2.0. Updating closes the editor risk; it does nothing for the code Cursor already wrote for you.

The risks that actually matter

Editor CVEs from prompt injection (patched in Cursor 2.0)

In 2025, researchers found CurXecute (CVE-2025-54135), where a malicious MCP server could rewrite Cursor's config so that, with Auto-Run enabled, injected commands executed on your machine. Related bugs CVE-2025-59944 (a case-sensitivity file-protection bypass) and CVE-2025-64110 (a cursorignore information-disclosure bug) shared the same root cause: prompt injection from untrusted repositories or MCP servers. All are fixed in Cursor 2.0. Update, and keep Auto-Run off for code you do not trust.

Hardcoded API keys and connection strings

When a step needs a credential, Cursor frequently writes the literal value into the file so the code runs immediately. That key then ships to the repo and, if the value is used client-side, to the browser.

Committed .env files

Cursor may create a .env with real values and, without a matching .gitignore entry, it gets staged and pushed. A public push exposes every secret in it within minutes.

API routes without authorization

Generated route handlers commonly return or mutate data without checking who is calling. The UI hides the route, but anyone can call it directly.

How to secure a Cursor app

  • Update to Cursor 2.0 or later and keep Auto-Run off for repositories or MCP servers you do not trust.
  • Add a .cursor/rules or AGENTS.md rule forbidding inline secrets and requiring process.env.
  • Confirm .env and .env.local are gitignored before your first commit.
  • Add a server-side auth check to every API route that reads or changes data.
  • Scan the project for hardcoded keys and missing auth before you deploy.

Check your Cursor app for these issues in seconds. Scan your live app or a public repo free, no account.

Scan my app β†’

Related: fix an exposed Cursor API key

Cursor Security: Is Cursor-Generated Code Safe? Risks & Fixes: Prbl