On March 20th, 2025, we discovered a critical vulnerability in Lovable's implementation of Row Level Security (RLS) policies. Applications developed using its platform often lack secure RLS configurations, allowing unauthorized actors to access sensitive user data and inject malicious data.
Lovable applications, being primarily client-driven, rely on external services for backend operations like authentication and data storage. This architecture shifts the security burden to the implementor of the application. However, misaligned RLS policies between the client-side logic and backend enforcement frequently result in vulnerabilities, where attackers can bypass frontend controls to directly access or modify data.
Lovable later introduced a "security scanner," but it merely checks for the existence of any RLS policy, not its correctness or alignment with application logic. This provides a false sense of security, failing to detect the misconfigurations that expose data.
This document details the vulnerability, its discovery, and subsequent findings, for which a formal CVE disclosure has been published here.
Initial Discovery & Scope Assessment
The vulnerability was first identified on March 20th, 2025, while examining Linkable, a Lovable-built site for generating websites from LinkedIn profiles.
An inspection of network requests revealed that modifying a query granted access to all data in the project's "users" table. After we highlighted this on a reply reply on Lovable's Twitter account, Lovable denied the issue, then deleted their tweets and the site. Linkable was later reinstated with a $2 fee.
The core issue was not an exposed public API key as we initially thought (Supabase provides public anon keys by design) but the absent RLS configuration. This allowed unrestricted data retrieval from the exposed table (sample in Appendix A1).
To determine if this was an isolated incident, we investigated other Lovable-created sites, starting with those on Lovable Launched—a showcase presumably featuring polished projects. Access to the list of these sites was gained by manipulating an endpoint on the Launched site itself, which also lacked RLS.
We then developed a script to visit the homepage of each Launched site, capture all external network requests, and filter for those made to external sources.
For each identified request, the script attempted to modify the request to select all data from the associated endpoint—an operation equivalent to SELECT *, which RLS would typically prevent. Here is a mermaid diagram of this process:
Automated Scan Findings
The scan, completed on March 21st, identified 303 endpoints across 170 projects (approximately 10.3% of the 1645 analyzed) with inadequate RLS settings. This indicates widespread RLS misapplication, potentially highlighting systemic issues in Lovable's platform that may predispose projects to insecure data storage.
The following anonymized public endpoints from the scan illustrate the types of sensitive data exposed:
<https://xxx.supabase.co/functions/v1/get-google-maps-token>
<https://xxx.supabase.co/rest/v1/rpc/get_gemini_api_key>
<https://xxx.supabase.co/functions/v1/refresh-ebay-token>
<https://xxx.supabase.co/rest/v1/users>
<https://xxx.supabase.co/rest/v1/transactions>
<https://xxx.supabase.co/rest/v1/subscriptions>
This script only analyzed homepages and did not attempt to access login-protected areas or perform deeper site scraping. Authenticated sessions on these vulnerable sites could expose even more sensitive data.
Users interacting with Lovable-built sites should exercise extreme caution in the data they submit.
Data Modification Vulnerability
A follow-up assessment of the Linkable site on May 24th, 2025, (a paid site actively maintained by a Lovable employee) was conducted to verify the current vulnerability state.
While the endpoint was relocated to /rest/v1/website_generation and RLS appeared active for authenticated requests, removing the authorization header bypassed all access controls by changing the security context of the request from an authenticated user to an unauthenticated one. This allowed unrestricted read access and, critically, unauthorized write operations.
We successfully inserted a new record (details in Appendix A2) by issuing a POST request with a crafted payload, including setting "payment_status": "paid", thereby bypassing the Stripe integration. We have attached anonymized user data extracted from the Linkable site in Appendix A3.
This demonstrates that critical security issues, extending to data manipulation and injection, persist even on company-maintained sites despite prior notification and the "Security Scan" feature. This indicates systemic RLS implementation flaws within the Lovable ecosystem. We have notified the owners of these findings.
Timeline of Disclosure
We notified Lovable of the vulnerability on March 21st, 2025. They confirmed receipt, but never responded to our email. The initial email can be seen in Appendix B1. We followed up with a formal disclosure on April 14th, 2025, referencing the public exploit, and initiated a 45-day disclosure window. The follow-up email can be seen in Appendix B2.
- March 20, 2025: Initial vulnerability discovered on linkable.site.
- March 21, 2025: Broader RLS misconfiguration issue identified across multiple Lovable projects. Lovable emailed regarding scope and severity.
- March 24, 2025: Lovable confirmed receipt of the email.
- April 14, 2025: A Palantir engineer independently discovered and publicly tweeted about the same vulnerability, demonstrating active exploitation (e.g., extracting personal debt amounts, home addresses, API keys).
- April 14, 2025: We re-notified Lovable, referencing the public exploit, and initiated a 45-day disclosure window.
- April 24, 2025: Lovable released "Lovable 2.0" with a "security scan" feature. This did not address the underlying RLS architectural flaw.
- May 29, 2025: With no meaningful remediation or user notification from Lovable, we published our CVE.
Details of our communications are in Appendix B.
The need for secure-by-default vibe coding
We are publishing this CVE to highlight the critical importance of secure-by-default configurations and best practices in AI-assisted development platforms, especially when they handle sensitive user data. We believe "vibe coding" and similar paradigms should empower users by inherently promoting security, not facilitating vulnerabilities or shifting the burden of security entirety to users (or worse, blaming them for lack of security).
Recent advancements have democratized not only coding but also access to sophisticated developer tooling. Coding agents can now implement services like databases and user authorization—tasks that once required days or weeks for professional developers.
However, we observe that without robust default settings or guardrails, or even architectural patterns that allow better defense in depth like having a client/server separation, these solutions can generate security vulnerabilities at scale. Consequently, users unfamiliar with web development best practices inadvertently "vibe code" applications that endanger both themselves and their users.
We urge Lovable to take immediate action to notify users and implement secure defaults to prevent systemic data exposure. Technical details have been redacted per responsible disclosure but have been shared with Lovable.
Appendix
A. Sample Data Accessed from Vulnerable Endpoints
A1 Linkable Users Table Sample
| id | |
|---|---|
| 625ff87e-0c0d-46af-9d2e-a618d648e035 | a***@***ble.dev |
| ee83085c-0f51-4033-bf9c-f42eaec696ea | u***@***hoo.com |
| c6671c86-85a0-4e32-a567-8011ef616565 | m***@***aas.io |
| bea7783d-f7a0-4545-9d81-de8f58ac1f92 | t***@***ail.com |
A2 Linkable Data Injection
{
"id": "65cfe5b1-8d1b-4524-82f4-e1b4431199bc",
"email": "[email protected]",
"linkedin_url": "https://www.linkedin.com/in/matt-palmer/",
"generation_id": "00b580fe-83a4-44fa-bb1e-c2f1d65999f9",
"payment_status": "paid",
"website_url": "https://mattpalmer.io",
"created_at": "2025-05-25T10:03:33.87533+00:00",
"updated_at": "2025-05-25T10:03:33.87533+00:00",
"created_by": null
}
A3 Linkable Users Table Sample
[
{
"id": "65cfe5b1-8d1b-4524-82f4-e1b4431165bc",
"email": "[email protected]",
"linkedin_url": "https://www.linkedin.com/in/user-profile-1/",
"generation_id": "00b580fe-83a4-44fa-bb1e-c2f1d65006f9",
"payment_status": "pending",
"website_url": null,
"created_at": "2025-04-01T10:03:33.87533+00:00",
"updated_at": "2025-04-01T10:03:33.87533+00:00",
"created_by": null
},
{
"id": "6420adfa-0952-4d19-acd4-1dcccb139817",
"email": "[email protected]",
"linkedin_url": "https://www.linkedin.com/in/user-profile-1/",
"generation_id": "39dd80de-0614-4cef-ad2f-a13489d20e91",
"payment_status": "pending",
"website_url": null,
"created_at": "2025-04-01T10:03:42.112132+00:00",
"updated_at": "2025-04-01T10:03:42.112132+00:00",
"created_by": null
},
{
"id": "65cfe5b1-8d1b-4524-82f4-e1b4431199bc",
"email": "[email protected]",
"linkedin_url": "https://www.linkedin.com/in/matt-palmer/",
"generation_id": "00b580fe-83a4-44fa-bb1e-c2f1d65999f9",
"payment_status": "paid",
"website_url": "https://mattpalmer.io",
"created_at": "2025-05-25T10:03:33.87533+00:00",
"updated_at": "2025-05-25T10:03:33.87533+00:00",
"created_by": null
}
]
B. Communications / Responsible Disclosure
B1 Initial email sent to Lovable team
Lovable Team,
I hope this message finds you well. My name is Matt, and I work in Developer Relations at Replit. I'm reaching out in good faith to share a security concern that my colleague Kody Low and I have identified.
On March 20, 2025, at 1:27 PM, I discovered a vulnerability in a Lovable marketing site (<https://linkable.site/>) that allowed me to extract the emails of approximately 500 users who had engaged with the app.
I initially reported this on X (<https://x.com/mattppal/status/1902819250395549811>), but received feedback that there was no issue.
Kody dug a bit deeper and found that several featured Lovable projects had auth endpoints or profiles endpoints that returned personally identifiable information (PII), including usernames, emails, and other identifying user data.
For example, [ REDACTED ] profiles table is publicly accessible.
Upon further investigation with my colleague Kody, we examined <https://launched.lovable.dev> and were able to access information from every project listed on the site from one of Lovable's own Supabase projects.
By recursing through these projects, we identified multiple instances with publicly accessible database endpoints on their homepages.
This exposed information includes subscriptions, names, phone numbers, API keys, payment details, Google Maps tokens, and various other PII.
303 Supabase endpoints were found across 170 websites, but this was only from examining the homepages.
Our hypothesis is that many users do not fully understand Row Level Security (RLS) settings on Supabase, and Lovable's implementation is creating these insecure calls when users connect their Supabase without properly configuring auth and RLS.
This combination leads to widespread vulnerabilities in the resulting applications. We believe that many developers using Lovable are unaware that they're exposing sensitive information through these database endpoints.
I would be happy to provide more technical details or assist with verification of this vulnerability. We are approaching this disclosure responsibly and have not shared these findings publicly beyond my initial tweet.
Could you please acknowledge receipt of this email and provide a timeline for when you expect to investigate this issue?
Thank you for your attention to this matter. We're reaching out because we care about the security of the AI builder community and believe that addressing this vulnerability will ultimately strengthen your platform.
Best regards,
Matt
B2 Responsible Disclosure Sent to Supabase & Lovable Teams
# Coordinated Vulnerability Disclosure: Default missing / insufficient Supabase Row Level Security policies
Dear Lovable team,
Following [CERT's guide on coordinated disclosure](https://certcc.github.io/CERT-Guide-to-CVD/), we intend to publicly disclose the vulnerability discussed here after 45 days. This is a follow-up on an email that Matt Palmer sent on March 21, 2025.
Affected products: https://lovable.dev
## What is the vulnerability?
[CWE-732: Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html)
[CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html)
[CWE-359: Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html)
Projects generated using code generation tools like Lovable using [Supabase Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) may have lax / insufficiently set security policies by default (unless the user requests such functionality to be enabled) that allow unauthenticated attackers to read arbitrary database tables / rows that may include API tokens (e.g. Gemini API keys) of the developer of the project and Personally Identifiable Information (PII, e.g. usernames, emails, phone numbers) of the users of the project. No user interaction is needed to successfully perform the attack: The attacker can take any unauthenticated POST request sent directly to Supabase from the client-side application, and modify the query to a `select=*` against any exposed database table.
**CVSS v3.1 Vector**
[AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/E:F/RL:X/RC:R](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/E:F/RL:X/RC:R&version=3.1)
### Proof of Concept
[ REDACTED ]
## How does an attacker exploit this vulnerability?
By inspecting the network traffic of a vulnerable site, especially on a login / profile page, filtering for traffic for Supabase, and replacing any select query payloads with `select=*`, the attacker can get read access to the full rows of full tables that the page used instead of only the rows intended to be used by the project's developer. The attacker can also copy paste any request hitting against supabase, ask to hit against any tables (users, portfolios, etc.) and any of those tables with incorrect RLS are vulnerable to this.
The following script is a proof-of-concept to check whether a single site is vulnerable:
[ REDACTED ]
## What does an attacker gain by exploiting this vulnerability? (i.e. what is the impact?)
Access to API keys (in multiple cases) owned by the project's developer, that could in turn cause escalation of privileges in other systems or unintended spend. Also, over-the-network exfiltration of PII, any data in tables the app accesses where the table does not have RLS policies set.
## How was the vulnerability discovered?
We first discovered a vulnerability in a Lovable marketing site, https://linkable.site, where the client could issue manipulated queries directly against Supabase only using the `anon_key` sent from the client. As a proof-of-concept, the query was changed to a `select=*` to return the complete user table including emails of over 500 people who had used the site.
Later, we saw the vulnerability on another Lovable site and suspected a wide-spread issue. We wrote a simple script that checked for similar vulnerabilities on the sites listed on https://[l](http://lovable.dev)aunched.lovable.dev and found more instances of projects without RLS set at all or incorrectly, and were leaking user data including phone numbers, emails, developer API Keys, and more as detailed above.
## Is this vulnerability publicly known?
Probably (see section below). There was a prior public disclosure of a missing RLS policy set for https://linkable.site but this report of the wider and repeated pattern of these vulnerabilities in Lovable-created sites is novel and hasn't been shared with anyone except for Lovable and Supabase.
## Is there evidence that this vulnerability is being actively exploited?
Yes: https://x.com/danialasaria/status/1911862269996118272
## Do you plan to publicly disclose this vulnerability yourself?
Yes, on May 28, 2025
## Contact Information
Name: [REDACTED]
Organization: Replit
End of Appendix