Is Lovable Secure? What CVE-2025-48757 Means for Your App

What Happened

In May 2025, security researcher Matt Palmer discovered a significant vulnerability in apps built with Lovable. The issue, tracked as CVE-2025-48757, affected Row Level Security (RLS) configurations in Supabase databases.

The numbers:

• 170+ applications had exploitable endpoints
• 303 endpoints across those apps were vulnerable
• Attackers could read and write to databases without authentication

What was exposed:

• Google Maps API tokens
• Gemini API keys
• eBay authentication tokens
• Complete user databases
• Financial transactions
• Subscription details

This wasn't theoretical. Real apps, real data, real exposure.

What Went Wrong

The root cause was RLS misconfiguration. When Lovable set up Supabase tables, the Row Level Security policies were either:

• Not enabled at all - Anyone could query anything
• Enabled but misconfigured - Policies existed but didn't actually restrict access
• Using overly permissive rules - Like USING (true) which allows everything

Why This Matters for Vibe Coding

This is the core tension of AI-generated code:

• Lovable generates code that works
• "Works" doesn't mean "secure"
• You didn't review the RLS policies because... why would you?

The AI set up the database. It created tables. It probably mentioned RLS. But did you actually understand what policies were created and whether they made sense for your specific app?

Most vibe coders: No.

Lovable's Response

To their credit, Lovable responded quickly:

• Security Scanner - They added a built-in security scan feature (visible in the publish dialog for Supabase-connected apps)

• Lovable 2.0 - Released with security as a major focus

• Fast Fixes - When other vulnerabilities were reported (like the account takeover issue found by Vidoc Security), they patched within hours

Is YOUR Lovable App Affected?

Quick Check

• Go to your Supabase dashboard
• Navigate to Database → Tables
• For each table with user data, click on it
• Check "RLS enabled" and review the policies

What to Look For

Red flags:

• RLS not enabled on tables with user data
• Policies using USING (true)
• No policies at all (just RLS "enabled" without rules)
• SELECT policies that don't filter by user ID

Example of a BAD policy:

CREATE POLICY "Allow all" ON users
FOR ALL USING (true);

Example of a GOOD policy:

CREATE POLICY "Users can only read their own data" ON users
FOR SELECT USING (auth.uid() = user_id);

The "Security Scanner Passed" Problem

Here's the uncomfortable truth: Lovable's security scanner can show all green checkmarks while your app is still vulnerable.

The scanner checks:

• Does RLS exist? ✓
• Are there policies? ✓

The scanner doesn't check:

• Do the policies actually make sense?
• Can unauthenticated users access protected data?
• Are your policies aligned with your application logic?

Passing the scan ≠ Being secure

You need to actually understand what each policy does and whether it matches your app's requirements.

How to Actually Secure Your Lovable App

Step 1: Audit Every Table

For each table in your Supabase database:

• What data does it contain?
• Who should be able to read it?
• Who should be able to write to it?
• Are the current policies enforcing that?

Step 2: Test Your Policies

The best test: Try to break your own app.

• Open your app's API in a tool like Postman
• Try to access data without being logged in
• If logged in as User A, try to access User B's data
• Can you write/update/delete things you shouldn't?

Step 3: Fix What's Broken

Common fixes:

• Add auth.uid() = user_id to SELECT policies
• Remove USING (true) policies
• Add policies for INSERT/UPDATE/DELETE, not just SELECT
• Consider using RLS for sensitive columns, not just rows

Step 4: Set Up Ongoing Monitoring

Your app isn't static. You'll add features. Lovable will generate more code. New tables will appear.

Make security review part of your workflow, not a one-time thing.

Should You Still Use Lovable?

Yes, but with eyes open.

Lovable is a powerful tool. It lets non-developers build real applications. That's genuinely valuable. But:

• You are responsible for security, not Lovable
• AI-generated code needs review, especially around auth and data access
• One-time scans aren't enough, security is ongoing

The vulnerability wasn't really Lovable's fault—it was a misconfiguration in the generated code. The same thing could happen with any AI coding tool. The lesson isn't "don't use Lovable." It's "understand what you're deploying."

The Bigger Picture

CVE-2025-48757 is a wake-up call for the entire vibe coding movement:

Vibe coding makes building easy. It doesn't make security easy.

When you prompt an AI to "create a user profile system with Supabase," it will. It'll set up tables, write queries, create UI. Whether those tables are properly secured? That's your job to verify.

This isn't going away. As more people build with AI, more vulnerabilities like this will emerge. The tools will get better, but the fundamental tension remains: AI optimizes for "it works," not "it's secure."

Your Next Steps

• Audit your Lovable app's RLS policies - Today
• Run Lovable's security scanner - But don't stop there
• Actually test your API - Can you access things you shouldn't?
• Set up dependency scanning - New vulnerabilities emerge constantly
• Stay informed - Follow Lovable's security updates

---

SlyDuck monitors your Lovable app's dependencies for security vulnerabilities. Get continuous scanning—because one security check isn't enough.