Lovable Vulnerability Explained: How 170+ Apps Were Exposed

The Lovable vulnerability (identified as CVE-2025-48757) exposed over a hundred companies and apps. First discovered by Matt Palmer, it was caused by a row-level security (RLS) misconfiguration in the platform. 

‍

The vulnerability touched 303 endpoints across 170 of the tested apps. This allowed unauthenticated attackers to read and write to the databases of Lovable apps, compromising confidentiality and integrity.

‍

This article breaks down:

• What caused the vulnerability and how it was discovered
• How Lovable responded
• The lessons SaaS teams should take from it

The critical Lovable vulnerability: What happened?

The root cause of CVE-2025-48757 was insufficient or missing Row Level Security (RLS) policies in Lovable-generated projects. Instead of restricting data access to the right users, certain queries skipped the necessary checks.

‍

Attackers didn’t need special credentials. In many cases, the public anon_key embedded in the client allowed direct queries to Supabase. They could dump entire tables like full user lists, payment records, or API keys, without logging in by swapping the intended query.

‍

This was a single flaw with multiple impact points. It allowed remote, unauthenticated attackers to read or write arbitrary data in connected databases.

‍

This vulnerability represents a systemic design issue in AI-assisted platforms that rely on client-driven architectures and delegate database access controls to the end user.

Where the vulnerability showed up

The Lovable security vulnerability first became public when Matt Palmer identified it in Linkable, a Lovable site for generating sites from LinkedIn data. The site’s missing row-level security (RLS) setup lets anyone retrieve full user data by tweaking queries. His follow-up scan revealed that 303 endpoints across 170 projects lacked proper RLS.

‍

The misconfiguration took several forms:

• Endpoints serving private data with no authentication at all.
• Session tokens that could be spoofed to access another user’s account.
• Input fields open to malicious data injection.

The data exposed was not limited to emails. The tests retrieved:

• Usernames and emails
• Phone numbers
• Payment status and subscription data
• API keys (e.g., Gemini, Google Maps)
• Developer credentials
• Other sensitive business records tied to app integrations

One of the most striking cases came from public Stripe integration endpoints. Attackers could override payment settings or inject unauthorized parameters, enough to disrupt billing for a live application.

Lovable’s response

Lovable’s response to the critical Row Level Security (RLS) vulnerability was widely criticized as inadequate and non-transparent by security researchers and the broader app development community.

Discovery and disclosure of the vulnerability

Matt Palmer reported the vulnerability to Lovable on March 21, 2025, the day after confirming the RLS misconfiguration in a public app. His initial report included proof-of-concept examples showing unauthenticated data access. 

‍

On April 14, a Palantir engineer independently found and publicly tweeted about the same issue. The public exploit showed attackers retrieving personal debt amounts, home addresses, API keys, and other sensitive data from live Lovable apps. That same day, Palmer re-notified Lovable, referenced the public exploit, and formally initiated a 45-day coordinated disclosure window.

‍

Ten days later, on April 24, Lovable released “Lovable 2.0” with a new “security scan” feature. However, the scanner only flagged the presence of RLS, not whether it worked. It failed to detect misconfigured policies, creating a false sense of security.

‍

When the 45-day window closed without a meaningful fix, Palmer published his statement and the CVE-2025-48757 entry on May 29.

How Lovable fixed the issue

Lovable introduced a security scan feature that flags whether an RLS policy exists on a table. However, it doesn’t test if the policy actually prevents unauthorized access.

‍

The platform also added a security review tool that analyzes apps for potential security issues, offers remediation suggestions. Users also get warnings if they share an API key in chat.

‍

Following these releases, the company stated on X: “Lovable is now significantly better at building secure apps than a few months ago and this is improving quickly. That being said, we’re not yet where we want to be in terms of security and we’re committed to keep improving the security posture for all Lovable users.”

Community and industry reactions to the Lovable vulnerability

Online developer forums were filled with advice to avoid using Lovable for anything involving private or sensitive backend data. Many recommended using Lovable solely for the frontend and handling your backend using another framework to sidestep its RLS/security issues.

‍

A Reddit user who built an app with Lovable and Supabase wrote that the number of security failures was absurd. 

‍

Some users described Lovable sites as "a sitting duck for hackers".

‍

The prevailing sentiment is that any application handling real user data, private information, or integrating with external services is at heightened risk if built with Lovable, unless the developer can fully audit the configuration.

Lessons for SaaS teams going forward

CVE-2025-48757 shows how a single platform misconfiguration can fan out into hundreds of live vulnerabilities. When a platform embeds an insecure default, every application users build on that platform inherits the vulnerability.

‍

Both platform providers and the developers who build on them have a role in preventing these cascading risks.

The platform’s security responsibility

Platform teams set the baseline. That baseline should be secure by default, with clear documentation of any settings that could weaken it.

‍

Some of the best practices include:

• Ship secure-by-default configurations: Defaults should follow least-privilege principles so new projects start from a safe baseline.
• Validate effectiveness, not just existence: Security tooling should confirm that RLS, RBAC, and other controls actually prevent unauthorized access.
• Block or warn on insecure deployments: If a generated app has missing authentication or overbroad permissions, the platform should stop it from going live or display unavoidable warnings.
• Communicate quickly and clearly: When vulnerabilities are found, provide timelines, interim mitigations, and progress updates to maintain trust.
• Balance flexibility with guardrails: Let developers loosen restrictions when needed, but start from the most secure possible baseline.

The developer’s responsibility

Even with good guardrails, your own implementation is the last line of defense.

‍

Start by testing what the platform gives you:

• Audit endpoints manually: Attempt to access restricted data using alternative queries or endpoints.

• Verify scope: Inspect JWT tokens and OAuth claims for minimal scope. Ensure that APIs do not allow access tokens with broader privileges than necessary.
• Simulate roles: Simulate all user roles (admin, regular user, guest, and malicious actor) to check whether RLS rules correctly prevent cross-tenant or cross-user access.
• Run security scans: Crawl your app and look for endpoints that return data without requiring proper authentication or with excessive breadth.

Next, strengthen your configuration by using:

• Custom RLS policies for sensitive tables.
• Backend gateways or proxies for sensitive operations.
• Environment isolation for dev, staging, and prod.
• Granular RBAC at both UI and API levels.
• Secret and key management in vaults or environment variables.

Finally, build security into your release cycle:

• Include authentication and authorization checks in every code review. 
• Schedule regular vulnerability scans. 
• Keep immutable audit logs of sensitive actions and watch them for anomalies. 
• Update dependencies and platform versions and review any new security-related features.

For more on securing internal development, see our guide on citizen developer governance.

Lovable’s post-mortem and roadmap

Lovable hasn’t published a full, public post-mortem for CVE-2025-48757. The closest equivalent was the introduction of its security scanner, released shortly after Matt Palmer’s initial disclosure. However, the tool’s limitations left many developers questioning whether it addressed the core problem.

Choose a secure platform with flexibility and transparency

Superblocks provides a secure platform for your apps with centralized governance and security, whether you build with code, a visual editor, or AI. This unifies controls to democratize development responsibly, reducing shadow AI risk and removing engineering bottlenecks without adding new vulnerabilities

‍

Our extensive set of features makes this possible:

• Central governance: Centrally managed RBAC, SSO, granular permissions, and audit logs. On-premise agent support keeps sensitive data in your environment. Integration with secrets managers eliminates risks from hard-coded credentials.
• AI app generation with guardrails: Clark enforces your security standards and best practices in every app it generates. Teams can customize prompts to align with internal development practices and sanitize them to remove sensitive or risky instructions.
• Flexible development modalities: Build your internal tooling with code, a full WYSIWYG visual editor, or AI, all within the same governed environment. Security controls apply regardless of the build method.
• Extensive integrations: Connect securely to APIs and databases (REST, gRPC, GraphQL, OpenAPI) and integrate with Git-based CI/CD for PR reviews and approval workflows before apps go live.

Ready to build secure, governed internal tooling? Book a free demo with one of our product experts.

Frequently asked questions

What caused the critical vulnerability in Lovable?

The critical vulnerability in Lovable was caused by a row-level security (RLS) misconfiguration. Unauthenticated visitors could query sensitive tables directly using a public API key and retrieve data without any server-side checks.

Was this a single bug or multiple flaws?

This was a single flaw with multiple impact points. The same RLS misconfiguration appeared in hundreds of endpoints across different apps.

Who discovered the issue?

Matt Palmer discovered the vulnerability. He found it while testing a Lovable-built app and confirmed the same flaw in many other projects.

How was it disclosed?

The issue was disclosed privately to Lovable on March 21, 2025. After two months without public acknowledgment or a full fix, Matt Palmer published his statement and the CVE entry on May 29, 2025.

Was user data exposed?

Yes, user data was exposed. Palmer’s tests retrieved emails, phone numbers, payment details, API keys, and other personally identifiable information (PII) from vulnerable endpoints across at least 170 Lovable-built applications.

How did Lovable fix the problem?

Lovable introduced a “security scanner” tool to flag missing RLS policies. However, it only checked for the existence of a policy, not whether it effectively blocked unauthorized access.

What does RLS misconfiguration mean?

An RLS misconfiguration means the database’s row-level security rules are missing, incomplete, or incorrectly applied. These rules determine which rows of data a given user can see or modify. In a secure setup, RLS ensures that a user querying a table only gets back the rows they are authorized to access. 

‍

When RLS is misconfigured, the database may return more rows than intended, or even the entire table.

What should other SaaS teams learn from this?

Other SaaS teams should learn that platform defaults are part of their own threat surface. When your defaults leave gaps, every customer inherits the vulnerability, and the impact multiplies across all apps built on your platform. Customers shouldn’t need to be security experts to deploy safe, production-ready apps on your platform.

Are low-code and AI-assisted platforms more vulnerable to security issues like this?

Yes, because much of the code and configuration is generated automatically. Insecure defaults or missing validations can be replicated across every app built on the platform. For strategies to reduce these risks, see our low-code security guide.