CVE-2025-48757: What the Lovable RLS Flaw Teaches Supabase Apps

The National Vulnerability Database entry was published on May 30, 2025. It describes an insufficient database Row Level Security policy in Lovable, through April 15, 2025, that allows remote unauthenticated attackers to read or write arbitrary database tables of generated sites.

The same entry carries a dispute note. The supplier's position, as recorded there, is that each customer of the platform accepts responsibility for protecting the data of their own application. The NVD entry is tagged as disputed and, at the time of writing, its status is deferred, which means it has not been fully analyzed.

That framing is worth holding onto. The recorded disagreement is about responsibility: whether this is a product defect or a customer configuration issue, and for a builder that distinction changes nothing about your risk: if your tables are open, your users' data is open.

The researcher who disclosed the issue published findings, which the NVD entry links to. Secondary coverage reported that a public scan flagged 170 of 1,645 showcased projects as having exposed data. We have not independently reproduced that scan, so treat the figure as reported, not verified, and do not read it as a measurement of all Lovable apps or of AI-built apps generally.

The scale of any single number matters less than what it shows: a showcase of apps that looked finished and worked in a browser could still have tables that an anonymous request could read. Working software and safe software are different properties, and preview builds only test the first one.

Supabase exposes your Postgres database through an auto-generated REST API. A browser app calls that API directly, using your project URL and a public key. Both values ship inside your JavaScript bundle, by design. Supabase documents its publishable key as safe to expose in web pages, mobile apps and source code, because it is meant to work together with Row Level Security.

That last clause carries the whole security model. The public key does not grant privileges. It identifies the request as coming from the anon role, and Postgres then decides what that role may touch. If RLS is off on a table in an exposed schema, there is nothing to decide: the request is allowed. If RLS is on with a policy such as using (true), the decision is also yes.

The NVD wording covers both read and write. A table that is readable by anon leaks data. A table that is writable by anon lets a stranger change prices, roles or ownership fields, which is often worse.

An assistant is optimizing for a working feature. It creates a table, writes a query, and the page renders. In the preview you are usually signed in as yourself, so everything you can see looks correct. Nothing on screen reveals that a stranger without a login can see the same rows.

Two other habits compound it. Generated migrations sometimes create tables without ever enabling RLS, and quick fixes for a permission error can loosen a policy to make the error disappear. The app then works again, and the protection is gone.

• Treat the public key as public. Rotating it does not fix a table with RLS off, because the new key is just as visible.
• Enable RLS on every table in every exposed schema, including tables created later by a generator.
• Enabling RLS with no policies denies access through the API. That is the safe default; add the narrowest policy that makes a feature work.
• Write policies for the operation they govern. Reads, inserts, updates and deletes each need their own reasoning.
• Never use the secret or service_role key in browser code. It bypasses RLS entirely, per Supabase's own documentation.

Only run this against a project you own. Start by asking the database itself which public tables have RLS switched off. Then list the policies that are effectively unconditional.

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

A table can have RLS on and still be open. This query shows policies whose conditions are literally true, which behave like no protection for that operation.

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true')
order by tablename;

Finally, confirm from the outside. Send a request with only the public key, no user session, to a table you own. Then try a write against a disposable row. A permission error or an empty result on reads, and a rejected write, is what you want.

curl "https://<project-ref>.supabase.co/rest/v1/<table>?select=*&limit=1" \
  -H "apikey: <public-key>" \
  -H "Authorization: Bearer <public-key>"

curl -X POST "https://<project-ref>.supabase.co/rest/v1/<table>" \
  -H "apikey: <public-key>" \
  -H "Authorization: Bearer <public-key>" \
  -H "Content-Type: application/json" \
  -d '{"<column>": "test"}'

1. 1Enable RLS on the affected table immediately. With no policies, API access is denied, which stops the bleeding while you design real policies.
2. 2Write a narrow policy per operation and re-run the outsider test.
3. 3Review your data for changes you did not make. Anonymous write access means you cannot trust rows, not just that they were read.
4. 4If the table held personal data, check the notification duties that apply to you and speak to a qualified lawyer. This post is not legal advice.
5. 5Add the two SQL checks to your release routine so a new table cannot ship unnoticed.