Which apps are affected by CVE-2025-48757?

The original documentation identified 170+ apps built with Lovable. The same vulnerability class affects any app that: (1) uses Supabase as a database, (2) was built or scaffolded by an AI builder that did not enable RLS by default, and (3) has not had RLS manually configured since deployment. This includes apps built with Bolt.new, Cursor, v0, Replit, and any other tool that generates Supabase schemas without enabling row-level security. Check your app: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; — any false value means the table is exposed.

Home / Blog / CVE-2025-48757

Security postmortem · May 2025

CVE-2025-48757: The Lovable RLS Vulnerability That Exposed 170+ Apps

Q: Am I vulnerable if I built with Lovable?

If you built with Lovable and have not manually enabled Supabase RLS on every table, you are likely vulnerable. Run this SQL in your Supabase SQL editor: SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY rowsecurity; Any table showing rowsecurity = false is publicly accessible using your anon key. Also check for permissive policies: SELECT tablename, policyname, qual FROM pg_policies WHERE schemaname = 'public' AND qual = 'true'; Policies with qual = 'true' provide no restriction despite RLS being enabled.

Q: How do I fix CVE-2025-48757?

Three steps: (1) Enable RLS on every table: ALTER TABLE users ENABLE ROW LEVEL SECURITY; (repeat for each table). (2) Add owner-scoped policies: CREATE POLICY 'select_own' ON users FOR SELECT USING (auth.uid() = id); — replace USING (true) with USING (auth.uid() = user_id). (3) Check for service_role key in client code: grep -r 'service_role' ./dist ./public — if found, rotate the key immediately via your Supabase dashboard and move it to server-side environment variables only. Test your app after each step.

Q: Is CVE-2025-48757 patched in newer Lovable versions?

Lovable has increased RLS awareness in its interface and documentation since May 2025. However, the underlying issue is not a Lovable bug — it is a Supabase default (RLS is off by default on every new table) combined with AI-generated schemas that do not enable it. Even with the latest Lovable version, you must manually verify RLS is enabled on every table in your production database. The patch is in your Supabase configuration, not in Lovable's code.

In May 2025, over 170 production apps built with Lovable had their entire Supabase databases publicly readable — no login, no exploit, no technical skill required.

CVE-2025-48757 Supabase RLS P0 — Critical CVSS v3

Executive summary

CVE-2025-48757, disclosed in May 2025 and attributed to research by Matt Palmer and Matan Getz, documented a critical misconfiguration pattern affecting 170+ production web applications built with the Lovable AI builder. The root cause: Supabase, the database platform used by Lovable-generated apps, ships with row-level security (RLS) disabled on every table by default. Lovable's code generation scaffolds the database schema without enabling RLS. The Supabase anon key — a public credential embedded in the client-side JavaScript bundle by design — could therefore be used to query any table in the affected databases and return all stored data: user accounts, emails, payment records, private content, and API keys stored in the database. No authentication, exploit, or technical knowledge was required. The fix is enabling RLS on every Supabase table and writing owner-scoped access policies. As of mid-2026, the pattern persists in newly deployed apps across multiple AI builders.

Timeline

Early May 2025

Vulnerability pattern identified

Security researchers Matt Palmer and Matan Getz independently identify that large numbers of Lovable-generated production apps have Supabase RLS disabled. The anon key, present in every client bundle, provides unrestricted database access.

May 2025

CVE-2025-48757 assigned and disclosed publicly

The vulnerability class receives a formal CVE identifier. Public documentation confirms 170+ affected apps, all in production with real users. The disclosure is published via the National Vulnerability Database and covered in security research blogs.

May–June 2025

Lovable and Supabase awareness response

Lovable updates its documentation and interface guidance around RLS. Supabase publishes clarifications on default RLS status. Neither platform pushes a retroactive fix to deployed apps — the configuration change must be made by each developer in their own Supabase project.

2026 (ongoing)

Pattern continues across all AI builders

RLS misconfiguration remains the most common critical finding in AI-built apps scanned by Launch Ready Code. The issue is not limited to Lovable — Bolt.new, Cursor, v0, and Replit apps using Supabase exhibit the same pattern when RLS is not manually configured.

Technical breakdown

Why the anon key is public by design

Supabase provides two primary API credentials:

The anon key: A public JWT intended to be shipped in the client browser bundle. It identifies your project and allows unauthenticated access to your database — subject to RLS policies. If RLS is configured, the anon key can only access what policies permit. If RLS is off, it has unrestricted access.
The service_role key: A private JWT that bypasses all RLS. Must never appear in client code or Git history.

The anon key being public is correct behaviour, documented in Supabase's own setup guides. The failure in CVE-2025-48757 was not the key being present in the bundle — it was the absence of RLS policies that should have restricted what the key can access.

Why RLS off = full database access

When Supabase row-level security is disabled on a table, the Supabase PostgREST API applies no row filtering whatsoever. Any request — authenticated or anonymous — that reaches the table's REST endpoint returns all rows. The check that PostgREST performs is: "Is the caller authorised to use this Supabase project?" (answered by the valid anon key). Without RLS, it never asks: "Is the caller authorised to see these specific rows?"

The exact attack vector

For any affected app, the attack was a single HTTP request:

GET https://[project-ref].supabase.co/rest/v1/users?select=*
apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "id": "uuid", "email": "user@example.com", "created_at": "...", ... },
  { "id": "uuid", "email": "another@example.com", "created_at": "...", ... },
  ...
]

The anon key is extracted from the page's JavaScript source (one browser DevTools search). The project ref is in the same URL. The table name is guessable from common Supabase conventions (users, profiles, orders, payments). No authentication, no session, no exploit code.

What data was exposed

170+

Production apps with full database access

100%

Of table data returned per request

Across the 170+ affected apps, the exposed data included:

User email addresses and account details (every user in every app)
Payment records, subscription status, and billing metadata
Private user-generated content (notes, messages, documents, uploads)
API keys and service credentials stored in the database rather than environment variables
Internal application data (admin flags, feature flags, configuration settings)
Application logs and audit trails

Any table without RLS was fully exposed. A typical Lovable app has 5–15 tables in the public schema. Every table without RLS was fully readable and writable. In many apps, every table was unprotected.

Root cause analysis

Three independent factors converged to create this vulnerability class:

Factor 1 — Supabase ships with RLS off by default

Every table created in Supabase has rowsecurity = false until explicitly enabled. This is a deliberate Supabase design choice — enabling RLS before policies are written locks out all users including authenticated ones, which would break apps in an equally confusing way. Supabase documents this clearly but relies on developers to take the enabling step.

Factor 2 — AI builders scaffold schemas without enabling RLS

Lovable (and Bolt, Cursor, v0, and other AI builders) generates CREATE TABLE statements and migration files. None of the major AI builders in 2025 included ALTER TABLE ... ENABLE ROW LEVEL SECURITY; or policy creation in their default schema output. The generated code was functional but insecure by default.

Factor 3 — No deployment-time warning

Supabase did not surface a prominent warning at deploy time or via the dashboard alerting developers that public-schema tables had RLS disabled. Lovable did not flag this condition before launching apps. Developers who were not already familiar with Supabase's RLS model had no automated signal that their database was publicly accessible.

The fix — 3 SQL commands

The complete remediation for CVE-2025-48757 is three steps in your Supabase SQL editor:

-- Step 1: Enable RLS on affected tables (repeat for every table)
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

-- Step 2: Add owner-scoped SELECT policy
-- Replace 'id' with the column that matches auth.users.id in your table
CREATE POLICY "owner_only"
  ON users FOR SELECT
  USING (auth.uid() = id);

-- Step 3: Verify no tables remain unprotected
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

-- Expected: zero rows returned

Also check for the service_role key in client code. If it is present in the browser bundle, an attacker can bypass all RLS regardless of your policies. Rotate it and move it to server-side environment variables only: grep -r "service_role" ./dist ./public 2>/dev/null

How to check if your app is affected

Diagnostic Query 1 — Check RLS status on all tables

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY rowsecurity, tablename;

-- rowsecurity = false → VULNERABLE (fix immediately)
-- rowsecurity = true  → check policies with Query 2

Diagnostic Query 2 — Check for permissive policies

SELECT tablename, policyname, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND qual = 'true';

-- Any result here = permissive policy (functionally equivalent to RLS off)
-- Fix: ALTER POLICY to use USING (auth.uid() = user_id)

The broader pattern — not just Lovable

CVE-2025-48757 was documented in Lovable apps because they were the most prevalent AI-built app category in mid-2025. The vulnerability class is not Lovable-specific. Any app that:

Uses Supabase as its database, and
Was scaffolded by an AI builder that did not enable RLS, and
Has not had RLS manually enabled since deployment

...has the same exposure. This includes apps built with Bolt.new, Cursor, v0, Replit, and any custom ChatGPT or Claude-assisted development that generated Supabase schema migrations without RLS configuration.

As of June 2026, this remains the most common critical finding in vibe-coded apps scanned through Launch Ready Code. Average security score on first scan across all AI-built Supabase apps: 42/100.

Check if your app is affected — free scan

URL-based scan. No code access. No signup. Checks RLS, service_role exposure, Edge Function auth, and 40+ additional vectors. Free Launch Readiness Score in 60 seconds.

Check if your app is affected — free scan

Frequently asked questions

What is CVE-2025-48757?

CVE-2025-48757 is a class of misconfiguration documented in May 2025 affecting 170+ production apps. The root cause: Supabase tables have RLS disabled by default; AI builders scaffold schemas without enabling it; the Supabase anon key — public by design, in the client bundle — could therefore query any unprotected table and return all rows with no authentication. No login, no exploit required.

Which apps are affected?

All apps that use Supabase and were built or scaffolded without manually enabling RLS. The original disclosure covered 170+ Lovable apps. The same pattern affects apps built with Bolt.new, Cursor, v0, Replit, and any AI-assisted development workflow that generated Supabase schemas without RLS configuration. Check your app: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; — any false value means that table is exposed.

Am I vulnerable if I built with Lovable?

If you built with Lovable and have not manually enabled RLS on every table, you are likely vulnerable. Run the diagnostic SQL above in your Supabase SQL editor. Look for rowsecurity = false (any table is exposed) and qual = 'true' in your policies (permissive policies that provide no restriction). For a complete check including service_role exposure and Edge Function auth, run the free scanner at launchreadycode.com.

How do I fix CVE-2025-48757?

Three steps: (1) Enable RLS on every table: ALTER TABLE users ENABLE ROW LEVEL SECURITY; (2) Add owner-scoped policies: CREATE POLICY "owner_only" ON users FOR SELECT USING (auth.uid() = id); — replace any USING (true) policies with owner-scoped ones. (3) Check for service_role key in client code and rotate it if found. Test your app after each step to confirm legitimate access still works.

Is CVE-2025-48757 patched in newer Lovable versions?

Lovable has increased RLS awareness in its interface since May 2025. The underlying issue is not a Lovable bug — it is a Supabase default (RLS off on new tables) combined with AI-generated schemas that did not enable it. Even with the latest Lovable version, you must verify RLS is enabled on every table in your production database. The fix is in your Supabase configuration, not in Lovable's code generator.

Sources: CVE-2025-48757 (NVD / Matt Palmer, May 2025); byteiota.com/supabase-security-flaw-170-apps-exposed-by-missing-rls; vibeappscanner.com/issues/supabase; Supabase documentation on Row Level Security. This page provides general security guidance and technical documentation, not a certification or guarantee.