Lovable PromptsLovable Prompts
    Updated CVE and scans re-read 23 Oct 2026Deep scan run on my own project

    Lovable security: the CVE, the two scans, and the check that proves a policy

    Lovable gives every project two free security scans and leaves the rest to you: its docs say you are responsible for making sure your app meets the security requirements of its use case. The public record shows the gap: CVE-2025-48757, rated 9.3 critical, covers missing row-level security in generated apps, and the researcher behind it found 303 exposed endpoints across 170 of 1,645 projects. Below: the record, what each scan checks, a Deep scan I ran on my own project, and the query that proves a policy denies what it should.

    By Marco Kohns · NVD record and Lovable docs read 23 October 2026

    9.3CVSS

    CVE-2025-48757, critical per NVD, disputed by Lovable.

    10.3%of projects

    170 of 1,645 scanned on 21 March 2025 had exposed endpoints.

    Freeboth scans

    Quick runs at every publish; Deep on request, 3 to 13 minutes. Mine took 3.

    The record

    What happened with CVE-2025-48757?

    A missing or permissive row-level security policy exposed whole tables, because generated apps query the database from the browser with a public key.

    CVE-2025-48757 timeline from the researcher's statement and the NVD record
    StepDate
    Discovery20 March 2025
    Vendor notified21 March 2025
    Disclosed29 May 2025
    CVE published30 May 2025

    NVD's description, read 23 October 2026: “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. Lovable disputes the record because each customer is responsible for protecting their app's data. The researcher, Matt Palmer, explains the mechanism in his statement: generated apps call the database directly from the browser with the public anon key and rely on row-level security alone, so one missing or permissive policy exposes the table. What leaked, in his words: “subscriptions, names, phone numbers, API keys, payment details, Google Maps tokens, and various other PII”.

    A second issue was reported in April 2026: a disclosure on X, written up by Bastion on 20 April 2026, that a free account could read other users' source code, credentials and chat history for projects created before November 2025. Lovable's changelog entries for April 2026, re-read 23 October 2026, list security features but no entry for that disclosure, so I report it as a disclosure and attach no numbers to it.

    Lovable's tools

    What do Lovable's two security scans check?

    Both are free. The Quick scan runs at every publish; the Deep scan reads your app's code and runs when you start it.

    Every publish · seconds

    Quick scan

    • Database review: tables without per-record access control (row-level security), access rules that let everyone through, and leaked-password protection turned off
    • Dependency audit: known vulnerabilities in your project's npm dependencies
    • MCP server check: an MCP server your app exposes without authentication

    On request · 3 to 13 minutes

    Deep scan

    • Access control & authorization
    • Unauthenticated & abusable endpoints
    • Unsafe input & injection
    • Leaked secrets & credentials
    • Payments & billing
    • Authentication & account security
    • Exposed personal & sensitive data

    Lovable docs: Security and Security view, read 23 October 2026: both scans “are free and do not consume credits”; fixes draw on 10 free fixes per account, then credits; a security review asked in the chat is billed. Since April 2026 workspace admins can also block publishing when critical vulnerabilities are found (changelog).

    Measured

    What did a Deep scan find on my own Lovable app?

    Nothing at any severity, in 3 minutes, on 26 September 2026. Two things around it matter more than the verdict.

    Everything the scans reported on my SaaS test project, 26 September 2026
    SeverityWhereWhat it said
    CriticalDeep scan, all seven areasNone reported.
    WarningDeep scan, all seven areasNone reported.
    InfoDeep scan, all seven areasNone reported.
    High (dependency)@tanstack/react-start 1.168.322 known issues in the dependency list, which is a separate panel from the scan verdict and which the chat had reported as clean four minutes earlier.
    Lovable's chat answer to a deep security scan request on the unpublished SaaS project: results by severity all none, what was checked, what was not covered, and two observations about invite links
    Asking the chat for a deep scan: clean at every severity, and the caveat that the in-depth review starts from the Security tab. Billed 1.3 credits.
    Lovable's Security view after the Deep scan on the SaaS test project: both scans up to date, No issues found, and a dependency panel reading 53 packages, 2 known issues
    The Security view after the Deep scan: free, 3 minutes, no issues; the dependency panel beside it lists 53 packages • 2 known issues.

    Do

    Read the scans this way

    • Start the Deep scan from More › Security; it is free
    • Read the dependency panel separately from the verdict
    • Treat a clean result as true for that check at that time
    • Prove each policy with a query as the wrong user

    Avoid

    What misled

    • Asking the chat for a scan: it ran its own checks, called them clean, and cost 1.3 credits
    • The chat's “no known vulnerable packages” while the Security view listed 2 High issues on @tanstack/react-start
    • Reading No issues found as proof that the policies match the app's intent

    The proof

    How do you prove a Lovable policy denies what it should?

    A scan confirms row-level security is on. Only a query run as a user who should be denied shows what it blocks.

    Palmer's criticism of the first scanner is the reason: it checked that a policy existed, not that it was correct. A policy written as using (true) covers a table and denies nothing. Every library prompt now carries the rule and the check as two sections; paste these into any prompt that stores user data.

    The two sections, as library prompts carry them

    ## Data & Access
- Every table has row-level security, deny by default; roles live in their own user_roles table
- Never accept a role, owner or workspace id from the client on a write; derive it on the server
- Do not weaken a policy to make a query work; a denied query is the query's problem

## Done When
- As the owner, selecting from [table] returns my rows
- As a second test account, selecting from [table] returns zero rows
- Every table I created shows row-level security enabled
    Row-level security policies and verification checks in the four build kits, counted from their files
    KitTablesPoliciesChecks
    SaaS Starter4126
    Landing Page with Email Capture117
    Internal Admin Dashboard257
    Lightweight CRM3126

    30 policies and 26 verification checks across the kits; each kit's verify.sql runs as an ordinary signed-in user, never as service_role.

    Our own failure

    Did this site ever leak data it should not have?

    Yes, and the lesson is the same as the CVE's.

    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 on 2026-09-11: the module became server-only, and a script now checks the built output for every paid body on every build. A rule that is read did not catch it for months; a check that runs did on the first try.

    Kits with the checks written

    Four free build kits, each with row-level security policies and verification queries that run as the wrong user.

    Disclosure: if you create a Lovable account through links on this page, we may earn a commission. It costs you nothing and does not change what we recommend. Create a free Lovable account

    Frequently asked

    Is Lovable secure?

    Lovable runs two free scans and leaves the app's security requirements to you, per its docs. The public record shows the risk when that part is skipped: CVE-2025-48757, rated 9.3 critical, covers missing row-level security in generated apps, and the researcher found 303 exposed endpoints across 170 of 1,645 projects. Lovable disputes the record.

    What is CVE-2025-48757?

    A record published 30 May 2025: an insufficient row-level security policy in Lovable through 15 April 2025 let unauthenticated attackers read or write arbitrary tables of generated sites. NVD rates it 9.3 critical (CVSS 3.1). Generated apps call the database from the browser with a public key, so a missing policy exposes the table.

    What do Lovable's security scans check?

    The Quick scan runs at every publish: database access rules, npm dependencies with known vulnerabilities, and an unauthenticated MCP server. The Deep scan reads the app's code across seven areas, from access control to exposed personal data, in 3 to 13 minutes. Both are free; fixes beyond 10 free ones cost credits.

    Does a clean Lovable scan mean my data is safe?

    It means the checks found nothing at that time. A scan can confirm row-level security is on; it cannot know which rows each of your roles should see. Run a query as a user who should be denied and expect zero rows.

    Should I ask Lovable's chat to run a security scan?

    No. On my project the chat ran its own lighter checks, called them clean, said the in-depth review must start from the Security tab, and billed 1.3 credits. The Deep scan in the Security view is free.

    What was the April 2026 Lovable security issue?

    A disclosure on X, written up by Bastion on 20 April 2026, that a free account could read other users' source code, credentials and chat history for projects created before November 2025. Lovable's April 2026 changelog has no entry for it, so I cite the write-up and repeat no numbers.

    What we did not publish

    • Counts of exposed users or databases for the April 2026 disclosure. No primary source I could verify publishes them.
    • A scan of other people's Lovable apps. The researcher did that with disclosure; I did not.
    • A claim that the kits are secure for your app. They pass their own checks on the tables they ship; your app adds tables they never saw.

    Sources

    1. NVD: CVE-2025-48757, read 23 October 2026
    2. Matt Palmer: Statement on CVE-2025-48757, 29 May 2025, re-read 23 October 2026
    3. Lovable docs: Security and Security view, read 23 October 2026
    4. Lovable docs: Changelog, April 2026 entries, read 23 October 2026
    5. Bastion: Lovable April 2026 write-up, 20 April 2026
    6. My Deep scan run, 26 September 2026; the kits' own SQL files

    Written by

    Marco Kohns

    Marco Kohns

    Founder of ProtoBites - Venture Growth Studio

    Growth PM at a Silicon Valley scale-up (a16z and General Catalyst backed), ex-Techstars where he consulted 13 early-stage startups, Reforge-trained. Every prompt on this site comes out of shipping ProtoBites' own portfolio products.

    WebsiteLinkedInX