CVE-2025-48757: the Lovable RLS flaw, who is affected and how to fix it

What CVE-2025-48757 is, in plain words

A Lovable app with a database talks to it straight from the browser. The frontend calls the database's REST API with the public anon key, which ships in the app's JavaScript. Nothing sits in between. The only thing that decides who can read or change a row is row level security (RLS): rules attached to each table in Postgres. When a table has RLS off, or a policy that lets everyone through, anyone who copies the key from the page can query that table without your app.

In March 2025, Matt Palmer found exactly that on a site built with Lovable. He then scanned 1,645 sites listed on Lovable Launched and found 170 projects, about 10.3%, with inadequate RLS, across 303 endpoints. His script only loaded homepages, signed out, so it missed anything behind a login. The CVE record that followed reads:

What a stranger could do with it

No password, no account, no special tool. With the project URL and the public key, both visible in the browser, a visitor could send requests to the database the same way the app does, minus the screens that hide what the app does not show. The researcher's write-up lists what was reachable on the affected sites:

The database did nothing wrong here. It answered exactly as configured. That is why this class of bug survives code review: every screen of the app shows the right data, and the open door is one level down.

Severity and exploitation status

CVSS 9.3, critical. That score comes from MITRE, which assigned the CVE, and the GitHub advisory GHSA-773x-pxjg-gxgx repeats it. NVD shows the same score as a secondary source and has not analyzed the CVE itself: its status is Deferred. The researcher's own report scores it lower, at 8.26, because it rates the scope as unchanged. The 9.3 vector describes a flaw reachable over the network, with no account and no action from a victim.

Disputed. The CVE record carries the tags disputed and exclusively-hosted-service, and this note: Lovable disputes it "because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." The researcher's answer is that a platform which generates the database and its policies should ship safe defaults. For your app, the dispute changes nothing: an open table is open.

Who is affected

Three conditions together: the app was built with Lovable, it uses a database, and at least one table the public key can reach has RLS off or a policy that is too wide. Where the frontend is hosted does not matter, because the browser talks to the database directly.

How to check if your Lovable app is affected

There is no version to compare: no npm package carries the flaw, so npm ls, pnpm why and yarn why cannot tell you whether you are exposed. The one package check that helps tells you whether RLS is your only lock. In a local copy of the project's code, run:

npm ls @supabase/supabase-js
pnpm why @supabase/supabase-js
yarn why @supabase/supabase-js
grep -n "@supabase/supabase-js" package-lock.json pnpm-lock.yaml yarn.lock

1. 1

   Run Lovable's scans

   The Quick scan runs when you open the publish dialog. It flags tables without row level security, access rules that let everyone through, and leaked-password protection turned off. The Deep scan adds a review of the code, access control included: start it from the project's Security view or ask Lovable in the chat. Lovable's own docs say these tools "cannot guarantee complete security", so a clean result is a starting point.

2. 2

   Read every policy

   Open More > Database > Manage > Policies. For each table, ask: is RLS on, who can read, who can write, and does the rule compare a column to the signed-in user? A rule that is just true lets everyone in. A rule for authenticated that never checks auth.uid() lets in anyone who signs up.

3. 3

   On your own Supabase project, run the SQL below

   In the SQL editor. It changes nothing and lists, for each table in public, whether RLS is on, what the anon role may do and how many policies exist.

4. 4

   Open Security Advisor

   In the Supabase dashboard, or run supabase db advisors with the Supabase CLI. Its checks include RLS disabled in public, permissive RLS policy and sensitive columns exposed. Treat each finding as a lead and confirm it.

5. 5

   Read one table as a stranger

   Use the request below with the URL and public key your app already ships, then repeat it signed in as a second test account. A row you should not see is the finding.

select c.relname as table_name,
       c.relrowsecurity as rls_on,
       has_table_privilege('anon', c.oid, 'select') as anon_select,
       has_table_privilege('anon', c.oid, 'insert') as anon_insert,
       (select count(*) from pg_policies p
         where p.schemaname = 'public' and p.tablename = c.relname) as policies
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p')
order by rls_on, table_name;

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true'
       or coalesce(qual, with_check, '') not like '%auth.uid()%');

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY" \
  -H "Authorization: Bearer YOUR_PUBLIC_KEY"

How to check your live app

The SQL tells you what your policies say. A live test tells you what a stranger actually gets. The free check reads your app's address the way a visitor's browser does: in about ten seconds it shows the backend, the exposed keys and the tables your JavaScript names, without sending anything to your database.

Keybrum's attacks then prove it, on apps whose owner proved ownership. The attack supabase.table-read lists every table the public key can reach, from the API schema, the app's own code and common table names, reads 10 rows and counts the rest, first with no account and then as a brand-new one. It keeps counts, column names and one redacted row. The attack supabase.table-insert sends an insert built to fail, with a null primary key, and asks the database to roll the transaction back: if the database answers with a constraint error instead of an RLS refusal, the policy let the write through.

How to fix CVE-2025-48757 in your project

There is no patch to install. Lovable added a security scan with Lovable 2.0 on 24 April 2025 and has extended it since, but the scan finds problems: the policies are yours to fix, table by table. Turn RLS on, then write rules that say who owns each row.

-- Before (do not run): every visitor reads and writes every row
-- create policy "public access" on public.orders
--   for all using (true) with check (true);

-- After: each signed-in user sees and creates only their own orders
alter table public.orders enable row level security;
drop policy if exists "public access" on public.orders;

create policy "read own orders" on public.orders
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "create own orders" on public.orders
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

revoke insert, update, delete on public.orders from anon;

• Keep payment and role fields away from the browser. No policy should let a user update their own payment_status, plan or role. Set them from your server, for example from a signed Stripe webhook.
• Move secrets out of tables and open functions. Lovable's docs say to keep sensitive values in Secrets and read them only in server-side code. A function that returns a key to any caller leaks it like an open table. Then rotate every key that was readable: follow what to do when an API key leaks.
• Read the fixes Lovable proposes. The scan recommends fixes. Check each generated policy against the questions above before you accept it: the researcher's point was that a policy that exists is not a policy that is right.
• Block risky publishes. Workspace admins and owners can turn on Block publishing with critical issues in Workspace settings > Security > Privacy & security > Publishing. Lovable turns it on for the new Enterprise workspaces it creates. On any other workspace, check that it is on.

What to check after fixing

• Every table answers the stranger test with [] or a permission error, not only the table you fixed.
• A second signed-up account cannot read or change the first account's rows. That is an IDOR at the database level.
• Views and database functions called through /rest/v1/rpc/ check the caller too. In February 2026, The Register reported a Lovable-hosted app whose access check in its RPC functions was inverted, which a researcher said exposed 18,697 user records.
• Every secret found in a readable table, or returned by a function anyone can call, has been rotated at its provider.
• Records you did not create, or payment and role fields that changed without a reason, have been looked for and cleaned up.
• If personal data was readable, you have checked what the privacy law that applies to you requires.
• Policies are reviewed again whenever a new prompt adds a table or a feature. Lovable's own guidance calls security an ongoing process.

Related issues: the same class, and one that is not

CVE-2025-48757 has no family of patched versions in the npm sense. Its relatives are the same mistake in other apps: open tables, policies that check nothing, functions that skip the caller. The Lovable security guide covers the rest of the platform, and vibe coding security risks covers the same bugs in other AI builders.

Searches for a "Lovable security breach" also turn up a separate story. In April 2026, a researcher claimed a flaw in Lovable's own platform API let any free account read other users' source code, chats and database credentials. Lovable said it had accidentally re-enabled access to chats on public projects in February while unifying backend permissions, then reverted it. That issue is about Lovable's platform, not about the policies in your database, and it is not this CVE.

Timeline

The fastest way to know where your own app stands is to look at it from the outside, the way the 2025 scan did.