Is Lovable Safe? The Incidents, the Scans and Your App

Lovable is a certified, mainstream platform, but "is it safe" has three separate answers. The company holds SOC 2 Type II and ISO 27001 certifications. The platform has had a confirmed incident: Lovable says that between 3 February and 20 April 2026, the chat history and source code of public projects could potentially be accessed by other users, while private projects and Lovable Cloud were not affected. The apps people build are where most real exposure has been found, through database access rules that were missing or too loose, the pattern behind CVE-2025-48757. Lovable can be safe for your app, but only if your project is private, your secrets are on the server and your access rules are tested, and those are yours to check.

This page explains each incident from the primary record, what Lovable's certifications and security scans do and do not cover according to its own documentation, and how to test your own app without crossing any lines.

At a glance

Three questions, three answers

Most of the confusion in search results comes from mixing these up. A SOC 2 report is about the first row. A CVE about generated apps is about the third.

Timeline of the public incidents

The April 2026 project-access incident

This is the one incident that was about Lovable's own platform rather than the apps on it.

Lovable's incident write-up, published 22 April 2026, says that while unifying permissions in its backend in February it re-enabled access to chats on public projects, and that "between February 3, 2026 and April 20, 2026 public project chat history and source code could potentially be accessed." It says access required a project link, that "private projects and Lovable Cloud were never impacted", and that several researchers had reported the issue from 22 February but the reports were closed without reaching its security team because triage relied on outdated internal documentation.

The researcher's public claims went further. The Register's report says the researcher described using a free account and a handful of API calls to reach another user's profile, public projects and source code, and said database credentials could be extracted from that code. Lovable's first statements said "we did not suffer a data breach" and called code visibility on public projects intended behaviour; it later apologised that this "didn't properly address our mistake." Lovable's own write-up describes chats and source code; it does not say database credentials or customer data were reached, though credentials hard-coded in exposed source code would have been readable with it.

What it means for you: anything you put into a public project's chat or code during that window, such as an API key, a customer's details or a database password, should be treated as possibly seen. Lovable says it has made historically public projects private and will contact affected owners directly.

What to do now:

1. Check each project's visibility. Lovable notes that visibility (who can see the editor, chats and code) is separate from who can visit your published app.
2. If any project was public between February and April 2026, list every secret that ever appeared in its code or chats and rotate it.
3. Search your chats for customer data you pasted while debugging, and decide whether you owe anyone a notification.
4. Stop pasting live secrets into chats. Use Lovable's Secrets store.

The February 2026 showcased app

The Register reported on 27 February 2026 that a researcher, Taimur Khan, found 16 vulnerabilities, six critical, in an education app featured on Lovable's Discover page, exposing 18,697 user records. Two causes are instructive. Row-level security and role checks were missing, and an authentication function had its logic inverted: it blocked logged-in users and let anonymous ones through.

Lovable's CISO told The Register that every Lovable project gets a free security scan before publishing, that acting on its recommendations is up to the user, and that "this project also includes code not generated by Lovable and the vulnerable database is not hosted by Lovable." Both points can be true at once. The lesson is that an inverted check reads as working code to anyone who only tests the happy path.

What CVE-2025-48757 actually says

The NVD record describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that "allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." The same description carries a note: "this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." The record is tagged both "disputed" and "exclusively-hosted-service".

The researcher who filed it, Matt Palmer, published a technical write-up and a statement. According to the statement:

• he scanned 1,645 projects listed on Lovable's showcase and found 170 vulnerable (about 10.3%), with 303 vulnerable endpoints;
• the scan checked homepages only, so logged-in areas were not tested and the real figure could be different;
• exposed data included names, emails, phone numbers, payment and subscription records, and third-party API keys; on one site, he could write a record marking a payment as paid;
• he criticised Lovable's April 2025 scan for checking that an RLS policy existed rather than whether it was correct;
• he published the CVE after a 45-day disclosure window.

Those are one researcher's figures from one scan of a public showcase. They tell you the problem was real and not rare in that sample. They do not tell you what share of Lovable apps are exposed today, and you will see other percentages quoted online that we could not trace to a primary source.

Why both sides have a point

The technical cause is not a bug in Lovable's code. In a Lovable app, the browser or server code calls the Supabase database with a public key, and Supabase's row-level security is what limits each request to the right rows. A table with RLS off, or with a policy that lets everyone through, is open to anyone holding that public key, which every visitor has.

Lovable's position is that the app owner configures and is responsible for those policies. The researcher's position is that a tool aimed at people who do not know what RLS is should make the safe setting the default. For a founder, the dispute changes nothing: if your policies are wrong, your users' data is exposed, and it is your app.

What Lovable's certifications and terms cover

Lovable's FAQ is the clearest primary source on the company's own position:

• Certifications: SOC 2 Type II, ISO 27001:2022 and AIUC-1. These are audits of Lovable's controls as a company.
• GDPR: Lovable says it is "committed to meeting the requirements of the data protection laws that apply to its services." For a contract, ask for its data processing terms.
• Health data: Lovable is not HIPAA-compliant and does not sign Business Associate Agreements.
• Regulated data in your app: its standard terms do not allow protected health information, payment card data or financial account numbers.
• AI training: Lovable may use customer data from Free and Pro plans unless you opt out; Business and Enterprise workspace data is excluded by default.
• Abuse: Lovable's security post from August 2025 says it blocks about 1,000 projects a day that violate its policies, which is about phishing and malware hosted on the platform rather than your app's safety.

For anything more, Lovable publishes a trust centre. We have not assessed its contracts or controls and make no claims about them here.

What Lovable's security scans cover today

Its security documentation, checked on 20 October 2026, describes:

• Quick scan. Runs automatically on every publish and when the publish dialog opens. It reviews database access rules, tables without per-record access control, and leaked-password protection; audits npm dependencies for known vulnerabilities; and checks for MCP servers exposed without authentication.
• Deep scan. Everything in the Quick scan, plus a review of application code in seven areas: access control, unauthenticated endpoints, unsafe input and injection, leaked secrets, payments and billing, authentication, and exposed personal or sensitive data. You start it yourself from the Security view.
• Auto-fix. When enabled, Lovable attempts to fix a few critical Quick scan findings on the database and dependencies. It does not apply fixes to Deep scan findings.
• Optional integrations with Wiz (code and dependency analysis) and Aikido (AI penetration tests against the running app, billed separately).
• Publishing controls. By default, Lovable warns you about critical issues before publishing but lets you publish anyway; a workspace setting can block publishing until they are fixed.

What they miss, in Lovable's own words

• the tools "cannot guarantee complete security" and "do not replace a thorough security review";
• "you are responsible for ensuring that your app meets the security requirements appropriate for its use case";
• the Quick scan does not cover application code;
• dependency findings include only critical vulnerabilities, and some are excluded when Lovable judges they cannot affect Lovable apps;
• "misconfigured RLS rules are a common cause of data leaks."

In practice, the gap is intent. A scanner can tell that a policy exists and spot obvious patterns. It cannot know that your invoices table should be visible to the customer and their accountant but not to other customers, or that a user should not be able to change their own plan column. The February 2026 case shows another blind spot: an inverted check looks like a check.

The vulnerabilities that actually show up

Across the incidents above and Lovable's own guidance, the same handful of problems recur:

Lovable's security best practices cover most of these in one line each: "always treat client input as untrusted", "check roles and permissions server-side", and use front-end auth state "only to control UI, never to enforce access."

How to check your own app safely

Test only apps you own or have written permission to test. Reading someone else's exposed data, even to prove a point, can be an offence under computer misuse laws across Europe. If you find an exposed app that is not yours, tell the owner.

For your own app:

1. Check project visibility and set anything that is not a deliberate template to private or workspace.
2. Run the Deep scan from the Security view and read every finding, including the warnings.
3. Make a table inventory. For each table: what it holds, who should read it, who should change it.
4. Read the policies in Lovable under More, Cloud, Database, RLS policies (or the Supabase dashboard if you use your own project). Look for true, for select policies with no matching update policy, and for inserts without a with check clause.
5. Try it logged out. With your own project URL and the public key from your app's code, ask the database for a table directly. If rows come back for a table that should be private, the policy is wrong.

curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR-PUBLISHABLE-KEY"

6. Try it as the wrong user. Create two test accounts. Logged in as one, open the other's records by changing an ID in the URL, and try to edit or delete them.
7. Try to promote yourself. As an ordinary user, try to update your own role, plan or credit balance.
8. Call your functions logged out. Every Edge Function that reads data, sends email or calls an AI model should refuse an anonymous request.
9. Check storage. List the buckets, note which are public, and make sure private documents are not in them.
10. Search for secrets. Look for service_role, sb_secret_, sk_live and any secret in a VITE_ variable, in the code, the git history and your chats. Supabase's API key guide explains how to rotate one.

The Supabase RLS checklist turns steps 4 to 7 into SQL tests you can keep and rerun after every change. For the wider pre-launch list, see taking a Lovable app to production.

Safe enough for what?

When not to hire us: if your app has no logins, stores no personal data and takes no payments, a public table may be exactly what you want. Make the project private, run the Deep scan, fix what it flags and launch.

Getting a second pair of eyes

The €99 Prototype Check is a person testing the steps above against your live app and reading the policies and server code behind them. Within 48 hours of payment and access you get the top security and data risks in writing, then a 15-minute call. The €99 is credited against the build if you hire us. If your app is not working at all yet, start with what to do when a Lovable app stops working, and if you are deciding whether it is ready to launch, see is Lovable production-ready.

We are based in Budapest and work remotely across Europe on CET, in English or Hungarian, with our engineering team in India.