Lovable's RLS CVE and its 2026 incidents from the primary sources, what its certifications and scans cover, and how to test your own app safely.

Source: https://easifytechnologies.com/is-lovable-safe/

Insights Articles

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

20 October 2026 14 min read

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.

Work with us

Want a person, not a scanner, to check your Lovable app?

Start a conversation ↗ Prototype to Production

At a glance

Question

Answer

Platform certifications

SOC 2 Type II, ISO 27001:2022 and AIUC-1, per Lovable's FAQ

Not offered

HIPAA compliance or a Business Associate Agreement

Platform incident

3 February to 20 April 2026: public projects' chats and code potentially accessible to other users

Lovable's position on it

Not a data breach; private projects and Lovable Cloud never impacted

The CVE

CVE-2025-48757, published 30 May 2025: insufficient row-level security in apps generated by Lovable

CVE severity and status

9.3 (critical) under CVSS 3.1, a secondary score from MITRE; tagged "disputed"

Researcher's CVE numbers

170 of 1,645 apps checked (about 10.3%), with 303 vulnerable endpoints, homepages only

Lovable's scans today

Quick scan on every publish (database, dependencies); Deep scan on request (application code)

What the scans promise

Lovable says they "cannot guarantee complete security"

AI training on your data

Possible on Free and Pro unless you opt out; excluded by default on Business and Enterprise

What to do

Make the project private, move secrets to the server, test policies with two accounts and a logged-out request

Facts checked

Against the sources linked below, 20 October 2026

Three questions, three answers

Layer

Who is responsible

What has gone wrong

What you control

Lovable the company

Lovable

No public evidence of a breach of its corporate systems

Your plan, your training opt-out, your contract

Lovable the platform

Lovable

Public-project chats and code exposed, February to April 2026

Project visibility; what you paste into chats

Your app

You

Missing or loose row-level security, secrets in front-end code, broken auth logic

Everything in the testing section below

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

Date

What happened

Source

20 March 2025

Researcher Matt Palmer finds exposed tables on a Lovable-built site; emails Lovable the next day

His statement

24 April 2025

Lovable launches a security scan with Lovable 2.0

Same statement

29 to 30 May 2025

CVE-2025-48757 published; Lovable disputes it

NVD record

13 August 2025

Lovable becomes SOC 2 Type 2 compliant, announced five days later

Lovable blog

November 2025

New projects become private by default

Lovable's April 2026 write-up

3 February 2026

A backend change re-enables access to public projects' chats and code

Same write-up

22 February 2026

First researcher reports filed through Lovable's bug bounty triage; closed without escalation

Same write-up

27 February 2026

Researcher reports 18,697 user records exposed in one showcased app

The Register

20 April 2026

Public disclosure of the project-access issue; Lovable reverts the regression

The Register

22 April 2026

Lovable publishes its account and makes historically public projects private

Lovable blog

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:

Problem

How it happens

How to spot it

Table readable without logging in

RLS off, or a policy of true

Logged-out request returns rows

One user can read another's data

Policy checks login, not ownership

Two-account test

User can promote themselves

Role or plan column editable by its owner

Try to update your own role

Inverted or missing auth check

Generated function blocks the wrong users

Call every function logged out

Secret key in the browser

Stored in a VITE_ variable or front-end code

Search the built JavaScript

Secret in a chat or public project

Pasted while debugging

Search chats; check visibility

Unprotected AI or email endpoint

Edge Function with no auth or limit

Call it logged out, repeatedly

Private files in a public bucket

Bucket created public for convenience

List buckets and their settings

Client-only validation

Rules enforced in the form, not the server

Send a request that skips the form

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?

What your app holds

Safe on Lovable?

Public content, a waiting list

Yes, after checking secrets and visibility

Accounts and ordinary personal data

Yes, after the ten steps above, with GDPR duties to meet

Payments through Stripe

Yes, if card data stays with Stripe and fulfilment uses verified webhooks

Card numbers or bank account numbers stored by you

Not under Lovable's standard terms

Patient or other health records

Not under standard terms; Lovable is not HIPAA-compliant

Children's data, IDs, contracts

Possible, but get a person to review it before launch

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.

Work with us

Want a person, not a scanner, to check your Lovable app?

We are a Budapest team that takes AI-built apps to production for founders across Europe, working remotely on CET. The €99 Prototype Check reviews your access rules, keys and payment flow against the live app and sends the top risks in writing within 48 hours. Send the repository and live URL, and we reply within one business day.

Start a conversation ↗ Prototype to Production

On this page

• At a glance
• Three questions, three answers
• Timeline of the public incidents
• The April 2026 project-access incident
• The February 2026 showcased app
• What CVE-2025-48757 actually says
• Why both sides have a point
• What Lovable's certifications and terms cover
• What Lovable's security scans cover today
• What they miss, in Lovable's own words
• The vulnerabilities that actually show up
• How to check your own app safely
• Safe enough for what?
• Getting a second pair of eyes

Frequently asked

Was Lovable hacked?

Lovable says it did not suffer a data breach. Its own incident write-up does confirm that between 3 February and 20 April 2026 a backend regression let other users potentially access the chat history and source code of public projects, and that private projects and Lovable Cloud were not affected. Separately, CVE-2025-48757 describes Lovable-built apps whose own database rules were too loose, which Lovable disputes.

Is the Lovable CVE fixed?

There is no patch in the usual sense, because the problem lives in each app's database policies rather than in one piece of Lovable code. Lovable has since added security scans that check access rules on publish. Apps built before or after the report are safe only if their own policies are correct, so each owner has to check.

Does Lovable's security scan make my app secure?

No, and Lovable says so. Its documentation states the tools cannot guarantee complete security and do not replace a thorough security review. The Quick scan that runs on publish checks the database and dependencies but not your application code; the Deep scan reviews code but only runs when you start it.

Is Lovable SOC 2 and GDPR compliant?

Lovable's FAQ says it holds SOC 2 Type II, ISO 27001:2022 and AIUC-1 certifications, and that it is committed to meeting the data protection laws that apply to its services. It also says it is not HIPAA-compliant and does not sign Business Associate Agreements. None of this certifies the app you build; your access rules and data handling are your responsibility.

Does Lovable use my code and chats to train AI?

According to Lovable's FAQ, it may use customer data from Free and Pro plans for training unless you opt out, while Business and Enterprise workspace data is excluded by default. If your prompts contain client details or business secrets, opt out or use a plan that excludes training.

Is it safe to visit a website built with Lovable?

Usually, in the same way any website is. Lovable says it scans for and blocks projects that break its policies, including malware and phishing, but a lovable.app address is not a guarantee about who runs the site. Treat a request for passwords or payment on an unfamiliar site with the same caution you would anywhere.

Is it legal to test whether a Lovable app is exposed?

Test only apps you own or have written permission to test. Probing someone else's database can break computer misuse laws in most European countries, even if the data was technically reachable. If you find an exposed app that is not yours, report it to its owner rather than reading the data.

Is the Supabase anon key in my app a security hole?

No. The anon or publishable key is meant to be public, and Supabase relies on row-level security to protect data. It becomes a problem only when a table has no policy, or a policy that lets everyone through. The secret or service role key is the one that must never be in the browser.

Keep reading

• [

  

  Edtech MVP Development: Buyers, Children's Data and Scope

  ](https://easifytechnologies.com/edtech-mvp-development/)

• [

  

  Enterprise Ireland Funding for Startups Building an MVP

  ](https://easifytechnologies.com/enterprise-ireland-funding-for-startups/)

• [

  

  EU Funding for Startups: Can It Pay for Your MVP?

  ](https://easifytechnologies.com/eu-funding-for-startups-mvp/)

Want this done properly on your own site?

Start a conversation ↗