The Lovable Security Breach, Explained: Are You Exposed?

What actually is the Lovable security breach?

The 'Lovable breach' is CVE-2025-48757, a critical vulnerability (NVD base score 9.3) describing an insufficient Row-Level Security policy in Lovable-generated sites that lets remote, unauthenticated attackers read or write arbitrary database tables. It is not a single hacked company. It is a structural class of exposure: apps built through 2025-04-15 could ship with their Supabase database effectively open to the internet.

The flaw is catalogued under CWE-863 (Incorrect Authorization) and was published on 29 May 2025. Lovable disputes the CVE, arguing that customers are responsible for securing their own application data. Both things can be true at once: the platform generated the exposure by default, and closing it is still the app owner's job. That is exactly why this page exists — to help you check and fix your own app.

Because the fix lives inside your own Supabase project, publicity around the CVE does not retroactively protect any app. Every affected project has to be checked and corrected individually — there is no platform-side switch that adds the right policies to your specific tables.

Related: How to lock down cross-account data access

How does the RLS data-exposure vulnerability work?

Lovable apps talk to the Supabase database directly from the browser using a public 'anon' key, and rely exclusively on Row-Level Security to decide what each request may see. When RLS is missing — or enabled with a policy that does not filter by the logged-in user — an attacker can call the Supabase REST API directly, skip your UI entirely, and read or write whole tables.

The anon key is meant to be public; it ships in every client bundle by design. Its safety depends entirely on correct RLS. Security researcher Matt Palmer, who reported the CVE, describes Lovable apps as making 'direct REST API calls against the database from the client, using a public and unprivileged anon key, while relying exclusively on RLS.' The moment a policy is absent or too permissive, the data behind it is public.

This is why the exposure is invisible in the editor. The preview runs as a single user, so a missing policy never returns someone else's rows. The hole only becomes observable once a second real account — or an attacker with a script — queries the REST API directly.

Is my Lovable app exposed?

You are potentially exposed if your app was built with Lovable, stores user data in Supabase, and you never explicitly verified Row-Level Security in the Supabase dashboard. The only way to know for certain is to check RLS status and policy conditions directly — a green preview and a working login prove nothing about database-level access control.

1. Open your Supabase project's SQL Editor (reach it from the Lovable Supabase integration).
2. List RLS status for every table: SELECT relname AS table_name, relrowsecurity AS rls_enabled FROM pg_class WHERE relkind = 'r' AND relnamespace = 'public'::regnamespace ORDER BY relname;
3. Any user-data table showing rls_enabled = false has no row filtering at all — treat its contents as already public.
4. For tables where RLS is on, read the policy conditions: SELECT tablename, policyname, cmd, qual, with_check FROM pg_policies WHERE schemaname = 'public';
5. If any policy's qual shows true (rather than an auth.uid() comparison), that table is exposed despite RLS being enabled.

Related: RLS is on but users still see each other's data

What should I do right now if I'm exposed?

Treat an exposed table as a live incident, not a backlog item. The priority order is: stop new sensitive data from being written to the open table, enable RLS with correct owner-scoped policies, then verify with two separate accounts. If regulated data — payments, health, personal identifiers — was readable, document what was exposed and for how long, because that determines your disclosure obligations.

1. Contain: if the table holds sensitive data and you cannot fix it within minutes, take the app offline or block writes rather than leave it collecting more exposed records.
2. Enable RLS: ALTER TABLE public.your_table ENABLE ROW LEVEL SECURITY; (this default-denies until you add policies).
3. Add owner-scoped policies for SELECT, INSERT, UPDATE, and DELETE using auth.uid() = user_id — never USING (true).
4. Rotate any secret that may have been reachable, and assume the anon key's data was public for the entire exposure window.
5. Verify adversarially: sign in as user A and try to fetch a row you know belongs to user B by ID; a correct policy returns nothing.
6. Assess disclosure: if real user data was exposed in production, record the affected tables and time window to inform any breach-notification duty.

Related: Step-by-step RLS lockdown · Move exposed keys into edge functions

Did Lovable fix the breach, or is it still my responsibility?

Both. Lovable added a Security Scan that flags tables with RLS disabled and has improved its scaffolding — but the CVE is disputed by the vendor precisely because securing each app's data remains the owner's responsibility. No platform-side change can retroactively add the correct policies to your specific tables; that work happens in your Supabase project, and only you can confirm it is done.

There is an important limit to the built-in scan, documented by the CVE reporter: it helps ensure RLS policies are enabled and notifies you when they are not, but 'doesn't necessarily indicate if they are sufficient.' A table can pass the scan and still be public if its policy is permissive. That nuance is common enough that we cover it in a dedicated guide.

Related: RLS is on but users still see each other's data

When should I get a professional breach response or audit?

Bring in help immediately if sensitive data was readable in production, if you are unsure how long a table was exposed, or if multiple tables and storage buckets are involved. A breach-response engagement contains the exposure, quantifies what was reachable, and produces the written timeline you need for user or regulator notification; a security audit then confirms every remaining table, key, and policy is closed.

Self-fixing is reasonable for a small app with one or two clearly owned tables and no regulated data, where you can run the verification above with two accounts. Escalate when the blast radius is unclear or the data is sensitive — the cost of a single missed exposed table far exceeds the cost of a review.

Related: Lovable Breach Response service · Lovable Security Audit service · Book a free security call