In March 2025, a security researcher named Matt Palmer was looking at Linkable, a small site built with Lovable that turned LinkedIn profiles into personal websites. He noticed he could read its database directly, including the email addresses of the people who had used it.
He wondered how common that was. So he looked at 1,645 apps from Lovable's own showcase of launched projects. 170 of them, about one in ten, had the same problem. Between them they exposed 303 endpoints where the data came back to anyone who asked.
What came back, according to Palmer's statement: subscriptions, names, phone numbers, API keys, payment details and Google Maps tokens, among other personal data. These were real products with real users, some of them taking money.
The issue was assigned CVE-2025-48757 and published on 29 May 2025, about two months after Palmer first emailed Lovable.
What the 170 apps had in common
Lovable builds apps on Supabase, which gives your app a database it can talk to straight from the browser. To make that work, a public key ships inside the site's code. Every visitor has it. That is how Supabase is designed, and it's fine as long as each table has Row Level Security (RLS) turned on, with rules that say who may see which rows.
In the vulnerable apps, those rules were missing or too loose. So the public key, which was only ever meant to let the app talk to the database under supervision, could be used by anyone to pull whole tables. Palmer describes swapping the app's intended query for a broader one and getting everything back, without logging in.
This is worth saying clearly because it's the most common serious flaw in AI-built apps generally, not a quirk of one platform. Supabase's own documentation says the public key is safe to expose only when RLS is enabled. AI tools write the queries your features need. They are much less consistent about writing the rules, because you asked for a feature and nobody mentioned strangers.
What Lovable did, and why it isn't the whole answer
Lovable released version 2.0 on 24 April 2025 with a security scan. Today its documentation describes a basic scan that runs every time you publish, covering RLS policies, the database schema and dependencies, and a deeper on-demand scan that also looks at access control and code-level issues. That's a real improvement, and you should use it.
Palmer's criticism of the first version still applies to any scanner of this kind. It checked that an RLS policy existed, not whether it was correct. Lovable's docs are honest about the limit: the tools "cannot guarantee complete security", and you remain responsible for your app meeting the security needs of what it does.
A concrete example of the gap. Imagine a table of invoices with RLS turned on and a single policy that lets any signed-in user read rows. The scanner sees RLS on, sees a policy, and moves on. Meanwhile every customer can read every other customer's invoices by changing an ID. The configuration is technically "secure" and practically broken.
How to check your own app
This takes about twenty minutes and needs no security background.
First, look. Open your Supabase dashboard and go through every table. For each one, confirm RLS is enabled and read the policies in plain English. If you see true as the whole condition, or a policy that only checks that someone is logged in, ask your AI tool what it means for that specific table. Tables holding anything personal, financial or secret should tie each row to its owner, usually with auth.uid().
Then, test. Create two accounts in your app, A and B. As A, create something private: a note, an order, a profile field. Sign in as B and try to reach it, first through the app's normal screens and then by asking your coding tool for a request that fetches A's row by its ID with B's session. If A's data comes back, the rule exists and doesn't do its job.
Finally, test without logging in at all. Take the public key from your browser's network tab and try to list a table. If rows come back that a visitor should never see, you have exactly the CVE-2025-48757 problem.
Our pre-launch security checklist puts these two checks first for a reason. They account for most of the serious findings we see.
The uncomfortable bit
Nobody behind those 170 apps did anything unusual. They used a popular tool the way it invited them to, shipped something that worked, and got users. The flaw was invisible because it doesn't break anything. No error, no crash, no bad review. The app works exactly the same for you and for whoever is quietly downloading your user table.
That's why testing from the outside matters more than any setting inside. If you want someone else to run the two-account test and the rest of the list against your live app, that's what we do. But start with the twenty minutes above. It's free, and it's the first thing a curious stranger will try.