Post-Mortem of the Lovable CVE That Exposed 170+ Apps

On June 4, 2025, security researcher Matan Getz published a disclosure that became the defining security incident of the vibe coding era. CVE-2025-48757 revealed that Lovable, a platform with over 8 million users and roughly $400 million in annual recurring revenue, had been generating Supabase database schemas without enabling Row Level Security. More than 170 production applications were confirmed exposed.

"The S in vibe coding stands for security" became the joke on every developer forum. But underneath the humor was a serious question: how does a platform valued in the billions ship a default configuration that leaves every user's database wide open?

Come along with me through the full timeline of what happened, why it happened, and what it means for anyone building with AI coding tools.

The House Without Locks

Imagine hiring a contractor to build your dream house. The contractor works fast, the finished house looks beautiful. Walls are solid, paint is flawless, kitchen is exactly what you asked for. You move in and sleep soundly.

Months later, a locksmith friend visits and points out something you missed: there are no locks on any of the doors. The front door, the back door, the garage. Anyone can walk right in.

That is exactly what happened with Lovable and Supabase. The AI built functional applications with working database connections. It generated the tables, the queries, the user interfaces. Everything worked. But it never installed the locks. Row Level Security, the mechanism that controls which users can see which rows of data, was never enabled.

Timeline of the Incident

Late May 2025. Security researcher Matan Getz begins investigating Lovable-generated applications and finds a pattern: Supabase projects created through Lovable have Row Level Security disabled by default.

June 4, 2025. Getz publishes his disclosure, assigned CVE-2025-48757. The report identifies over 170 production applications with fully accessible databases, meaning any user (or anonymous request) can read, modify, or delete any row in any table.

June 4-6, 2025. The disclosure goes viral. Researchers estimate the true scope extends well beyond 170 apps, since every Lovable user who followed the default Supabase setup was likely affected.

June 6-10, 2025. Lovable updates their code generation pipeline to include RLS policies in new schemas. Existing applications remain vulnerable unless owners manually enable RLS.

Mid-June 2025. Supabase releases documentation and tooling for Lovable users, including a one-click RLS audit.

The Technical Root Cause

In Supabase (built on PostgreSQL), every table has an optional feature called Row Level Security. When RLS is enabled, the database checks a set of policies before allowing any read, write, update, or delete operation. These policies define rules like "users can only read rows where the user_id column matches their own ID."

When RLS is disabled, there are no policies. Anyone with access to the database can do anything to any row. In Supabase, "anyone with access" means anyone who has the public API key, which is embedded in client-side JavaScript and visible to anyone who opens browser developer tools.

Here is what a secure Supabase table creation looks like:

CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  display_name TEXT,
  email TEXT
);

ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

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

CREATE POLICY "Users can only update their own profile"
  ON user_profiles
  FOR UPDATE
  USING (auth.uid() = user_id);

Here is what Lovable was generating:

CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  display_name TEXT,
  email TEXT
);

No ENABLE ROW LEVEL SECURITY. No policies. The table exists, the data flows, the application works. The house looks perfect, but there are no locks.

Why AI Tools Optimize for "Make It Run"

This is where the incident stops being about Lovable and becomes systemic. Large language models optimize for functional correctness. Does the code compile? Does it produce the expected output? Does it connect to the database?

Security exists in tension with that goal. Enabling RLS adds complexity: defining policies, handling edge cases, debugging authentication flows. The path of least resistance is to skip it, because the application works either way. The user asks for a todo app, the AI delivers one that stores and retrieves todos. The fact that every other user can also read those todos is invisible during testing.

Every major AI coding tool exhibits versions of this pattern:

• Bolt generates API routes without authentication middleware unless explicitly prompted.
• Cursor produces database queries that work correctly but lack input sanitization.
• Replit scaffolds projects with environment variables exposed in client-side bundles.

The pattern is always the same. AI optimizes for the happy path where every user is legitimate. Security is the unhappy path where users are malicious. The unhappy path gets deprioritized because it does not affect whether the demo works.

The Scope of Damage

The confirmed 170+ exposed applications are only the cases researchers identified. The actual number is almost certainly larger. Lovable has over 8 million users, and the vulnerability affected every application using the default Supabase setup flow.

The data exposed included user emails, authentication tokens, private messages, financial records, and anything else stored in unprotected tables. For a platform marketed to non-technical founders, the users least equipped to respond were the ones most likely affected.

What Affected Users Should Do Right Now

If you built an application with Lovable that uses Supabase, assume you are affected until you verify otherwise.

Audit RLS status. In your Supabase dashboard, check each table. If you see "RLS disabled" on any table containing user data, you are vulnerable.

Enable RLS and create policies. Run ALTER TABLE your_table_name ENABLE ROW LEVEL SECURITY; for every table, then define policies for who can read, insert, update, and delete rows. The most common pattern restricts access to rows where a user_id column matches the authenticated user.

Rotate your API keys. Your public API key was exposed if your app was deployed. Generate new keys and update your application.

Check for unauthorized access. Review Supabase logs for unusual query patterns or bulk data reads. If you stored personal data and believe it was accessed, you may have notification obligations under GDPR or CCPA.

The Broader Pattern

CVE-2025-48757 is the highest-profile example, but it is not an isolated incident. The Tea App leaked 72,000 private images and 1.1 million messages due to missing access controls. Moltbook exposed 1.5 million authentication tokens through improperly secured API responses. A Veracode study found that 45% of AI-generated code introduces security vulnerabilities, with AI code 2.74 times more likely to contain cross-site scripting flaws than human-written code.

The through-line is consistent. AI tools build the walls but skip the locks. Return to the house analogy: the contractor was not malicious. They optimized for what the homeowner would notice during the walkthrough. Nobody tests door locks at a showing. They admire the countertops. Locks are invisible infrastructure, exactly what gets skipped when speed is the priority.

Lessons for the Vibe Coding Community

This incident crystallizes several lessons that apply to every AI coding tool, not just Lovable.

Never trust default configurations. If an AI tool sets up a database or any external service, verify the security configuration manually. Defaults optimize for speed, not safety.

Security is not a feature you add later. The 170+ affected applications were production apps serving real users. The gap between "it works" and "it works safely" was invisible until a researcher went looking.

AI tools need security-aware defaults. Lovable has since updated their code generation, but the fix should have been the default from day one. Platforms serving non-technical users cannot rely on those users to compensate for security gaps.

What This Means For You

CVE-2025-48757 is not just a Lovable story. It is a preview of what happens when an industry optimizes for speed over security. Every AI coding platform faces the tension between "make it work" and "make it safe," and the market rewards the former far more than the latter.

• If you are a founder, schedule a security audit before your first real user touches the product. Under GDPR, breach fines can reach 4% of annual revenue. If you are using Supabase, run the RLS audit today. For any other database, verify access control at the database level, not just in application code.

• If you are a senior developer, treat every AI-generated infrastructure configuration as untrusted until verified. The Lovable CVE could have been caught by a single code review asking "is RLS enabled on these tables?" Add that question to every workflow involving AI-generated schemas.

• If you are an indie hacker, build a pre-deployment checklist: RLS enabled, API keys not in client bundles, authentication on every route, input validation on every form. Five minutes prevents incidents that take months to recover from.

The vibe coding community earned a joke at its expense with this incident. But jokes aside, the lesson is clear: the tools are powerful, the output is impressive, and the security gaps are real. The walls look great. Make sure you install the locks.