CVE-2025-48757 is a critically-rated Lovable vulnerability (CVSS 9.3) that exposed more than 170 applications. The problem: anyone, without logging in, could read —and in many cases modify— data in your database: names, emails, third-party API keys, even payment status. The root cause is not a hidden Lovable bug but a pattern shared by almost every "vibe-coded" app: trusting all database security to Supabase's RLS policies… and leaving them incomplete.
What actually happened
Lovable builds apps where the browser talks directly to the database (Supabase) through REST calls, using the public anon key. That is a sound design as long as every table has Row-Level Security (RLS) policies deciding which rows each user may read or touch. The vulnerability appeared because many projects shipped with tables that had no RLS or insufficient RLS. An attacker only had to edit the REST request —change a filter in the URL— to ask for "all rows" of a table that should have been protected.
It was reported in March 2025 by Matt Palmer and Kody Low, and independently by Danial Asaria, with public disclosure on May 29, 2025 (technical write-up, CVE entry). Any Lovable project using a database created on or before April 15, 2025 could be affected.
Why it affects you even if you don't use Lovable
This is not a Lovable-only problem. Any app that talks to Supabase directly from the browser —whether you built it with Bolt, v0, Cursor or by hand— relies on RLS being correct on every table. The app looks perfect, login works, but real security lives in the database, not in the interface. Hiding a button in the frontend protects nothing: the REST request is still there for anyone who knows where to look.
How to know if your app is vulnerable
- Open DevTools (F12) → Network tab while using your app and watch the calls to
*.supabase.co/rest/v1/. Copy one of those URLs, open it in an incognito window (no session) and see if it returns data. - Try to over-ask: if a call returns your data, remove the filter from the URL. If it hands back other users' rows, your RLS is not effective.
- Check the Supabase dashboard → Authentication → Policies. Any table with real data showing "RLS disabled" or no policy at all is an open door.
How to fix it
- Enable RLS on every table, not just the "important" ones. The rule is deny by default: with no policy allowing it, nobody gets in.
- Write explicit policies per operation (select/insert/update/delete) tied to
auth.uid(), so each user only touches their own rows. - Never use the
service_rolekey in the frontend: it bypasses RLS entirely. That key lives on the server only. - Re-test with the incognito step above: if the session-less request now returns empty or an error, you're on track.
How Scanaris checks it
Scanaris scans your site read-only and detects the fingerprint of this pattern: Supabase endpoints reachable from the browser, permissive CORS, keys and tokens exposed in your JavaScript, and data the app serves with no session. Paste your URL and it tells you, in seconds and ranked by severity, what is in plain sight —before someone else finds it.