I keep getting hired to clean up apps built with Lovable, Bolt, Cursor, and that whole crowd. One bug shows up often enough in that work that I went looking for how common it actually is outside my own client list.
So I scanned 66 live apps built on those tools. Public stuff only, the JavaScript bundle each app already ships to your browser, plus one harmless read per table to confirm what was open. No app was named. Nothing was saved beyond a count, and nothing was exploited.
The headline number: 32 of the 66 run on Supabase. 13 of those 32, about 4 in 10, had at least one database table anyone could read using the app's own public anon key. No login, no exploit. 5 of the 32 exposed something that had no business being public: user tables, subscriptions, private support chats, audit logs.
This is a data report, not a takedown of any one tool. The bug is not "Supabase is insecure." The bug is that Supabase ships an anon key that is supposed to be public, and the app is supposed to pair it with a row-level security (RLS) policy that says who can read what. AI builders reliably wire up the key and reliably skip the policy, because the demo works either way.
Methodology
Transparency matters more than the stat here, so here is exactly what I did and did not do.
- Sample: 66 live apps built on Lovable, Bolt, Cursor, base44, or Tempo, sourced via certificate-transparency logs on their deploy domains and filtered down to apps that were actually live and reachable.
- What I collected: the public JavaScript bundle each app already sends to every visitor's browser, nothing more.
- What I ran: one
GETrequest per table,limit 1, using the anon key already present in that bundle. This confirms whether a table is readable, nothing more. No data was downloaded and no write ever touched an authenticated route. - What I did not do: no app was named. No data was saved beyond an aggregate count. No app was contacted, and no request went past a single-row read. No service_role keys were used or found anywhere in the sample.
- What this sample is not: small and builder-skewed. Sixty-six apps sourced from public deploy domains is not a random sample of "all software," or even of all AI-built software. The claim in this report is scoped to "AI-built apps I could find live on the public web," not to the category as a whole.
Of the 66 apps, 32 run on Supabase specifically. The rest use other backends, and I did not extend this pass to those, because the anon-key pattern is Supabase's particular shape of the problem. Other backends fail in their own ways, that is a different report.
The finding: 13 of 32 Supabase apps had a readable table
Of the 32 apps on Supabase, 13, or 41%, had at least one table that returned rows to an unauthenticated request carrying only the public anon key. That is RLS either disabled or misconfigured on at least one table in the schema.
Not every open table is a problem. Some of what I found was clearly meant to be public: a product catalog, a list of blog posts, a config table with feature flags. I did not count those toward the sensitive-finding number below, because publishing a products table on purpose is a design choice, not a leak.
5 of the 32 Supabase apps, about 1 in 6, exposed a table that had no business being world-readable. Across the sample, the sensitive tables I found included:
users,user_roles,user_profiles,profilessessions,session_summariessubscriptionssupport_chats,chat_messages,live_chat_messagesaudit_logsemployee_profiles,employee_team_assignments- a bookings table (
agendamentos) - one regulated operation's compliance tables (cannabis seed-to-sale tracking style tables, the category is the point here, not the specific business)
None of this required an exploit. It required opening a browser's network tab, copying the anon key the app already publishes, and asking the database for a table by name. That is the entire attack. It is also, not coincidentally, the entire self-check later in this post.
Why this keeps happening: named incidents, not a one-off
This pattern is not new and it is not rare. It has already produced real, documented incidents, so if the framing here sounds abstract, here is what it looks like at scale.
CVE-2025-48757, the Lovable RLS disclosure. In March 2025, security researcher Matt Palmer was testing a Lovable-built app and found he could strip the authorization header off a request and still read the full user database, because RLS was missing or misconfigured. He and a colleague built a scanner and ran it against 1,645 Lovable apps pulled from the platform's own gallery of public projects. 170 of them, about 1 in 10, had the same class of critical exposure across 303 vulnerable endpoints. The finding earned a CVSS score of 8.26 and was assigned CVE-2025-48757 after a 45-day responsible-disclosure window passed with no fix.
The RedAccess "shadow builders" report. In 2026, security firm RedAccess ran a much larger version of the same scan across Lovable, Base44, Replit, and Netlify, and found roughly 380,000 apps built with vibe-coding tools sitting exposed on the open web. About 5,000 of them were actively leaking sensitive data: medical records, financial documents, clinical trial information, unredacted customer conversations. WIRED and Axios both covered the findings independently. RedAccess's CEO called it one of the largest involuntary exposures of corporate data on record, and the cause was not a sophisticated attack, it was default configuration nobody thought to check.
Moltbook. In January 2026, an AI social network called Moltbook went viral and was breached within days of its launch. The cause: a Supabase key exposed in client-side JavaScript with no RLS policies on the tables behind it, the exact pattern in this report. The exposure included 1.5 million API tokens and 35,000+ email addresses, and researchers found plaintext third-party API keys sitting in what were supposed to be private messages. It was reported and patched within hours, but the database was fully open until someone happened to look.
The common thread across all three: the anon or public key is not the vulnerability. It is meant to be public, that is how Supabase's model works. The vulnerability is the missing policy on the other side of that key, and AI builders ship that gap by default because the demo passes without it.
The 60-second self-check
You do not need a scanner or a security background to check your own app. This is the exact test behind every number in this report.
- Open your app in a browser with dev tools open, on the Network tab.
- Load a page that touches your database. Find the request going to
<your-project>.supabase.co. - Copy the
apikeyheader from that request. That is your public anon key. It is meant to be in your JavaScript bundle, so finding it is not the problem. - Open a terminal (or a tool like Postman/Insomnia) and run a direct read against your own REST API, replacing the placeholders:
curl "https://<your-project>.supabase.co/rest/v1/<table_name>?select=*&limit=1" \
-H "apikey: <your-anon-key>" \
-H "Authorization: Bearer <your-anon-key>"
- Try this against every table your app touches, especially anything holding user data, sessions, messages, subscriptions, or internal records.
If a row comes back, that table has no RLS enforcing who can read it, and anyone with your anon key (which is public by definition) can read the whole table, not just one row. If you get an empty array or a permissions error, RLS is doing its job on that table. Repeat for every table. It took me longer to write this section than it will take you to run it.
If you find a table wide open, the fix is a Postgres policy, not a rewrite: enable RLS on the table, then add a policy scoped to the actual owner column, something like auth.uid() = user_id. The fast version of this check, done right, catches the exact failure mode behind CVE-2025-48757 and Moltbook.
What this data does and does not tell you
This report tells you that in a sample of 66 live AI-built apps, the RLS gap was common enough to hit 41% of the Supabase-backed subset, and severe enough to expose real sensitive data in 1 of every 6. It does not tell you that your specific app is affected. It does not tell you Supabase is unsafe, Supabase's model works fine when the policy layer gets written. It does not tell you every AI builder ships this bug, plenty of the apps in this sample had clean RLS.
What it tells you is that the failure mode is common enough, and invisible enough from the outside, that "I built it with a tool that's supposed to handle security" is not a safe assumption. The check above costs you a minute. Not checking costs whatever is in the table you didn't look at.
If you want someone else to run this check, plus the related checks that a public REST scan cannot reach (auth boundaries, storage buckets, server-side routes), the Leak Check is free and takes about the same effort as reading this post. It never DMs you. You get a report, not a sales call.
If you want a second set of eyes on this, or on the auth and storage-bucket checks a public REST scan cannot reach, the Leak Check is free. No call, no DM, just a report.