In May 2025 a security researcher published a scan of apps built with Lovable and listed on Lovable's own showcase. The finding was recorded as CVE-2025-48757, a CVE being a public identifier for one specific software weakness (Matt Palmer (Replit, Inc.), 2025). This post explains what the scan found, what is disputed, what Lovable's documentation says, and three checks you can run on your own app without writing code.
What the scan found
The researcher scanned 1,645 apps from Lovable's showcase and found 170 of them, about 10.3%, with database endpoints readable without logging in (Matt Palmer (Replit, Inc.), 2025). Across those apps, 303 endpoints returned data to an anonymous request (Matt Palmer (Replit, Inc.), 2025). The scan ran on 2025-03-21 and public disclosure followed on 2025-05-29 (Matt Palmer (Replit, Inc.), 2025).
The mechanism was Row Level Security, or RLS: the per-row access rules that a Supabase (Postgres) database applies to every query. Where a table had no RLS policy, or a policy that allowed everything, the publishable key already sitting in the app's JavaScript was enough to read the rows.
Two things about this CVE are contested, and you should know both. The CVE record scores it 9.3, Critical, while the researcher's own write-up scores it 8.26 (Matt Palmer (Replit, Inc.), 2025). Lovable disputes the CVE on the grounds that each customer is responsible for protecting their own data, and the CVE record notes that dispute (Matt Palmer (Replit, Inc.), 2025). The researcher works at Replit, a competing builder (Matt Palmer (Replit, Inc.), 2025). None of that changes what the scan measured. It does mean the figures should be read as one researcher's scan on one date, not as a verdict on the product.
What to check: open your Supabase dashboard and follow Row Level Security disabled on a table. It takes a few minutes and needs no code.
What Lovable's docs say
Lovable's documentation, as we read it on 2026-09-21, states that Lovable sets up RLS policies automatically when it builds features that store user data. The RLS policies view under Cloud > Database is read-only, and changes go through chat. The built-in backend, Lovable Cloud, is on by default and uses Supabase's open-source foundation, so the same RLS model applies whether you connected your own Supabase project or used Cloud.
Lovable also ships a security scan. The Basic scan runs automatically before publishing and covers RLS policy linting, database schema review and an npm dependency audit (a check of the third-party packages your app uses against public vulnerability records). On demand, the Deep scan adds access-control review, backend endpoint protection checks and code-level checks such as exposed secrets. Lovable's docs are careful about scope: the scanners identify common issues and do not claim complete coverage, and the Basic scan does not include access-control review. The researcher's own write-up also notes that Lovable's Publish flow warns about tables without RLS (Matt Palmer (Replit, Inc.), 2025).
That is a fair set of features. It is also a set of automated linters. A linter can see that a policy exists; it cannot tell whether the policy says what you meant.
Three self-checks
Each of these is written for a non-engineer and links to a page with the full steps and what a bad result looks like.
- Is RLS on for every table. In the Supabase dashboard, open Table Editor and look for any table labelled Unrestricted. Then open Advisors, then Security Advisor. Full steps: Row Level Security disabled on a table.
- Does any policy allow everything. Open Authentication, then Policies, and read each policy's condition. A condition of
trueon a table with customer data is the warning sign. Full steps: RLS policy that allows everything with using (true). - Is the wrong key in the browser. The publishable key belongs in the browser; the secret key, which skips every RLS policy, does not. Search your live app's loaded files for
service_roleandsb_secret_. Full steps: Service-role key shipped in the browser bundle.
If all three come back clean, your app is not in the group the scan described. If one does not, the fix is a policy change in the database, and it can be made through Lovable's chat or by your developer.
Where testing comes in
Lovable did its job: it built the app and it shipped a scanner. Testing is a separate job. When we test an app built with Lovable, we call every table through the API as an anonymous visitor and as two unrelated signed-in users. We record exactly which rows each one could read or change. That is the check a linter cannot make, and it is the first item in our pre-launch package. The Lovable hub lists every pattern we test for on this builder.
What to do this week
- Run the RLS check on every table: Row Level Security disabled on a table.
- Read every policy condition aloud: RLS policy that allows everything.
- Answer the ten-minute self-check for your stack and keep the list it gives you.