Is Cursor secure?

Editor vulnerabilities — patched in Cursor 2.0

CurXecute (CVE-2025-54135) was the most severe: a malicious MCP server could send specially crafted tool responses that caused Cursor to rewrite its own configuration, and with Auto-Run enabled, that led to arbitrary command execution on your machine without any user prompt. CVE-2025-59944 let attackers bypass file-protection rules through case-sensitivity differences, so files you thought Cursor could not read were accessible. CVE-2025-64110 was an information-disclosure bug where content matched by .cursorignore rules could still be included in the model's context, leaking secrets or proprietary code you intended to exclude. All three share a root cause: prompt injection from untrusted input. All are fixed in Cursor 2.0 — update immediately. Going forward, install MCP servers only from sources you trust, and leave Auto-Run off unless you are actively using it on a repository you own.

Hardcoded API keys and connection strings

When Cursor needs a credential to make an integration work, the path of least resistance is to write the literal value into the source file. That gets the feature running immediately, which is what Cursor is optimizing for. The key then ships into your git history, and if it is used in a client component or a file with a NEXT_PUBLIC_ prefix, it also ships to every visitor's browser in the JavaScript bundle. We found hardcoded secrets in roughly 1 in 10 Cursor-built apps we scanned. The fix is to set the key as an environment variable immediately and use process.env.KEY_NAME instead. Add a .cursor/rules file that instructs Cursor never to inline credentials.

Secrets committed in .env files

Cursor often creates or modifies a .env file to store configuration. If .env is not listed in .gitignore before that first commit, the file goes into the repository. A public repository push exposes every secret in it within seconds — automated scanners watch GitHub for newly committed credentials and begin trying them within minutes of the push. The fix is simple but must happen before the first commit: confirm that .env, .env.local, and .env.production are all in .gitignore, and run git status before every push to verify no env file is staged.

API routes without authorization checks

Cursor generates route handlers that satisfy the feature requirement: the UI calls the route, data comes back, and the feature works. What is not required for the feature to work is a server-side check that the calling user is allowed to access that data. So Cursor often omits it. The result is an API route that returns or mutates data for any caller, authenticated or not. This is the most common issue in Cursor-built apps: a /api/user/profile route that returns any user's data when called with their ID, or a /api/admin endpoint that runs without checking whether the caller is actually an admin. Add an explicit auth check — session validation or a JWT verify — at the top of every route that reads or writes user data.

Your code sent to Cursor's servers

Cursor sends your code to its servers (and through them to the underlying model provider, currently Claude and GPT-4o) to generate completions. In Privacy Mode, Cursor's policy is that code is not retained or used for training, but it is still transmitted. For codebases containing proprietary algorithms, unreleased product code, or data covered by compliance requirements (HIPAA, SOC 2, PCI), review Cursor's data handling policy and your organization's rules before enabling AI completions. Cursor for Business and Enterprise add contractual data-processing guarantees; the free tier does not.