Advisory VV-001critical2025-05
CVE-2025-48757: Lovable apps shipped with missing or weak Supabase RLS
Lovable-generated apps talked to Supabase directly from the browser, but many tables had no (or wrong) Row Level Security policies, so anyone with the public anon key could read or write data.
What it is
The CVE 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." Lovable disputes the CVE, saying each customer is responsible for protecting their app’s data.
The researchers’ scan on 21 March 2025 found 303 endpoints across 170 projects (about 10.3% of 1,645 analyzed) with inadequate RLS. The anon key being public is normal; the missing RLS is the problem.
How to check
- Supabase dashboard → Table Editor: look at the RLS column for every table. "Disabled" means anyone with your anon key can read it.
- From a logged-out browser, request a table through the REST endpoint (see code). If rows come back, it is exposed.
How to fix
- Enable RLS on every table in the public schema.
- Write least-privilege policies tied to auth.uid(). RLS with no policy denies everything, so add policies before you ship.
-- 1) Check: run logged out (replace values)
-- curl "https://<project>.supabase.co/rest/v1/profiles?select=*" -H "apikey: <anon-key>"
-- 2) Fix
alter table public.profiles enable row level security;
create policy "Users read own profile"
on public.profiles for select
using (auth.uid() = id);
create policy "Users update own profile"
on public.profiles for update
using (auth.uid() = id);