Is code generated by Cursor secure?

Not by default. Cursor runs on the same models as other AI assistants, and Veracode found roughly 45% of AI-generated code introduces an OWASP Top 10 vulnerability. Expect broken access control, exposed secrets, and injection or XSS holes until you audit and fix them.

Has Cursor itself had security vulnerabilities?

Yes. Pillar Security disclosed the Rules File Backdoor, where hidden Unicode in a rules file steers the agent into writing malicious code. Check Point reported the MCPoison flaw (CVE-2025-54136), where a trusted MCP entry could be swapped for a malicious command, fixed in Cursor 1.3.

How do I use Cursor safely?

Treat output as a draft, audit access control and secrets before launch, review rules files and shared templates for hidden characters, only enable MCP servers you trust and re-approve on changes, keep Cursor updated, and pair automated scanners with a human review of authorization logic.

Is Cursor Safe? Cursor Code Security

Q: Is Cursor safe to use?

Cursor is safe to build with if you treat its output as a draft and harden your setup, but it is not safe to ship from blindly. It optimizes for code that runs, not code that's secure, so audit what it generates and lock down Cursor's own rules-file and MCP trust settings before production.

Cursor is a productivity tool, not a security tool. The code it generates carries the same roughly 45% vulnerability rate as other AI assistants, and Cursor itself has had agent and extension-level security issues. So audit both the generated code and your Cursor setup before anything reaches production.

Cursor is one of the most popular AI code editors, and it really is fast at turning out working software. But “works on my machine” and “safe to ship” are two different bars. Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code samples failed security tests and introduced an OWASP Top 10 vulnerability, and that number stayed flat even on the newer, bigger models. Cursor runs on those same models, so its output inherits the same risk. And then there’s a second layer: Cursor the app has had its own security holes at the rules-file and MCP level. This guide covers both. The flaws in what Cursor writes, and the flaws in how Cursor runs.

Is Cursor safe to use?

Yes, Cursor is safe to build with, as long as you treat its output as a draft and harden your setup. It is not safe to treat that output as production-ready by default. The editor optimizes for code that runs and matches what you asked for, not code that’s secure, so the same insecure patterns you see across every AI assistant show up in Cursor too. Add a couple of Cursor-specific attack surfaces on top (the config files and MCP servers it can execute) and the honest answer is this: safe to build with, not safe to ship from blindly. Audit what it generates, and lock down the tool’s own trust settings.

Security risks in Cursor-generated code

These are the failure modes that show up across every AI assistant, Cursor included. The good news: they cluster in the same predictable places, which is exactly what makes them auditable.

Broken access control. Cursor will happily scaffold tables and APIs with permissive defaults, no row-level security, and checks that only live in the client. Anyone who edits an ID in a URL or hits the API directly can often read or write data they have no business touching.
Exposed secrets. Keys get prefixed with NEXT_PUBLIC_ or VITE_ and ship in the browser bundle, or get committed straight into git history.
Injection and XSS. Generated handlers tend to trust user input and skip sanitization. Veracode found AI tools failed to defend against cross-site scripting in 86% of relevant samples, so unvalidated input reaching the DOM or a SQL query is a real, common hole, not a hypothetical one.
Security misconfiguration. Verbose error messages, exposed endpoints, and default-open settings that leak internals or widen the attack surface.

For the full audit sequence, see our guide on how to audit AI-generated code for security, and the background on AI-generated code security risks.

Cursor-specific risks

Beyond what it writes, Cursor has had two notable problems in the app itself. Both are real, both were reported by security researchers, and both turn a “trusted” project into something that can run attacker-controlled instructions.

The “Rules File Backdoor” (configuration poisoning)

In March 2025, Pillar Security disclosed an attack it named the “Rules File Backdoor.” Cursor reads rules files from your repo to steer how the agent behaves. An attacker can hide malicious instructions inside one of those files using invisible Unicode characters (zero-width joiners and bidirectional markers) that render as blank space to a human reviewer but parse as valid instructions to the model. The poisoned file can tell the AI to inject backdoors or quietly weaken the security of the code it writes, and because rules files travel with the repo, the poison survives a fork and spreads to every downstream project. Pillar reported that Cursor took the position that this risk falls on the user, while GitHub later added a warning when a file contains hidden Unicode text. The takeaway is simple: review rules files and shared templates exactly the way you’d review any executable code.

The MCP “MCPoison” remote-code-execution issue

In August 2025, The Hacker News reported a high-severity flaw in Cursor, tracked as CVE-2025-54136 (CVSS 7.2) and codenamed “MCPoison” by Check Point Research. The bug: Cursor tied trust to an MCP server’s name, not its contents. So once a collaborator approved a harmless Model Context Protocol entry in a shared repo, an attacker could silently swap the underlying command for a malicious one (launching an executable, say) with no new warning and no re-prompt, giving them persistent code execution every single time Cursor opened. Check Point disclosed it on July 16, 2025, and Cursor fixed it in version 1.3 (late July 2025) by requiring fresh approval whenever an MCP configuration changes. The lesson outlives this one CVE: keep Cursor updated, and treat any MCP server you let it run as code you are executing. Because it is.

How to use Cursor safely

You can keep the speed and strip out most of the risk. Do these before anything goes to production.

Treat output as a draft, not a release. Run a security pass on auth, secrets, and input handling before you ship a single line Cursor wrote.
Audit access control first. Confirm every protected route and table enforces auth on the server, not just in the UI. For Supabase or Postgres, check that row-level security is on for every table holding user data.
Hunt for secrets. Grep for NEXT_PUBLIC_, VITE_, API keys, and tokens. Move anything sensitive server-side and rotate any key that already leaked.
Review rules files and shared templates as code. Check for hidden or non-printing characters before you trust a rules file from a PR, a dependency, or a starter template.
Lock down MCP and keep Cursor updated. Only enable MCP servers you trust, re-approve when their configs change, and stay on a current Cursor version so the known fixes are actually in place.
Run scanners plus a human review. Pair a static scanner, a dependency scan, and a secrets scan with a manual review of authorization and business logic. That’s the part tools miss.

If you are deciding whether an AI-built app is launch-ready, our guide on whether AI app builders are secure covers the same questions across tools.

Want us to run this audit for you?

We do a free 15-minute build audit: you show us your AI-built app, we tell you the specific security and production gaps and what it takes to fix them. No obligation.

Book your free build audit