Browse the blog
Sentrint Blog
Lovable A Lovable security checklist you can finish in an evening Is Lovable safe? What it secures, and what it leaves to you
Bolt Is Bolt safe? The platform is certified. Your app is not covered by that A Bolt security checklist for the hour before you share the link
v0 A v0 security checklist for the Next.js app you just exported Is v0 safe? The generated code is the whole question
Cursor Is Cursor safe? The editor and the code it writes are two questions Every MCP server you added is code you never read
Replit Is Replit safe? The agent deleted a production database, and that was the smaller problem
Base44 Is Base44 safe? A single flaw exposed every private app on the platform
AI-built apps Why AI-generated code keeps shipping XSS, and the four places it hides Supabase RLS is not enough on its own. Here is what else you need Six security checks you can run on your own SaaS in 15 minutes Write a security rules file once, and every prompt inherits it Deleting the key from the file does nothing. It is still in your git history Your app calls an LLM. Everything your users type is now instructions Your paywall is a CSS rule. Here is what it costs and how to fix it The package was real, popular and compromised. Your agent installed it anyway Your AI invented a package name. Someone else registered it Can one of your users read another user's data? Here is how to find out Your API key is in your frontend. Here is how to find it and what to do What the research actually says about AI-generated code security
Cursor · Is it safe?

Is Cursor safe? The editor and the code it writes are two questions

Cursor the editor has had real remote code execution flaws, every one of them patched, and every one of them needing you to open something hostile first. Cursor the code generator writes the same insecure patterns every AI tool writes. Keep the editor current, and treat the code as unreviewed until you have checked it yourself.

Gourab Dasgupta Founder, Sentrint 5 min read

Ask whether Cursor is safe and you get two answers that have almost nothing to do with each other. One is about the editor running on your laptop, which has had three separate rounds of serious vulnerabilities and has shipped a fix for all of them. The other is about the code Cursor writes into your repository, which nobody has patched, because it is yours.

The second question is the one where your users' data lives, so most of this goes there. The first deserves twenty minutes and a version check, and that is the section immediately below.

What has actually gone wrong with Cursor itself?

Three public disclosures, all in the same family, all fixed by the time you read this. Taken together they say something more useful than any one of them says alone.

CurXecute, CVE-2025-54135. Aim Security showed in August 2025 that a message sitting in a connected data source, a Slack channel in their write-up, could rewrite Cursor's ~/.cursor/mcp.json and get commands run on the developer's machine. The rewrite went through even when the developer clicked reject on the suggested edit, which is the detail that made it an 8.6. The fix shipped in Cursor 1.3.

MCPoison, CVE-2025-54136. Check Point found that once you approved an MCP server entry, Cursor kept trusting it by name rather than by what it ran. Anyone with commit access to a shared repository could swap the command behind an already-approved entry, and every teammate who had approved the old one silently ran the new one. That turned a single-developer problem into a team-wide one.

DuneSlide, CVE-2026-50548 and CVE-2026-50549. Cato Networks reported two sandbox escapes in 2026, both rated 9.8, both reachable with no click from the developer at all. Hostile text in something the agent read was enough to get out of the IDE sandbox and run code on the host operating system.

The shape repeats, and the shape is the useful part. In all three, the attacker never touched Cursor's servers and never needed your password; they put words somewhere your agent would read them, and the agent treated those words as instructions. That is a property of every agentic coding tool rather than a Cursor defect, and it is why the version you are running matters more than any single CVE number.

Does any of that reach the app I shipped?

Almost certainly not, and the reason is worth being precise about. Every one of those flaws executes code on a developer machine, so the blast radius is your laptop, your local .env, your git credentials and any token your shell can reach. If you were on an old version and you opened a repository or connected a data source you did not control, spending an afternoon rotating tokens is a reasonable response.

What none of them touch is the code in your repository. A sandbox escape in an editor does not insert a missing authorisation check into your API, and patching the editor does not remove one. Those arrived through the ordinary route, which is that you asked for a feature and got exactly the feature you asked for.

What does Cursor not check in the code it writes?

Cursor is an editor with a model attached, not a hosted platform, so it makes fewer promises than Lovable or Bolt do and keeps most of them. It does not run your database, so it cannot turn row-level security on for you. It does not deploy your app, so it cannot tell you that the key you referenced is now sitting in a shipped bundle.

That leaves a specific list, and it is the same list on every AI-built codebase we read:

  • Authorisation between users. Whether account B can load account A's record by changing an id in the URL. The generated route usually checks that you are logged in and stops there.
  • Secrets that crossed the client boundary. A variable named with a NEXT_PUBLIC_ or VITE_ prefix is compiled into your JavaScript. Ask for "read the API key from the environment" and you may get exactly that, on the wrong side.
  • Database grants. On Supabase, switching RLS on does not revoke the privileges the table was created with. That is documented behaviour and a separate step, and no editor runs it for you.
  • Server-side plan checks. If the premium feature is hidden in the component and not checked in the handler, it is free to anyone who reads the network tab.
  • Anything spanning two files. The model that wrote your handler is not holding your middleware, your policy file and your webhook in mind at once, and most real flaws live in the gap between two of those.

None of these produce an error. Your tests pass, the feature works, nothing turns red, and the only signal that any of it exists is somebody finding it.

How do I check a Cursor project?

Start with the editor, because it takes one minute. Open the About or version panel and confirm you are on a current release; if you have been pinned to an old version for a plugin, that is the thing to fix today.

Then check the code, in this order, stopping at the first failure:

  1. Make a second account in your deployed app, then paste a URL belonging to the first one. Seeing the first account's data is the most common serious flaw in generated apps, and it is invisible while you test as yourself.
  2. Grep your own repository for NEXT_PUBLIC_, VITE_ and REACT_APP_, and read what each one holds. A publishable key is fine. A service key, an OpenAI key or a Stripe secret key is an incident.
  3. Search your deployed bundle, not your source, for sk-, secret and token. Source and bundle disagree more often than people expect.
  4. Call a premium endpoint as a free user with the browser network tab open. If it answers, the paywall is decoration.
  5. Look at your MCP server list and delete anything you cannot name the purpose of. Each entry is code you trusted without reading.

What is worth doing this week?

Update the editor, then read your own repository as though somebody else wrote it, because in the parts that matter somebody else did. The five checks above take under an hour and they cover the flaws that get people, in roughly the order they get them.

After that the honest limit shows up. A checklist finds what it lists and looks where you point it, and a codebase has more surface than anyone reads on a Tuesday. That is the job Sentrint does: it reads the whole repository, tells you what an attacker would reach first, in plain English, with a fix you can paste straight back into Cursor. It is a code scan and not a pentest, so it reads what you wrote rather than attacking your running site, and the first scan is free with no card.

The editor's CVEs will keep arriving and keep getting patched. The missing authorisation check in your own code will sit there until somebody looks.

More on Cursor
Every MCP server you added is code you never read Risks · 5 min read Write a security rules file once, and every prompt inherits it Guide · 5 min read
Enough reading. See your own findings.
A free scan turns this into a list of what to fix, in order.
Run your free scan