Breach breakdowns

Breakdown: Crissy Field found thousands of Lovable apps with open Supabase tables

By Pritesh Ghodge, security engineer · Published 6 November 2026

In early November 2026, German security firm Crissy Field GmbH published research (with Handelsblatt) on apps built with Lovable. Using Common Crawl, they examined 159,041 Lovable projects and found many cases where personal and confidential information was reachable without logging in. This is a plain-English breakdown of what they reported, what the numbers do and don't mean, and how to check your own app.

Timeline

• December 2025 – September 2026: Crissy Field draws a Common Crawl sample of Lovable projects and analyses those that use Supabase.
• 2 November 2026: Lina Knees reports the findings in Handelsblatt (in German). Crissy Field notes that its English research report has more recent analysis and updated figures than that article.
• Early November 2026: Crissy Field publishes the English write-up. Cybernews, India Today, Techzine and others cover it.

What the researchers found

From Common Crawl they identified 159,041 Lovable projects (Dec 2025–Sep 2026). Of those, 34,545 used Supabase.

24,664 of the sites sent Supabase records as soon as the page loaded, with no login. Crissy Field is clear that this alone is not automatically a leak: the data may be intentional public content.

With extra read-only requests using the same public API key, they found email-bearing records in 10,560 tables across 7,403 of those 24,664 sites (30%).

Caveats they stress (read these before quoting the 30%):

• Emails may be public contact addresses or test data, so the figure is not a confirmed leak rate.
• The method misses personal rows that have no email address.
• The 30% applies only to the 24,664 sites they examined more closely; the Common Crawl sample is not representative of all Lovable apps.
• They retrieved only parts of datasets, not full dumps, and are not publishing access details.
• They could not establish misuse.

Serious examples they describe (organisation types only, as in the reporting):

• A German lifestyle forum: more than 80,000 profiles (names, emails, dates of birth, gender) plus more than 200,000 chat messages.
• Event organisers and restaurants: ticket and food sales records including emails, phone numbers, postal addresses, payment information and ticket codes.
• A property management company: AI-generated summaries of internal emails about tenants, property owners and business partners.
• A service provider: more than 1,000 identity-document records (passport numbers, expiration dates, nationalities).
• Other accessible content included contracts, invoices, personal photo albums and internal WhatsApp communications; in one case, 280,000 customer emails were accessible.

They focused on Supabase as the most common database integration. Lovable's own late-2025 database features were not examined.

Root cause

Same class of miss as CVE-2025-48757 (the smaller 2025 Lovable Launched scan), on a much larger sample.

The Supabase anon / publishable key is meant to be public. Access depends on Row Level Security (RLS). When RLS is missing, or policies are overly broad (for example using (true) for anonymous reads), anyone who can see the key in the browser can read those tables.

That matches what Crissy Field describes: records reachable with the same public API key the page already uses, without logging in.

How to check your own app

Only test projects you own.

1. Open your live site, then DevTools → Network. Filter for supabase.co (or your database host).
2. Copy the project URL and the apikey header value (the anon or sb_publishable_ key).
3. For each table you see, run:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/TABLE?select=*&limit=1" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

• [] or a permission error: an anonymous visitor gets nothing. Good.
• A row of real data: anyone on the internet can read that table.

4. In the Supabase SQL editor, list every policy:

select tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'public';

Anything with qual = 'true' for anon or public deserves a second look. Also open Database → Security Advisor and clear the warnings before you ship.

The free Supabase RLS policy checker reads pg_policies for you in your browser.

Fix steps

1. Turn on RLS for every table in public:

alter table public.profiles enable row level security;

2. Replace "allow everyone" policies with owner-only ones:

drop policy if exists "Enable read access for all users" on public.profiles;

create policy "own rows"
  on public.profiles for select
  to authenticated
  using ((select auth.uid()) = user_id);

Add matching insert, update and delete policies with with check clauses.

3. Keep genuinely public data public on purpose (a published blog list is fine). Do not put emails, phones, ticket codes, IDs or internal summaries in tables the anon role can select.
4. Re-test signed out after every big AI-generated change. Agents that hit a permission error often "fix" it by loosening a policy.
5. Run Security Advisor and the curl test above before you put real customer data in.

The takeaway

Crissy Field's sample is larger than the 2025 Lovable Launched scan behind CVE-2025-48757, and the pattern is the same: the public anon key isn't the bug — missing or overly broad RLS is. Treat their 30% as a finding inside a specific subsample with clear caveats, not a platform-wide leak rate. Then spend ten minutes testing your app from the outside, as an anonymous visitor.

Abbi Labs runs these anonymous checks for you (one row max per table, nothing stored), and the free Supabase RLS policy checker reads your policies. Or use the curl test above.

Scan your app free

Sources

• Crissy Field GmbH, "Lovable: Many Apps Built on the Platform Expose Sensitive Data" (primary; notes Handelsblatt reporting by Lina Knees, 2 Nov 2026)
• Cybernews, Lovable AI apps expose personal information
• India Today, AI app maker Lovable apps expose personal details
• Techzine, Thousands of Lovable apps are leaking personal data
• CTXSec, Crissy Field Lovable / Supabase unauthenticated data (7,403 sites)

Related

• Breakdown: how 170 Lovable apps left their Supabase data open (CVE-2025-48757)
• How to check if your Supabase tables are readable by anyone
• Is the Supabase anon key safe to expose?
• Tip: Supabase RLS using (true)