Overview
A vulnerability exists in deployed Lovable-generated projects due to default insufficient Row Level Security (RLS) policies on client-controlled direct database requests. You can learn more about RLS in Postgres projects here.
This can result in Lovable projects being deployed with RLS policies that don't match the business logic, potentially exposing sensitive data (including Personally Identifiable Information—PII—and credentials) to unauthenticated remote attackers via direct client access to database endpoints despite using the non-sensitive and unprivileged anon key.
Furthermore, attackers may issue unauthorized writes or injections of malicious data to some of these projects with minimal additional effort.
CVE Information
- CVE ID: CVE-2025-48757
- Published: May 29th, 2025
CVSS Score
CVSS v3.1:
- AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N/E:F/RL:W/RC:R
- Base Score: 8.26
- Temporal Score: 7.58
Affected Products
- Product: Lovable
- Vendor: Lovable (https://lovable.dev/)
- Vulnerable Versions: All versions
- Fixed Versions: None
- Components: Public endpoints of generated code
Vulnerability Details
Description
The vulnerability is an Incorrect Authorization issue stemming from missing or insufficient Row Level Security (RLS) policies on databases used by Lovable projects. This affects any Lovable project that uses a database, created on or before April 15th, 2025, but may also affect projects created after that date.
The root cause lies in the failure to enforce or maintain secure default RLS configurations for user projects.
This can lead to projects being deployed with RLS that don't match security requirements for certain tables. Exploitation requires the target Lovable project to be using an external database as its backend, with specific tables lacking appropriate RLS policies to restrict data access.
Attackers can leverage this by sending crafted HTTP requests to public Postgres endpoints associated with vulnerable Lovable projects. These requests can be modified to bypass intended data access restrictions: for example, by attempting to select all records from a table, thereby exposing sensitive information. The requests may also be modified to insert, update, or delete data, potentially allowing attackers to inject malicious content or manipulate existing records.
Exploitation
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
An attacker first identifies public endpoints associated with a Lovable project (e.g., by inspecting network traffic of the application). Lovable creates frontend applications that make direct REST API calls against the database from the client, using a public and unprivileged anon
key, while relying exclusively on RLS to ensure the privacy and integrity of the contents of the database.
If an application interacts with a table that has missing or insufficient RLS policies, the attacker can modify the REST request (e.g., query parameters or request body) to query for data they should not have access to, such as all rows in a table (e.g. ?select=*
).
For security reasons, we have chosen not to provide specific examples of exploitation scripts, as this could enable malicious actors to target vulnerable sites. However, the vulnerability can be exploited through standard HTTP request manipulation techniques.
[
{
"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
}
]
Impact
- Confidentiality Impact: High
- Integrity Impact: LowHigh
- Availability Impact: None
- Scope: Unchanged
Successful exploitation of this vulnerability can lead to significant data breaches and unauthorized data modification. Attackers can gain unauthorized access to and in some cases even modify a wide range of sensitive information, including:
- Personally Identifiable Information (PII) from
users
tables (e.g., names, email addresses,). - API keys and access tokens for third-party services (e.g., Google Maps, Gemini API, eBay tokens), allowing further unauthorized actions on those platforms acting on behalf of the compromised application or its users.
- Financial data such as
transactions
andsubscriptions
details, including the ability to modify payment status.
Resolution
Patches and Updates
None available
Workarounds
Users of Lovable projects utilizing external services are strongly urged to take immediate action to mitigate this vulnerability. As an example, we provide links to Supabase, one database vendor that has good documentation on the topic:
-
Implement and Enforce Row Level Security (RLS) Policies: This is the primary mitigation. Review all database tables to ensure RLS is enabled. Lovable's Publish feature will help ensure that RLS policies are enabled in all tables and notify if they aren't (but doesn't necessarily indicate if they are sufficient). Note that RLS is enabled by default on tables created with the Table Editor in the dashboard. If you created the tables via the SQL editor or via another way, enable RLS manually:
ALTER TABLE schema_name.table_name ENABLE ROW LEVEL SECURITY;
Define granular RLS policies for all tables, particularly those containing sensitive data, adhering to the principle of least privilege: This means only allowing users access to the specific rows they are authorized to view or modify. For publicly accessible data, create explicit policies that permit public read access only to non-sensitive columns. For authenticated access, ensure policies correctly use
auth.uid()
or similar session variables to restrict data access to the logged-in user or their specific roles and permissions.Crucially, avoid overly permissive policies, such as
USING (true)
for select operations on sensitive tables without additional restrictive conditions. Example of a secure policy:CREATE POLICY "Users can view their own todos" ON todos FOR SELECT TO authenticated USING ( (SELECT auth.uid()) = user_id );
-
Audit Endpoints and Data Storage: Carefully review all data stored in external services and tables. Identify and assess any Personally Identifiable Information (PII), credentials (like API keys or tokens), financial information, or other sensitive data. Determine if this sensitive data absolutely needs to be stored. If it does, evaluate whether it can be stored more securely (e.g., encrypted secrets—though RLS remains the primary defense against this specific CVE). Remove any unnecessary sensitive data from the database. You can rely on server-side technologies (like Supabase Edge Functions) to limit the client-side exposure of data.
-
Secure API Keys and Credentials: Avoid storing API keys, access tokens, or other credentials directly in database tables if they are intended to be client-accessible: If service-to-service keys are necessary, consider using secure server-side secrets storage with environment variables for storing secrets (as an example, Supabase Secrets, which are compatible with Edge Functions). Ensure these functions incorporate appropriate authorization checks if they return sensitive information. This follows the principle of defense-in-depth.
-
Regularly Review RLS Configuration: Periodically review RLS policies and data schemas, even if the security scanner doesn't show any issues. This ensures they remain effective and align with the application's security requirements, especially following updates to the application or changes in data handling practices.
-
Separate tables with sensitive and non-sensitive data: Since PostgreSQL Row-Level Security can only operate on full rows, if a row has sensitive (e.g. payment information) and non-sensitive (e.g. username) information, even with RLS enabled, attackers will still be able to access sensitive information if direct client-side access to the database is enabled. For cases like these, separate tables should be used, with independent RLS policies to prevent access to the sensitive data by any users. Alternatively, an architectural change like relying on server-side technologies could make the implementation of custom access control easier. Alternatively, PostgreSQL privileges can also be used as an advanced feature to implement column-level security.
You can find comprehensive information on how to configure RLS at: https://supabase.com/docs/guides/database/postgres/row-level-security
Detection
Methods for detecting this vulnerability differ for project owners and external parties.
For Project Owners/Administrators
Project owners and administrators should begin by reviewing their RLS policies in their database dashboard. For each table, particularly those storing sensitive information (e.g., users
, transactions
, API keys), verify that RLS is enabled. Any table created through the Supabase Dashboard will have RLS enabled by default, but tables created via SQL editor will need manual enablement.
Examine the defined policies to ensure they are not overly permissive—for example, a simple public
read access without conditions on a sensitive table is a red flag. Policies should restrict access based on user roles or ownership (e.g., using conditions like auth.uid() = user_id
if the tables don't hold any sensitive information), or restrict client-side access altogether if there are columns with sensitive information.
Next, it's crucial to inspect table grants: Check the privileges granted on tables to ensure that the anon
and authenticated
roles do not have overly broad SELECT
, INSERT
, UPDATE
, or DELETE
permissions that could bypass RLS or are otherwise unintended.
Finally, manually test the application's API endpoints that interact with the database. This involves attempting to access data for which permission should not be granted (e.g., as an unauthenticated user, or as one user trying to access another user's private data). The dashboards of some vendors allows you to impersonate users and test queries to validate your RLS policies.
As an additional resource, you can follow Supabase's production checklist for more best practices.
Disclosure Timeline
- Discovery Date: March 20th, 2025
- Vendor Notification: March 21st, 2025
- Vendor Acknowledgement: March 24th, 2025
- Vendor Disclosure: April 15th, 2025
- Vendor Response: April 15th, 2025
- Patch Development: N/A
- Patch Release: April 24th, 2025
- Public Disclosure: May 29th, 2025
Credits
- Discovered by: Matt Palmer
- Additional Contributors: Kody Low
- Independently reported by: https://x.com/danialasaria/status/1911862269996118272
- Organization: Replit, Inc.
Contact Information
For questions regarding this disclosure:
- Security Contact: [email protected]
This disclosure follows responsible disclosure practices and coordinated vulnerability disclosure guidelines.