Lovable Security: The CVE, the Two Scans, and the Checks We Ran on Our Own Kits

What is on the public record?

One CVE and one researcher's scan behind it. The CVE-2025-48757 record, read from MITRE on 26 September 2026, was published 30 May 2025: “An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites.” Score: 9.3 (Critical), CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N. Status: Disputed: the vendor contests the record on the grounds that customers are responsible for protecting their application data.

The numbers come from Matt Palmer's statement on the CVE (29 May 2025): “The scan, completed on March 21st, identified 303 endpoints across 170 projects (approximately 10.3% of the 1645 analyzed)”, exposing “subscriptions, names, phone numbers, API keys, payment details, Google Maps tokens, and various other PII”. The mechanism in his words: generated apps “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”. His criticism of the first fix is the sentence this page is built around: the scanner “merely checks for the existence of any RLS policy, not its correctness or alignment with application logic”.

A second issue is reported for April 2026: a disclosure on X, written up by Bastion on 20 April 2026, that a free account could read another user's source, database credentials and chat history for projects created before November 2025. Lovable's changelog, read the same day, carries no entry for it, so this page reports the disclosure as a disclosure and attaches no numbers to it.

What do Lovable's own security tools do?

Two scans, per the security documentation on 26 September 2026. The Quick scan “completes a fixed set of checks in seconds and runs automatically every time you publish”. The Deep scan “reviews all your application code for issues specific to your app's logic, permissions, and data”, includes everything in the Quick scan, and is triggered by hand from the Security view. Findings are grouped by area and labelled Critical, Warning or Info; since 15 September 2026 each opens with a plain-language “What could happen” per the changelog.

The last row is the whole page. Both scans, by the docs' own description, look for missing or fully open rules. Neither runs a query as the wrong user. The docs put the remainder on you: “You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions.”

What did a Deep scan find on our test project?

Nothing at any severity, in three minutes, for free. The project is the SaaS built earlier on 26 September 2026 for the prompt examples page, an unpublished app with sign-up, workspaces, three roles and invite links. The run taught two things before it produced a verdict.

First, asking the chat does not run the Deep scan. We typed “Run a deep security scan of this app and list every finding by severity with the affected table or file. Do not change any code.” and the chat ran the checks it can start itself, reported “Critical: none. Warning: none. Info: none.”, and then said: “The checks I can start myself don't read the app's own code in depth. No in-depth code review has run for this project yet, so I can't show those results or call the project fully clean. You can start one from the Security tab.” It also offered two observations it labelled as not scanner findings: invite link used by someone already in the workspace: if a person joins the workspace some other way after their invite was created, then opens the old link, their role is reset to whatever the invite says, and that anyone holding an invite link can see the workspace name, the invited email and the sender.

Second, the Security view (More, then Security) is where both scans live. Before the run it read “Free · Not scanned yet” for the Deep scan and “Free · Last scan 6 hours ago” for the Quick scan, with the estimate “Takes about 4 minutes”. Started at 18:12, finished by 18:15; the card afterwards reads “Last scan took 3 min”.

The dependency row is the one to read twice. The chat wrote “Outside code packages: no known vulnerable packages were found. That check last ran earlier today and is a little out of date, but nothing new was reported.” The Security view, four minutes later, listed “53 packages • 2 known issues”, both on @tanstack/react-start 1.168.32, rated 2 High. The chat had flagged its own check as a little out of date. Neither statement is false; they are two checks at two times, and a clean verdict belongs to the check that produced it.

Cost of the run: both scans are labelled Free in the Security view; the chat message that asked for one cost 1.3 credits (Workspace Hub usage 11.5 to 12.8 on the billing page). What the clean verdict does not say: that a member cannot read another workspace's rows. The scan confirms the four tables have access rules turned on. The next section is the query that would prove the rules deny.

What does a policy that denies look like, and how do you prove it?

The four build kits on this site ship a schema and a verification file each. The counts below are read from the kit files at build time; the verification files run queries as a member and as an admin and expect denials where the policy should deny. That is the check neither scan performs, and it is free.

The three lines that carry the rule in every prompt on this site that touches user data, and the check to paste into Lovable after any of them:

## Safe-Guard Instructions
- Enforce roles in the database with row-level security as well as in the UI; hiding a button is not access control
- Never accept a role or workspace id from the client on writes
- Do not weaken a security policy to make a query work; if the query is denied, the query is wrong

## Verification (paste after the build)
Run two queries and paste both results: as the owner, select from [table] (expects rows); as a second test user, select from [table] (expects zero rows). Then confirm in pg_tables that rowsecurity is true for every table you created.

The Lovable and Supabase guide has the three failure shapes and the kit verification tables; the SaaS starter kit prints the files.

What was our own security failure?

Every paid Pro prompt shipped in the JavaScript bundle to every visitor; the lock was a picture of a lock. It survived for months because nothing tested for it. Fixed 2026-09-11 in 30803ce. The lesson we wrote down: A client component that imports paid data ships it. Mark the module server-only and prove it with a script against the built output. It is the same lesson as the CVE at a smaller scale: a rule the builder is told is not a check the build runs, and only the second one catches the plausible-looking mistake. The vibe coding tips page has the other eleven.

What we did not publish

• Third-party counts of exposed users and databases for 2026 incidents. We could not trace them to a primary source today, so they are absent.
• A scan of other people's Lovable apps. The researcher did that with disclosure; we did not.
• A claim that the kits are secure. They are proven against their own verification queries on the policies they ship; an app built on them adds tables the kits never saw.

Sources

All read on 26 September 2026. Record and scan figures in src/data/lovableSecurity.ts; the Deep scan run in src/data/lovableSecurityRun.ts.

• CVE record: CVE-2025-48757 (MITRE)
• Matt Palmer: Statement on CVE-2025-48757 (29 May 2025)
• Matt Palmer: CVE-2025-48757 (29 May 2025)
• Lovable docs: Security overview
• Lovable docs: Changelog
• Bastion: Lovable April 2026 data breach (20 April 2026)