In early June 2025, security researcher Matan Getz disclosed CVE-2025-48757, a vulnerability that exposed more than 170 applications built on Lovable, one of the most popular AI app builders on the market. The root cause was not a sophisticated exploit. Lovable's AI was generating Supabase database configurations with Row Level Security disabled by default. Anyone who opened browser developer tools could see the API keys and access every row in every unprotected table.
With 92% of developers now using AI tools daily and studies showing AI-generated code ships 1.7x more major security issues than human-written code, the Lovable CVE is not an outlier. It is a warning sign. This case study walks through what happened, the technical root cause, and the concrete steps every vibe coder should take to prevent the same pattern in their own projects.
The Key Taped to the Front Door
Think of building a web application like building a house. Your database is the safe inside, and the API key is the key to that safe. What Lovable's AI did was the equivalent of building a beautiful house and then taping the key to the front door with a sticky note that said "safe key." The house looked perfect. Everything worked. But anyone who walked up and read the note could open the safe and take whatever they wanted.
Supabase's public API key, called the anon key, is designed to be used in client-side code. That is normal. What makes it safe is Row Level Security (RLS), a set of rules defining who can access which data. Without RLS, the anon key grants unrestricted access to every table. Lovable's AI was generating schemas without enabling RLS, which meant the key taped to the front door actually opened every room in the house.
What Happened, Step by Step
Late May 2025. Matan Getz begins investigating Lovable-generated applications and discovers that tables created through Lovable's AI consistently lack RLS policies.
June 4, 2025. Getz publishes his disclosure, formally assigned CVE-2025-48757. The report confirms more than 170 production applications with fully accessible databases.
June 4-6, 2025. The disclosure spreads rapidly. "The S in vibe coding stands for security" trends across developer forums. The actual number of affected apps is likely far higher, since every Lovable user who followed the default Supabase setup was potentially exposed.
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 a one-click RLS audit tool to help affected users identify and fix unprotected tables.
The gap between disclosure and patch was roughly two weeks. But the vulnerability had existed for the entire lifespan of the platform. Every application built before the fix carried the same exposure.
The Technical Root Cause
Supabase is built on PostgreSQL, which has an access control mechanism called Row Level Security. When RLS is enabled on a table, every query must pass through policies that define who can see and modify which rows. When RLS is disabled, the table has no access restrictions. The anon key, which is intentionally public and embedded in client-side JavaScript, can query anything.
Lovable's code generation was producing schemas like this:
CREATE TABLE user_data (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES auth.users(id),
email TEXT,
private_notes TEXT
);
What it should have been generating:
CREATE TABLE user_data (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES auth.users(id),
email TEXT,
private_notes TEXT
);
ALTER TABLE user_data ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users read own data"
ON user_data FOR SELECT
USING (auth.uid() = user_id);
CREATE POLICY "Users update own data"
ON user_data FOR UPDATE
USING (auth.uid() = user_id);
The missing lines are the difference between a locked safe and an open one. The AI optimized for the code that makes the app work. RLS is not required for functionality. It is required for security. And the AI treated those as different priorities.
The Lovable CVE was not caused by a complex exploit or a novel attack vector. It was the absence of a standard security feature. Row Level Security is not optional when your API key is public. If RLS is disabled, the key taped to the front door opens everything. Every vibe coder using Supabase should verify RLS is enabled on every table before deploying.
Why AI Tools Get Security Wrong
This vulnerability pattern is not unique to Lovable. It reflects a structural problem in how AI coding tools generate infrastructure.
Large language models learn from billions of lines of open-source code, much of it from tutorials, Stack Overflow answers, and prototypes that prioritize getting something working over getting something secure. The model learns what functional code looks like. It does not learn what secure code requires.
When a user prompts Lovable to "build a task management app," the AI focuses on tables, queries, and UI components. Security constraints like RLS are not part of the prompt, and the AI does not add them unprompted. The result is code that passes every functional test and fails every security audit.
Lovable reports that roughly 60% of their users are non-developers. These users have no mental model for Row Level Security or database access control. They trust the AI to handle the details, just as you trust a contractor to install locks without being asked. The contractor in this case skipped the locks because the house "worked" without them.
AI coding tools compete on speed and ease of use. Security adds friction. The path of least resistance is to skip it, and AI consistently chooses the path of least resistance unless explicitly instructed otherwise.
What Lovable Got Right in the Response
Credit where it is earned. Lovable's response moved relatively quickly once the disclosure went public.
The code generation pipeline was updated within a week to include RLS policies in new schemas. The AI now generates security policies as part of its default output. Supabase also responded constructively, shipping a one-click RLS audit that made it significantly easier for non-technical users to identify unprotected tables.
The limitation was that the fix only applied to new applications. Existing apps in production required manual intervention. For a platform with 8 million users, many of whom are non-technical, "manually enable RLS" is a high bar.
Assuming that because you built your app after the fix, you are safe. Lovable patched new code generation, but if you used any custom SQL, modified schemas after generation, or added tables manually, those tables may not have RLS enabled. Always verify every table individually in your Supabase dashboard, regardless of when you created the project.
Five Checks Every Vibe Coder Should Run Before Shipping
The Lovable CVE provides a concrete checklist that applies to any AI-built application, not just those on Lovable or Supabase.
1. Verify database access controls. If you use Supabase, check every table for RLS. If you use another database, verify that your application enforces access control at the database level, not just in application code. Application-level checks can be bypassed. Database-level controls cannot.
2. Search your client-side code for secrets. Open your browser's developer tools on your deployed application. Search the JavaScript bundles for API keys, tokens, and connection strings. If you find anything beyond a public anon key that is protected by RLS, you have an exposure.
3. Test as an unauthenticated user. Open an incognito browser window and try to access your app's API endpoints directly. If you can retrieve data that should be private without logging in, your access controls are missing.
4. Review AI-generated infrastructure code line by line. Application UI code is relatively low risk. Infrastructure code (database schemas, authentication flows, API middleware) is where AI tools consistently introduce vulnerabilities. Spend your review time on the highest-risk code.
5. Run a security scanner. Tools like the Supabase RLS audit, Escape.tech's scanner, or even a manual review against the OWASP Top 10 will catch the most common AI-generated vulnerabilities. Five minutes of scanning prevents months of incident response.
The security fundamentals every vibe coder needs before going live.
Read the security guideThe Bigger Picture for the Vibe Coding Community
CVE-2025-48757 landed at a moment when the vibe coding community was growing faster than its security practices could keep up. The incident forced a conversation that needed to happen.
AI coding tools are genuinely powerful. They compress weeks of work into hours and make software development accessible to people who never would have built anything otherwise.
But the key-taped-to-the-front-door problem is real. When the AI builds your house, it optimizes for what you can see during the walkthrough: the layout, the finishes, the features. It does not optimize for the invisible elements: the locks, the alarm system, the reinforced door frames. Those are exactly what protect you when someone tries the handle.
The lesson from the Lovable CVE is not that AI tools are dangerous. The lesson is that AI tools produce code that is functionally complete but security-incomplete, and closing that gap is your responsibility as the person who ships the product. The AI is the contractor. You are the homeowner. Check the locks before moving in.
A simple checklist prevents the most common AI-generated vulnerabilities.
Get the checklistThe 170+ applications exposed by CVE-2025-48757 did not fail because their builders were careless. They failed because their builders trusted the AI to handle something the AI was never designed to handle. Now you know. Check the locks. Verify the policies. Test as an attacker. Then ship.