CVE-2025-48757: Are You Still Exposed to This Lovable Bug?

Quick answer: CVE-2025-48757 is a real, disclosed vulnerability affecting Lovable-generated apps that connect to a Supabase database. The root problem: Row-Level Security, the setting that restricts who can read or write which rows in a database table, wasn't enabled by default, and the app's public API key was exposed on the client the same way it always is. Researchers found 170+ live apps where that combination let anyone send a crafted request and read or write data with no login at all. Lovable never shipped a code fix. The mitigation was, and still is, "turn on RLS yourself." If your app was built this way and you haven't checked, this is worth ten minutes right now.

What actually happened

In March 2025, security researchers identified that Supabase projects created through Lovable frequently had Row-Level Security disabled by default. Supabase, the backend-as-a-service many AI coding tools wire up automatically, exposes a REST-like API directly to the browser, secured by a public anon key that's meant to be visible in client-side code. That's normal and by design. The actual security boundary is supposed to sit one layer deeper: Row-Level Security policies on each table, which decide who's allowed to read or write which rows, regardless of what key made the request.

When RLS isn't turned on, that boundary doesn't exist. The anon key alone is enough to query a table directly, and researcher Matt Palmer's subsequent scan found more than 170 live Lovable apps in exactly that state: unauthenticated requests that could read full user tables, API keys and access tokens for third-party services, and financial or subscription data, or write to those tables outright. The technique itself was mundane: a crafted HTTP request with a query parameter like ?select=* against a public database endpoint, no exploit chain, no zero-day, just a door that was never locked.

The vulnerability was assigned a CVSS base score of 8.26 (High), with a temporal score of 7.58, per the published advisory. Discovery was March 20, 2025, Lovable was notified the next day and acknowledged it March 24, and the advisory went public on May 29, roughly a ten-week coordinated disclosure window. Affected versions covered essentially all Lovable projects using an external database created up to that point, though the advisory notes later projects could be vulnerable too, since the underlying default didn't change.

Why this wasn't a one-off bug

This is worth separating from "someone shipped broken code," because that's not quite what happened. Lovable's generated apps worked. They rendered, they handled logins, they looked like real products, because from a functional standpoint, they were. What was missing wasn't a feature. It was a decision that never got made: whether every table Lovable wired up to Supabase should default to open or default to locked down.

It defaulted to open, and nothing in the normal act of building and testing an app would ever surface that. Clicking through screens, running through a demo flow, showing it to a friend, none of that sends the kind of raw, crafted request that reveals whether RLS is actually enforced. The gap sits exactly where this whole series keeps landing: invisible from inside the product, visible the moment anyone outside the team goes looking on purpose.

Why "it's fixed now" isn't quite true

Here's the part that makes this worth revisiting rather than filing away as 2025 news: Lovable didn't ship a patch. There was no code change that retroactively turned RLS on for existing projects, and the advisory's own mitigation guidance is to go implement and enforce RLS policies yourself, table by table. That's the right technical fix, but it depends entirely on someone doing it.

Which means the actual population of exposed apps isn't fixed by time passing. A Lovable-and-Supabase app built the week the advisory dropped, and one built last month, can both still be running with RLS off, because the default that caused this in the first place was never the thing that changed. "This was patched" is the wrong mental model here. "This is a setting every project owner has to go turn on themselves, and plenty haven't" is the accurate one.

How to check your own app

You don't need database credentials to find out whether this applies to you, and you don't need to be the one who built the app either.

The direct check: if your app uses Supabase, look at whether Row-Level Security is enabled on every table that holds anything sensitive, user records, API keys, payment or subscription data, in the Supabase dashboard under each table's settings. "Enabled with no policy" is often just as exposed as "disabled," so the policy itself needs to actually restrict access, not just exist. If you didn't set this up explicitly, there's a real chance nobody did.

The outside-in version of the same check is what a scan is for: probing the app's public endpoints the same way an attacker would, without needing access to the Supabase project itself, to see whether unauthenticated requests can pull data they shouldn't be able to.

Your turn

CVE-2025-48757 is over a year old, and it's still an active, checkable risk on any app where nobody went back and turned RLS on. You don't need to relive the disclosure timeline to find out if that's your app. You need to run the scan.

No setup, no coding, no passwords required. Drop in your app's URL, and in about two minutes you get a full scorecard: security, performance, infrastructure, and SEO, each out of 100, every finding in plain English, with a toggle between the founder view and the full technical one.

Scan your site for free →

If you're building on Lovable more broadly, our full Lovable app security checklist covers this finding alongside the other gaps that show up by default.