CVE-2025-48757 describes a Row Level Security failure in Lovable-generated sites that lets an unauthenticated stranger read or write arbitrary database tables. MITRE scored it 9.3, critical. Lovable disputes it, arguing customers own their application data.
Both positions can be true at once, and that is the whole problem with shipping a Lovable app. The platform is not what leaks. Your generated app is.
TL;DR
Lovable's own infrastructure is reasonably run. The apps it writes for you are not production-ready on their own. Five failures cover almost everything that goes wrong: RLS off or wide open, a service key in the browser bundle, auth checks that only run in React, secrets in VITE_ variables, and a public project exposing its prompt history. Fix those five and you have removed the paths that actually leak data.
What Is Lovable?
Lovable (formerly GPT Engineer) builds full-stack web apps from a natural-language description. You get a React frontend, a Supabase backend, and one-click deployment, with GitHub sync if you want the code out.
It is genuinely fast. That speed is also why the security gap exists: the model writes what you asked for, and you did not ask for authorization.
The Five Risks That Actually Break Lovable Apps
These are ranked by what we see leak, not by what sounds alarming.
1. Row Level Security is off, or written to always pass
This is the one. Supabase tables start without RLS, and a generated app can talk to the database perfectly well while every policy is missing. Nothing errors. Your app works.
What it exposes: every row of every table an attacker can name. Reads, writes, deletes.
Check this first. Open your Supabase dashboard, go to Table Editor, and look at the shield icon on each table. A table holding user data with RLS disabled is readable by anyone who opens your site and copies the anon key out of the network tab. That takes about thirty seconds.
The subtler version is worse, because it looks fixed. A policy of USING (true) has RLS enabled and grants everyone everything. Enabled is not the same as enforced. Read each policy, not just the badge.
2. A service_role key reached the browser
Supabase publishes two kinds of key and they are not interchangeable. The anon (publishable) key is designed to sit in your frontend: Supabase's own docs call it "safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code." Row Level Security is what protects it.
The service_role key is the opposite. Supabase describes it as having "full access to your project's data, bypassing Row Level Security," and it carries Postgres's BYPASSRLS attribute, "skipping any and all Row Level Security policies you attach."
If that key is in your bundle, your policies are decoration.
# Pull every JS asset your live site loads and grep for the giveaway.
curl -s https://your-app.lovable.app | grep -oE '/assets/[^"]+\.js' | \
while read f; do curl -s "https://your-app.lovable.app$f"; done | \
grep -oE 'eyJ[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]+' | sort -u
Paste any JWT it returns into jwt.io and read the role claim. anon is fine. service_role means rotate the key today and audit what happened while it was live.
3. The auth check runs in React and nowhere else
A generated app hides the admin link when user.role !== 'admin'. That is a UI decision, not an authorization boundary. The API call underneath still succeeds if you make it directly.
This is the failure mode behind the exam-app breach below, and it is the hardest for a non-technical founder to spot, because clicking around the app as a normal user shows nothing wrong. The app behaves. The check just never happens where it counts.
The fix is to push the rule into the database as an RLS policy, or into a Supabase Edge Function that verifies the JWT server-side. If the rule only exists in a .tsx file, it does not exist.
4. Secrets in VITE_ environment variables
The old advice for leaked API keys was "move them to environment variables." For a Vite-built React app that advice is actively wrong: any variable prefixed VITE_ is inlined into the client bundle at build time. You moved the secret from one public place to another.
Lovable's docs are now explicit that "API keys and other secrets cannot be stored safely in client-side code," and the documented pattern is to store the value in Secrets and call the third-party API from an Edge Function. Your OpenAI key, your Stripe secret key, your Resend key: all of them belong server-side.
5. The project is public, and so is its prompt history
In April 2026 a Broken Object Level Authorization flaw let free-tier accounts read the chat histories of other people's public projects. Those histories routinely contain pasted credentials, business logic, and customer details, because that is what people paste into a builder.
Reporting differs on the exact cutoff: Halborn says only public projects created before December 2025 were affected, while The Next Web put it before November 2025. Either way, if you created a public project in 2025 and pasted a key into the chat, treat that key as burned.
The Incident Record
Our earlier version of this page described the risks in the abstract. Here is the actual paper trail, which is more persuasive than any warning we could write.
The cutoff version for CVE-2025-48757. Insufficient RLS policy in Lovable allows remote unauthenticated attackers to read or write arbitrary database tables of generated sites.
CVE-2025-48757 published. CVSS 3.1 base score 9.3 (critical), CWE-863 Incorrect Authorization. Lovable disputes the entry, stating customers bear responsibility for protecting their application data.
The Register publishes researcher Taimur Khan's findings on a Lovable-hosted exam app featured on Lovable's own Discover page: 16 vulnerabilities, six critical, 18,697 user records exposed including 4,538 student accounts.
A researcher reports the BOLA chat-history flaw through Lovable's HackerOne program. Lovable patches new projects but leaves existing ones exposed. A second report is closed as a duplicate.
Public disclosure, 48 days after the report. Lovable calls the behaviour intentional, then points at its documentation, then at HackerOne, and later the same day apologises and concedes that blaming documentation was not enough.
The exam app is worth dwelling on because of how it failed. The generated authentication logic was inverted: it blocked users who were logged in and admitted anonymous visitors to everything.
::
Our Verdict
What's Good
- Clean, modern React code
- Supabase integration built-in
- Built-in Basic and Deep security scans
- GitHub sync and full code export
- One-click deployment
What to Watch
- RLS not configured by default
- Auth logic can be generated inverted
- Service keys can reach the client bundle
VITE_variables are not secrets- Public 2025 projects leaked prompt history
Good for: prototypes, internal tools, landing pages, and MVPs with non-sensitive data, where you plan to harden before real users arrive.
Be careful with: payment data, health information, and anything involving minors. The exam app that leaked 18,697 records included 4,538 student accounts, and that is the exact category where a mistake stops being a bug and becomes a notification obligation.
What are the biggest security risks in a Lovable app?
Five failures account for nearly everything we find: Row Level Security left off or written permissively, a Supabase service_role key shipped in the browser bundle, auth checks that only run in React, secrets pasted into VITE_ environment variables, and a project left public so its prompt history is readable. The first two leak the whole database, so start there.
What is CVE-2025-48757?
A critical Row Level Security flaw affecting Lovable through 2025-04-15, scored CVSS 9.3 by MITRE and classified CWE-863 (Incorrect Authorization). It allowed unauthenticated remote attackers to read or write arbitrary database tables of generated sites. Lovable disputes the CVE, arguing that customers are responsible for protecting their own application data. Whichever side you find more convincing, the practical takeaway is identical: check your own policies.
Is Lovable safe for production?
The platform is safe to build on. What it generates is not safe to launch unreviewed. Run the Deep Scan, verify RLS on every table holding user data, and confirm no service key reached the client bundle. For payment, health, or children's data, get a real security review before launch.
Is the Supabase anon key in my bundle a leak?
No. Supabase documents the anon (publishable) key as safe to expose in a web page, and Row Level Security is what guards it. The key that must never reach the browser is service_role, which carries the BYPASSRLS attribute and skips every policy you wrote. If you are unsure which one you are looking at, decode the JWT and read the role claim.
Can I fix these issues without coding knowledge?
Partly. Enabling RLS and setting project visibility are dashboard clicks. Writing a correct policy, or moving a Stripe key into an Edge Function, needs someone who can read the code Lovable wrote. The checks in the list above are all doable by a founder in an afternoon; the fixes for items three and four usually are not.
Built with Lovable?
We scan your live app for missing RLS, exposed service keys, and auth that only runs in the browser.