The public Supabase anon key was not itself the secret. In Lovable's client-driven architecture, browser code can call Supabase directly and Row Level Security is expected to decide which rows each caller may read or change. Palmer reports that 303 endpoints across 170 of 1,645 analyzed projects had inadequate RLS settings, so modifying the browser-visible…
Inspect the ClaimsCase · DiggingBeagle record
A scan of 1,645 Lovable projects found 170 with inadequate database RLS
Matt Palmer reported 303 inadequately protected Supabase endpoints across 170 of 1,645 analyzed Lovable projects. The technical boundary was Row Level Security behind direct browser-to-database access; attribution of responsibility to the platform remains disputed.
Scope
Palmer's research covered publicly discoverable Lovable projects, primarily from Lovable Launched, plus a later Linkable follow-up. The broader scan inspected homepages and altered observed Supabase requests rather than exhaustively testing every application surface. It is not a census of all Lovable applications and does not establish a victim or exploitation count.
At a glance
The useful AI-security lesson is not that a public Supabase anon key is inherently a secret leak. It is that AI app builders can produce a working interface while the effective authorization policy lives elsewhere. Secure-by-default generation, backend policy tests and explicit ownership rules matter more than whether the UI hides an action.
Read the implicationsThe 1,645-project sample was not a census of all Lovable applications and was drawn from discoverable public projects. The disclosure does not establish how many projects were exploited by malicious third parties. The CVE's platform-level responsibility remains disputed. The March 2025 prevalence should not be treated as a current 2026 prevalence estimate…
Limits and uncertaintyFull account
The public Supabase anon key was not itself the secret. In Lovable's client-driven architecture, browser code can call Supabase directly and Row Level Security is expected to decide which rows each caller may read or change. Palmer reports that 303 endpoints across 170 of 1,645 analyzed projects had inadequate RLS settings, so modifying the browser-visible request could expose data outside the application's intended interface.
The follow-up Linkable test makes the distinction between frontend behavior and backend authority concrete. Palmer reports that removing the authorization header changed the request context and allowed an unauthenticated insert with payment_status set to paid. The CVE record later described unauthenticated read or write access through insufficient RLS but marked the issue disputed because Lovable says individual customers are responsible for protecting their application data. That dispute affects attribution, not the basic security question: a generated interface is not an authorization boundary if the backend accepts a request the interface would never present.
Mechanism and trust boundary
- 01
A generated frontend calls Supabase directly
The browser contains the public anon credential and makes direct REST requests to the application's Supabase backend.
Boundary: browser / database API
- 02
The attacker bypasses the generated interface
A user modifies an observed request, changes selection or request context, or targets another exposed table rather than following the controls presented by the UI.
Boundary: frontend intent / backend request
- 03
Insufficient RLS accepts the request
A missing or overly broad row-level policy permits data access or modification that the application intended to restrict.
Boundary: database policy / protected rows
Timeline
- Mar 20, 2025discovery
Initial Linkable issue discovered
Palmer reports discovering unrestricted access to the Linkable users table.
- Mar 20, 2025occurrence
Occurrence began
- Mar 21, 2025Event type unspecified
Broader Lovable scan completed
The scan reported 303 inadequately protected endpoints across 170 of 1,645 analyzed projects.
- Mar 21, 2025notification
Vendor notified
- May 29, 2025disclosure
Palmer published the coordinated disclosure
The statement and CVE write-up documented the RLS mechanism and follow-up Linkable write test.
Claims & evidence
CLM-LOVABLE-170Palmer reports that a March 21, 2025 scan identified 303 endpoints across 170 of 1,645 analyzed Lovable projects with inadequate Row Level Security settings.supported
Basis: reported finding
- supportsStatement on CVE-2025-48757primary disclosure
Automated Scan Findings, reporting 303 endpoints across 170 projects, approximately 10.3% of 1,645 analyzed
CLM-LOVABLE-WRITEIn a May 2025 Linkable follow-up, Palmer reports that an unauthenticated request could insert a record with payment_status set to paid, demonstrating an integrity impact in addition to read exposure.supported
Basis: reported finding
- supportsStatement on CVE-2025-48757primary disclosure
Data Modification Vulnerability section and Appendix A2
CLM-LOVABLE-DISPUTEDThe public CVE record describes insufficient RLS allowing unauthenticated reads or writes but records the issue as disputed because Lovable says customers are responsible for protecting their application data.supported
Basis: direct observation
- supportsCVE Record: CVE-2025-48757government record
CVE description, disputed tag and supplier note
- contextStatement on CVE-2025-48757primary disclosure
Disclosure statement attributing recurring insecure RLS configurations to Lovable-generated projects
CLM-LOVABLE-ESCAPE-CONTEXTA later Escape study of more than 5,600 publicly available vibe-coded applications across several platforms reported more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of exposed PII. Lovable accounted for roughly 4,000+ applications in Escape's initial platform coverage, but Escape explicitly warns that its one-time dataset has sampling, temporal and platform-imbalance bias. The study therefore corroborates the broader class of exposed backend and authorization failures without providing a directly comparable Lovable-specific prevalence estimate.supported
Basis: reported finding
- supportsMethodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platformsprimary disclosure
Methodology sections 'Data Gathering Strategy' and 'Observations and Biases': more than 5,600 public applications analyzed; initial platform coverage included Lovable at roughly 4,000+ applications; more than 2,000 vulnerabilities, 400+ exposed secrets and 175 PII exposures reported; sampling, temporal and platform-imbalance limitations are explicitly stated.
Implications
The useful AI-security lesson is not that a public Supabase anon key is inherently a secret leak. It is that AI app builders can produce a working interface while the effective authorization policy lives elsewhere. Secure-by-default generation, backend policy tests and explicit ownership rules matter more than whether the UI hides an action.
Controls and mitigations
- Treat Row Level Security as server-side authorization and test anonymous, authenticated and cross-user requests directly against each sensitive table.
- Verify the semantics of RLS policies rather than checking only that a policy exists; ownership and role predicates must match the application's actual business rules.
- Keep service-level credentials and sensitive server operations outside browser-accessible data paths, while recognizing that server-side placement does not replace authorization checks.
Unknowns and contradictions
- The 1,645-project sample was not a census of all Lovable applications and was drawn from discoverable public projects.
- The disclosure does not establish how many projects were exploited by malicious third parties.
- The CVE's platform-level responsibility remains disputed.
- The March 2025 prevalence should not be treated as a current 2026 prevalence estimate after later platform and user changes.
Sources and citation
Material revision history
- Oct 7, 2026 · Canonical change recorded · new in release · revision 94