CVE-2025-48757 describes a widespread pattern in apps built with the AI builder Lovable, where Supabase tables shipped without Row Level Security enabled, so the app's public anon key let anyone read, modify, or delete user data directly through the Supabase REST API. Security researcher Matt Palmer found around 170 exposed Lovable projects, including ones leaking personal data. The leak was not caused by the exposed anon key, which is meant to be public; it was caused by the missing RLS that is supposed to constrain that key. The fix is to enable and correctly configure RLS on every table, then rotate keys and assess what was exposed.
Short answer
The Lovable data leak, tracked as CVE-2025-48757, happened because AI-generated apps connected to Supabase without Row Level Security, so the public key granted full access to the database. Per the CVE record and Supabase's RLS guidance, the anon key is safe only when RLS restricts what it can do, and these apps had no such restriction. Research by Matt Palmer identified roughly 170 affected projects. To patch it, enable RLS on every table, write and test least-privilege policies, rotate any keys, and determine what data was reachable. The root cause is missing RLS, not the exposed key.
What happened with the Lovable leak
The vulnerability came down to a missing database control in apps generated by an AI builder. Lovable produces working applications quickly, and many of them used Supabase as a backend but did not enable Row Level Security on the tables. Because the frontend connects to Supabase with the public anon key, and Supabase exposes a REST API, anyone could take that public key from the app and query the database directly, reaching data the UI never intended to show.
The consequence was direct data exposure. Without RLS, the anonymous role had full access, so an outside party could list, read, and even modify or delete records, including personal information, simply by calling the API with the key that ships in the app. Matt Palmer's research found this pattern across roughly 170 Lovable projects, which is what turned it from a single mistake into a documented, widespread vulnerability class.
Why AI builders skip RLS
The pattern exists because generating a working app and generating a secure one are different tasks, and AI builders optimize for the former. To make an app function quickly, the fastest path is often to create tables and connect the frontend without the extra step of writing Row Level Security policies, which require thought about who should access what. The app works in a demo, so the missing control is easy to miss.
This is not unique to one tool; it is a property of fast, AI-assisted backend generation. The builder gets you a functioning product, but the security posture is only as good as the policies that were or were not added. Treating a generated backend as secure because it runs is the exact assumption that produced the Lovable leak, and it is why a generated app needs a security review before it holds real user data.
The anon key was not the bug
It is worth being precise about the cause, because the exposed anon key is often blamed and it is not the actual problem. The anon key is designed to be public and to live in client code; Supabase intends it to be there. On its own it grants only the anonymous role, and that role is meant to be tightly constrained by RLS. An exposed anon key on a properly secured project is a non-issue.
The bug was the absence of that constraint. With RLS missing, the anonymous role was not limited to anything, so the public key became a key to everything. Framing it correctly matters for the fix: you do not solve this by hiding the anon key, which you cannot do anyway, but by adding the RLS that was supposed to govern it. The lesson is that a public key is only as safe as the policies behind it.
How to patch RLS
Patching starts with enabling Row Level Security on every table the client can reach, then writing policies that grant each role only what it needs. For a typical app, that means users can read and write only their own rows, and the anonymous role can reach only genuinely public data, if any. Enable RLS first, since a table with RLS off is open regardless of any policies you later add.
Then write and test the policies deliberately. Create least-privilege policies for select, insert, update, and delete, and test them by querying as the anonymous role to confirm the restrictions actually hold. A frequent trap is enabling RLS but adding a policy so permissive that it allows everything, which leaves you no better off, so verification against the anonymous role is the step that proves the patch works rather than merely looks applied.
How to check if you are affected
If you built an app with an AI builder on Supabase, assume nothing and check directly. Open each table and confirm whether Row Level Security is enabled, and review the policies on the tables that are. Any client-reachable table without RLS, or with a policy that permits broad access to the anonymous role, is exposed, because the public key can reach it.
Test it the way an attacker would, against your own project. Using the public key, try to read a table you expect to be protected, and see whether it returns data it should not. If it does, that table is leaking. Because the anon key is public and the REST API is documented, this check is straightforward, and doing it yourself first is far better than learning about the exposure from someone else.
The vulnerability at a glance
Seeing the parts together clarifies both the cause and the fix. The table below summarizes the vulnerability behind the Lovable leak.
| Element | In the Lovable leak |
|---|---|
| Root cause | Missing or permissive RLS on Supabase tables |
| Exposed surface | The public anon key plus the Supabase REST API |
| Impact | Anyone could read, modify, or delete user data |
| Scale | Around 170 projects found exposed |
| Fix | Enable and test RLS, then rotate keys |
The table makes the point that every part except the fix was avoidable with one control. The exposed key and the REST API are normal and expected; only the missing RLS turned them into a leak, which is why RLS is where both the cause and the remedy sit.
Remediation checklist
A clear sequence turns the fix into action and confirms it worked. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Audit tables | List every table and whether RLS is enabled | [ ] |
| Enable RLS | Turn on Row Level Security for all client-reachable tables | [ ] |
| Write policies | Add least-privilege policies and test them as the anon role | [ ] |
| Rotate keys | Rotate keys if data was reachable while exposed | [ ] |
| Assess exposure | Determine what data was accessible and for how long | [ ] |
The two steps people skip are testing policies as the anonymous role and assessing what was already exposed. Testing proves the patch holds, and assessment tells you whether you also have a disclosure or notification obligation, since data that was reachable may have been accessed before you fixed it.
Verify with a scan
Fixing RLS closes the backend hole, but it is worth verifying the app side too, since the same fast-build pattern that skipped RLS can also ship a secret key or other credential in the app. The dangerous case there is not the public anon key but a leaked secret key, which bypasses RLS entirely.
A scanner like PTKD.com analyzes your app build and reports findings ordered by severity and mapped to OWASP MASVS, including secrets embedded in the binary, so you can confirm no secret key or credential shipped in the app. To be clear about the boundary: PTKD does not configure your Supabase RLS or write policies. It checks the built app for exposed secrets, which complements the RLS remediation that fixes the leak itself.
What to take away
- The Lovable leak, CVE-2025-48757, was caused by Supabase tables shipped without Row Level Security, so the public key gave full database access.
- Research found roughly 170 affected projects, making it a documented, widespread vulnerability class rather than a one-off.
- The exposed anon key was not the bug; it is meant to be public, and the missing RLS that should constrain it was the real cause.
- Patch it by enabling RLS on every table, writing and testing least-privilege policies as the anonymous role, and rotating keys.
- Check your own project directly, and verify the app with PTKD.com that no secret key shipped alongside the public one.
