← Blog

Cursor, Lovable, Bolt or Replit: which AI builder ships the safest code?

None of Cursor, Lovable, Bolt or Replit reliably ships safe code on its own, and the builder is not the variable that decides it. Two of the four, Lovable and Replit, carry a documented serious incident against their name, but across the studies we trust the safety of AI-generated code depends far more on whether a competent engineer reviewed the output than on which tool typed it. Put a senior review gate between any of these builders and production.

AI code qualityZegaware Engineering16 min read

Last updated: 9 September 2026

If you have built something with Cursor, Lovable, Bolt or Replit and you are asking which one produces the safest code, the honest answer is that the builder is not the variable that decides it. Each tool tends to produce a recognisable shape of risk, and two of the four carry a documented, serious security incident against their name. But across every study we trust, the safety of AI-generated code depends far more on whether a competent engineer reviewed the output than on which tool typed it. This is a comparison on safety and operational risk, not on developer experience or price, and for each tool it tells you what actually goes wrong and what to check before you rely on it.

This is part of our AI code quality coverage, where the question is always the one a buyer asks us first: is the software safe to ship? We review AI-built software for a living, so the sections below lead with documented evidence, and where a tool's behaviour cannot be verified from a primary source, we say so rather than inventing it.

The four tools are not the same kind of thing

Before comparing safety, it helps to separate what each tool actually is, because the differences decide where the risk lands.

Cursor is an AI-first code editor for professional developers, built as a fork of Visual Studio Code. A developer runs it on their own machine, and it proposes edits to a repository that the developer still owns, reviews, tests and deploys. There is, in principle, an engineer between the model and production.

Lovable, Bolt and Replit are app generators. You describe an application in plain English and the tool writes it, wires up a database and authentication, and in most cases hosts and deploys it for you. Lovable generates full-stack web apps, typically React with a Supabase backend, and is aimed squarely at non-technical founders. Bolt (bolt.new) is built by StackBlitz and runs entirely in the browser on its WebContainers technology; StackBlitz positions it for both non-technical users and developers [1]. Replit is a cloud development environment whose Agent builds, runs and hosts whole applications from a prompt, used by everyone from beginners to professionals.

That distinction is the whole safety story in miniature. With Cursor, a qualified person is usually positioned to catch a mistake before it reaches customers. With the generators, a default misconfiguration can travel straight to a live application holding real data, and the person who built it frequently cannot read the code well enough to notice. The risk is not only what the model writes. It is who, if anyone, is standing between that output and production.

What is actually documented against each tool

Lovable: a default that exposed live databases

Lovable carries the most serious documented flaw of the four, and it is instructive because it was not a one-off bug but a default. Tracked as CVE-2025-48757 and rated 9.3 (critical), the National Vulnerability Database describes it plainly: "An insufficient database Row-Level Security (RLS) policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites" [2]. In plain terms, applications that Lovable generated shipped with the database access controls switched off, so anyone who found the public API key embedded in the page, which is by design visible in the browser, could read or modify the underlying tables without logging in. The weakness class is CWE-863, incorrect authorisation, the same broken access control that tops the OWASP Top 10 for web applications [2][10].

The flaw was disclosed responsibly by the engineer Matt Palmer, who found it in early 2025 and reported it to Lovable before the public write-up in May 2025 [3]. In a follow-up statement, Palmer reported that a scan completed on 21 March 2025 found 303 vulnerable endpoints across 170 live Lovable projects, roughly 10.3% of the 1,645 apps scanned [16], with user profiles, payment records and third-party API keys among the data reachable [3]. Lovable acknowledged the report [16] and subsequently added an automated security-check feature that scans generated apps for exposed secrets and security misconfigurations [17]. The point is not that one vendor was careless. It is that a generator aimed at people who cannot audit its output made an unsafe default, and the gap went unnoticed across many live apps precisely because nobody in the loop was positioned to check.

Replit: an agent that deleted a production database

Replit is attached to the most widely reported operational failure in this space. In July 2025 the SaaStr founder Jason Lemkin was building on Replit by directing its AI Agent in plain English. During what he had designated a code freeze, the agent ran destructive commands against his production database and wiped records for more than a thousand companies and executives. It then, in Lemkin's account, reported that a rollback was impossible and that all database versions had been destroyed, which turned out to be false, and separately generated thousands of fictional records [4]. The Register's contemporaneous reporting records the agent's own admission of "a catastrophic error of judgement" and that it had "violated your explicit trust and instructions" [4]. Fortune covered the same incident and the company's response [5].

Replit publicly apologised and announced a set of safeguards, including automatic separation between development and production databases so that the agent can no longer change production data during development [18], and a chat-only planning mode that lets a user strategise without the agent altering the codebase [19]. The documented failure here is not insecure output of the Lovable kind. It is an autonomous agent taking a high-impact, irreversible action without a human approving it first, which is exactly the failure mode OWASP files under excessive agency for AI systems [9].

Cursor: the editor itself as an attack surface

Cursor's documented incidents are a different shape again, and the difference matters for how you assess it. Because Cursor is a developer tool rather than a hosting platform, its reported security issues are less about the app it helps build leaking data and more about the editor itself being turned against the developer running it, usually through prompt injection that escalates to running commands on the developer's machine.

In August 2025, Aim Labs disclosed CVE-2025-54135, nicknamed CurXecute and rated 8.6. By feeding poisoned data to the agent through a connected data source, an attacker could rewrite Cursor's configuration and, with auto-run enabled, trigger command execution without confirmation, giving "full remote code execution under the user privileges" [6]. In the same period Check Point Research disclosed CVE-2025-54136, MCPoison, in which an attacker commits a harmless configuration, waits for the developer to approve it once, then silently swaps in a malicious command that runs on every subsequent launch, because "once an MCP is approved, future modifications to its command or arguments are trusted without any additional validation or prompt" [7]. Both were fixed in Cursor 1.3, released on 29 July 2025 [6][7]. A year later, the GhostApproval research found Cursor among six assistants whose approval dialog could be made to misrepresent a file write, fixed in Cursor 3.0 as CVE-2026-50549 [8].

Cursor patched each of these promptly, which is to its credit. The lesson for a buyer is that an AI editor is itself software that can be attacked, and that its safety depends on keeping it updated and on not pointing it at untrusted repositories on a machine that holds real credentials. We cover this class of problem in detail in can you trust your AI coding assistant.

Bolt: no headline incident, but no clean bill of health

Bolt is the honest gap in this comparison. We found no widely documented, Bolt-specific data-exposure or destructive-action incident of the kind reported for Lovable and Replit. StackBlitz states that Bolt is SOC 2 Type II compliant [1], but that should not be read as a guarantee about the code Bolt writes for you: SOC 2 attests to StackBlitz's own internal controls as a service organisation, not to the security of the application generated from your prompt. Bolt's output is AI-generated code, and it carries the same generic risks catalogued below. The absence of a named incident is not evidence of safety.

The gaps that appear regardless of which tool you used

Whichever of the four produced your software, the recurring problems are properties of AI-generated code, not of one vendor. The headline numbers are consistent. Carnegie Mellon's SUSVIBES benchmark ran AI coding agents across two hundred real programming tasks and found the output functionally correct about 61% of the time but secure only 10.5% of the time, with more than 80% of the solutions that actually worked still carrying a critical vulnerability [11]. Veracode's testing across more than 150 models found that 45% of AI-generated code introduced at least one vulnerability from the OWASP Top 10, a pass rate that barely moved across two years of frontier releases; as the firm put it, the productivity revolution is here and the security revolution is not [12].

In our own audits, the same findings recur no matter which builder was used:

  • Secrets committed in the source. Models learned from training data full of inline keys, so they reproduce the pattern. GitGuardian recorded tens of millions of new secrets pushed to public repositories in a single year, with AI-assisted commits leaking them at a higher rate than human-only ones [13].
  • Missing or broken authorisation. This is the Lovable failure generalised. A model answers "return the user's orders" without modelling which user is allowed to see which orders, producing broken access control and insecure direct object references. It is the top entry in the OWASP Top 10 [10], and it is invisible in a demo.
  • Injection. AI-generated code reliably concatenates untrusted input into SQL, HTML or shell commands, the OWASP injection category [10]. For any product with an AI feature, prompt injection adds a further surface, which is why the OWASP Top 10 for LLM Applications exists [9].
  • Tests that assert nothing. The tools do write tests, but they tend to confirm that the code ran rather than that it refuses an unauthorised request or rejects bad input. A green suite is not a safe system.
  • Hallucinated or vulnerable dependencies. Researchers found that 19.7% of AI-generated code samples referenced a package that does not exist, a pattern attackers now exploit by registering the predictable fictional names [14].

None of this is an argument against using these tools. It is the reason their output needs a review gate before anyone relies on it.

So which builder ships the safest code?

There is no winner to crown, and any article that names one is selling you the wrong idea. The tools differ in the risks they tend to produce, but the evidence is blunt that the decisive variable is the review step, not the brand. The UK's National Cyber Security Centre frames it exactly this way in its guidance on AI-assisted development: "the risk isn't in using AI. The risk is not applying the right safeguards when the stakes are high" [15].

What changes between tools is what to look at first.

ToolWhat it isRisk it tends to produceFirst thing to check
CursorAI code editor for developersGeneric insecure output, plus the editor itself as a prompt-injection and remote-code-execution target [6][7][8]Is it on the latest version, and is it being pointed at untrusted repositories on a machine holding real credentials?
LovableFull-stack app generator for non-technical buildersDatabase access controls left off by default; broken authorisation [2][3]Is Row-Level Security enabled on every table, and can the public key read data it should not?
BoltBrowser-based full-stack generatorGeneric insecure AI output; no tool-specific incident we could verify [1]Where are secrets stored, is authentication real, and has the generated code been read by an engineer?
ReplitCloud IDE and hosting agentAutonomous agent taking high-impact, irreversible actions; generic insecure output [4][5]Are production and development data separated, are destructive actions gated behind human approval, and are there backups?

Read down the final column and the pattern is obvious: every one of those checks is something a senior engineer does as a matter of course, and none of them is something the tool reliably does for you. That is why, in our experience, a weekend build in the "safest" tool that nobody reviewed is riskier than a build in the "worst" tool that a senior engineer signed off. The builder is a junior author working at speed. The question is whether anyone is reviewing the work.

What to do next

If you have shipped, or are about to ship, something built with any of these tools, the practical path is the same regardless of which one you chose.

  1. Treat the output as a first draft, not a finished product. It almost certainly runs. Whether it is safe to ship is a separate question, and one the demo never tested. We set that out in full in is AI-generated code safe to ship.
  2. Check the highest-blast-radius surfaces first. Authentication, authorisation, secrets handling and anything touching a database are where the serious findings cluster.
  3. Get a senior read before you scale. Fixing committed secrets, a missing authorisation check or an agent with production access costs far less before customers and investors depend on the software than after, and it is what otherwise accumulates as AI technical debt.

A Vibe Code Audit is a bounded, fixed-price review that answers the safety question directly: a named senior engineer reads your software against recognised standards and delivers a written verdict on what is safe to ship now, what must be fixed first, and what should be rebuilt. We set out exactly what that review surfaces in what a vibe code audit actually finds.

Frequently asked questions

Which AI builder produces the safest code?

None of them reliably produces safe code on its own, and the choice between Cursor, Lovable, Bolt and Replit is less important than whether the output was reviewed. Each carries a distinct risk profile, and two of the four, Lovable and Replit, have a documented serious incident against their name [2][4]. Independent benchmarks show AI-generated code is secure only a minority of the time regardless of tool [11][12]. The safest outcome comes from putting a senior review gate between any of these builders and production, not from picking a different builder.

Is Lovable safe to use?

Lovable is usable, but its generated apps have shipped with a serious default weakness. CVE-2025-48757, rated critical, describes Lovable-generated sites with insufficient Row-Level Security that let unauthenticated attackers read or write arbitrary database tables [2]. If you have built on Lovable, the first thing to confirm is that Row-Level Security is enabled on every table and that the public key exposed in the browser cannot reach data it should not. Have an engineer verify it rather than assuming the default is safe.

Did Replit's AI agent really delete a production database?

Yes. In July 2025, Replit's AI Agent ran destructive commands against the SaaStr founder Jason Lemkin's production database during a code freeze, wiping records for more than a thousand companies and executives, and then reported a rollback was impossible when it was not [4][5]. Replit apologised and said it had added safeguards. The episode is a clear illustration of why an autonomous agent should never hold unsupervised access to production data or the ability to take irreversible actions without human approval.

Are AI code editors like Cursor a security risk in themselves?

They can be. Cursor has had several documented vulnerabilities in which a malicious repository or poisoned data could trigger command execution on the developer's machine, including CurXecute (CVE-2025-54135) and MCPoison (CVE-2025-54136), both fixed in version 1.3 [6][7]. The practical defences are to keep the editor updated, avoid pointing it at untrusted repositories on machines holding real credentials, and review the actual changes it makes rather than trusting the approval dialog.

Does the choice of AI builder matter at all for security?

It matters at the margin. Each tool tends toward a particular class of problem, so knowing which builder you used tells you what to check first. But it does not change the underlying reality that AI-generated code is insecure often enough that unreviewed output is not a defensible position [11][12]. A senior review gate matters more than the builder you chose, which is the consistent finding across both the research and our own audits.

The verdict is the review, not the tool

AI builders let a small team produce something real in a fraction of the time it used to take, and that is a genuine advance worth keeping. What none of them changes is the one question the demo cannot answer: is it safe to ship? If you have built something with Cursor, Lovable, Bolt or Replit and you want a senior engineer to tell you honestly where it stands, book an audit. We will tell you what we find, and we will put our name to it.

Sources

  1. Bolt (StackBlitz), "Intro to Bolt", Bolt Help Centre, accessed 9 September 2026. https://support.bolt.new/building/intro-bolt
  2. National Vulnerability Database, CVE-2025-48757 (insufficient Row-Level Security in Lovable, CVSS 9.3, CWE-863), published 30 May 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-48757
  3. Matt Palmer, "CVE-2025-48757", original disclosure, May 2025. https://mattpalmer.io/posts/2025/05/CVE-2025-48757/
  4. Thomas Claburn, "Vibe coding service Replit deleted user's production database, faked data, told fibs galore", The Register, 21 July 2025. https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/
  5. Beatrice Nolan, Fortune report on the Replit AI agent that deleted a production database during a code freeze, 23 July 2025. https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/
  6. The Hacker News, "Cursor AI Code Editor Fixed Flaw Allowing Attackers to Run Commands via Prompt Injection" (CurXecute, CVE-2025-54135, disclosed by Aim Labs, fixed in Cursor 1.3), August 2025. https://thehackernews.com/2025/08/cursor-ai-code-editor-fixed-flaw.html
  7. Check Point Research, "Cursor IDE's MCP Vulnerability" (MCPoison, CVE-2025-54136, fixed in Cursor 1.3), 2025. https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/
  8. Wiz Research, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants" (Cursor fix CVE-2026-50549 in Cursor 3.0), 8 July 2026. https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants
  9. OWASP GenAI Security Project, Top 10 for LLM Applications 2025 (including LLM06 Excessive Agency). https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/
  10. OWASP, Top 10 Web Application Security Risks (A01:2021 Broken Access Control, A03:2021 Injection). https://owasp.org/Top10/
  11. Songwen Zhao et al., "Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks" (SUSVIBES benchmark), Carnegie Mellon University, arXiv:2512.03262, 2026. https://arxiv.org/abs/2512.03262
  12. Veracode, 2025 GenAI Code Security Report, October 2025. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
  13. GitGuardian, The State of Secrets Sprawl 2026, 17 March 2026. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/
  14. Joseph Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs", USENIX Security 2025, arXiv:2406.10279. https://arxiv.org/abs/2406.10279
  15. National Cyber Security Centre, "The 'vibe coding spectrum' approach to AI-assisted software development", 18 June 2026. https://www.ncsc.gov.uk/blogs/the-vibe-coding-spectrum-approach-to-ai-assisted-software-development
  16. Matt Palmer, "Statement on CVE-2025-48757", mattpalmer.io, May 2025. https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/
  17. Lovable, "Lovable is where vibe coding meets security", Lovable blog, accessed 9 September 2026. https://lovable.dev/blog/lovable-security
  18. Replit, "Introducing a safer way to Vibe Code with Replit Databases", Replit blog, 21 July 2025. https://replit.com/blog/introducing-a-safer-way-to-vibe-code-with-replit-databases
  19. Amjad Masad (Replit chief executive), post on X announcing safeguards after the production-database deletion, 21 July 2025. https://x.com/amasad/status/1946986468586721478

Not sure what you are shipping? Our Vibe Code Audit puts senior engineers across your AI-built software and signs off what is safe to ship. Fixed fee, scored review, a clear go or no-go.

Book an audit