A critical vulnerability unearthed in Lovable’s implementation of application security, specifically its handling of Row Level Security (RLS) policies, is exposing sensitive user data and enabling attackers to inject malicious code across multiple client applications.
The issue, now assigned a public CVE, risks API keys, personally identifiable information (PII), and payment statuses for countless end users.
Vulnerability Mechanics and Scope
Initial Discovery and Attack Workflow
On March 20th, 2025, security researchers uncovered that applications developed on the Lovable platform frequently lack secure RLS configurations, resulting in unauthorized data exposure.

Lovable, a low-code platform for building client-driven applications, often relies on external backend services like Supabase for data storage and authentication.
This setup, while flexible, shifts the security burden onto application implementors and frequently results in inconsistencies between intended client-side restrictions and backend enforcement.
Investigations began on Linkable, a Lovable-built website for generating sites from LinkedIn profiles. Researchers noticed that simply altering client-side API queries could expose full tables of user data including emails and payment statuses without requiring authentication.
By intercepting and modifying network requests to use a wildcard select (SELECT *), attackers could retrieve everything from developer API keys to customer payment records, effectively bypassing all frontend access controls.
Automated Scan Reveals Widespread Exposure
To assess the scale, the researchers built an automated script to scan each site listed on Lovable’s public showcase, “Lovable Launched,” for similar vulnerabilities.
The script visited each project’s homepage, filtered for external network requests (particularly to Supabase), and tried to modify these requests to select all data from exposed endpoints. The results were chilling:
python# Example pseudocode for script logic
for site in launched_lovable_sites:
page = visit(site.homepage)
requests = capture_network_requests(page)
for req in requests:
if req.url.contains('supabase'):
modified = modify_request(req, select='*')
if modified.response.returns_all_rows:
log_vulnerability(site, req.endpoint)
The scan uncovered 303 vulnerable endpoints across 170 projects (around 10.3% of 1,645 analyzed), indicating a systemic issue. Sensitive endpoints exposed included /users, /transactions, and even /functions/v1/get-google-maps-token, leaking not only user data but also tokens and keys used by the apps themselves.
Malicious Data Injection and Write Bypass
While read access is a serious risk, the vulnerability went further. On May 24th, 2025, researchers conducted a follow-up test on the (by now paid) Linkable site.
Although the endpoint had been moved and RLS appeared active for authenticated requests, merely stripping the authorization header from the request transformed the security context, allowing unrestricted read and crucially write access.
By sending a crafted POST request, the researchers successfully inserted a new user record and manipulated payment status, bypassing the site’s Stripe integration:
json{
"id": "65cfe5b1-8d1b-4524-82f4-e1b4431199bc",
"email": "hello@mattpalmer.io",
"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
}
This demonstrated that unauthorized users could not only read but also write any data to the database, including altering payment statuses to circumvent business logic and even inject malicious records.
Industry Implications and Recommendations
Systemic Risks in Low-Code and AI-Driven Development
Lovable’s architecture exemplifies the pitfalls of “vibe coding” in modern AI-assisted development where ease of use and rapid iteration can lead to critical security oversights.
The platform’s reliance on developers to manually configure security policies, paired with insufficient guardrails, creates vulnerabilities at scale. This is especially dangerous when users lack deep security expertise but are empowered to launch production-grade apps.
Responsible Disclosure and Patch Lag
Researchers initially notified Lovable on March 21st, 2025, and followed up with coordinated disclosures to both Lovable and Supabase.
Despite confirmation of receipt, Lovable’s remediation efforts were lacking: a “security scanner” introduced in April only checked for the presence, not correctness, of RLS policies, leaving the core issues unresolved. The vulnerability was ultimately published as a CVE after a 45-day disclosure window expired without meaningful action.
Technical Mitigations and Best Practices
To prevent such issues, organizations should:
- Enforce secure-by-default configurations for all database access, especially when using platforms like Supabase.
- Implement robust RLS policies that align application logic with backend security.
- Regularly audit network requests for sensitive endpoints and review security scanner outputs critically.
- Adopt defense-in-depth practices, such as validating authorization server-side and limiting direct client-to-database operations.
sql-- Example: Secure RLS policy for Supabase
CREATE POLICY user_select ON users
USING (auth.uid() = id);
The Lovable vulnerability is a stark reminder that democratizing app development must not come at the expense of security. Tools that simplify coding for the masses must also simplify secure coding.
Until then, users and organizations remain at risk not only from data exposure but from malicious code injection and business logic bypasses. Developers, platform providers, and security teams must collaborate to close these gaps before attackers capitalize on them at scale.





