Lovable AI Agent Security Audit — Due Diligence Report

The subject of this report is the AI app-creation platform operated at lovable.dev ("Lovable"), and specifically the security posture of the applications it generates and of the publish-time controls the platform applies to them. We did not verify the corporate identity, ownership or jurisdiction of the vendor from the sources consulted, and this report does not rely on any figure of scale, funding or adoption. [S1] That restraint is deliberate: a desk-based report should carry only what the fetched record supports, and the marketing and incident documents below are sufficient to the findings.

What the vendor's own security page asserts is the relevant baseline, because it is what a procurement questionnaire will capture: a page headlined "Secure by design", enterprise controls (SAML, OIDC, SCIM, server-side RBAC), regional data hosting in the EU, US and Asia Pacific, no model training on Business and Enterprise data, and an automatic security scan on every publishcovering "database configurations, RLS rules, cloud project settings, and known misconfiguration patterns in about 10-15 seconds", with an on-demand deep scan of about three minutes and scheduled deep scans on Business and Enterprise plans. [S1]

Materiality for a risk file. The buyer this report is written for is not choosing whether to adopt an IDE autocomplete. It is deciding whether to let a natural-language platform generate, host and publish applications that hold real end-user data — and, on the enterprise plans the vendor is actively marketing, to make that practice a matter of company policy. The incident record examined in §04 concerns precisely that deployment: applications generated on the platform, holding real data, whose database access control failed at scale.

The architectural fact that organises this file comes from the CVE disclosure itself: Lovable applications are "primarily client-driven" and "rely on external services for backend operations like authentication and data storage", which shifts the security burden to the implementor of the application. [S2]In the generated-app pattern, the browser talks directly to a backend database (in the documented cases, Supabase) using a public anonymous key embedded in the client; Row Level Security policies are the only thing standing between any visitor and the whole table. When those policies are missing or misaligned with application logic, "attackers can bypass frontend controls to directly access or modify data". [S2]

The NVD record generalises it: "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." [S3] MITRE's CVSS 3.1 vector for the record is 9.3 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N) — network-exploitable, no privileges, no user interaction, scope changed. [S3] The record is disputed by the supplieron the ground that "each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application". [S3] We return to that dispute in §3.6 and §07.

2.1 — The platform's publish-time control surface

• Basic scan on every publish— "checking database configurations, RLS rules, cloud project settings, and known misconfiguration patterns in about 10-15 seconds". [S1]
• Deep scan on demand — about three minutes, analysing the full codebase; Business and Enterprise workspaces can schedule recurring deep scans across all projects. [S1]
• Auto-fix and publish blocking — workspace admins can let the agent resolve non-breaking findings during basic scans, and can block publishing on critical findings. [S1]
• Continuous dependency checks run in the background on every edit. [S1]
• Isolation model— "a multi-tenant platform with logical isolation between workspaces and projects"; environment boundaries "explicitly defined and evaluated before changes are published". [S1]

2.2 — Threat model

The threat we model is not an attacker against Lovable's own infrastructure. It is the platform's own failure mode, demonstrated in §04: an application generated for a non-developer holds end-user data behind an RLS policy that is missing or wrong, the publish-time control that should catch the condition reports the application safe, and any party on the internet can read — in the documented re-test, also write — the data by editing a query. [S2][S3]The blast-radius unit is therefore a generated application and everyone whose data it holds, and the blast-radius multiplier is the platform's user base of non-developers, who are the least likely to audit an RLS policy they cannot see.

The architectural finding of this reportis that the platform's marketing and its dispute position describe two different products. The marketing describes a platform whose publish-time scanning checks RLS configuration so that customers do not have to be security experts — "Secure by design". The dispute position describes a platform where "each individual customer... accepts a responsibility over protecting the data of their application". [S1][S3] Both can be true in a shared-responsibility sense, but a buyer is entitled to know which of the two will be in the contract.

Threat model: a team — or a single non-technical founder — generates an application on Lovable that collects real end-user data: sign-ups, profiles, payments, integrations. Whose hands can that data land in?

The demonstrated exposure is of end-user data, at scale. The researcher's scan of the platform's own showcase directory identified 303 endpoints across 170 projects (approximately 10.3% of the 1,645 analysed) with inadequate RLS settings, exposing sample data that included user tables, transactions and subscriptions, and the disclosure appendices contain redacted end-user records — names, emails, payment status — retrieved from a generated site.[S2]The disclosure email included in the record lists what the endpoints exposed across sites: "subscriptions, names, phone numbers, API keys, payment details, Google Maps tokens, and various other PII." [S2] The scan covered homepages only; the researcher notes that authenticated areas could expose more. [S2]

The vendor's present claims on this dimension are specific and recorded: regional data hosting in the EU, US and Asia Pacific with data remaining in the selected region by default; logical isolation between workspaces and projects; and no model training on Business or Enterprise data, with an opt-out for Free and Pro users. [S1]These are the right commitments on paper. We note two things. First, they are vendor assertions — the sub-processor list that would let a buyer verify the residency chain is "available upon request", not published. [S1]Second, they post-date the incident by more than a year, and the record of what changed after the incident is the vendor's own (§04). [S2][S4]

OWASP relevance: LLM06 (Sensitive Information Disclosure). Hundreds of generated applications silently returning full tables to unauthenticated queries is the canonical LLM06 incident for an app-generation platform.

Threat model: the platform itself is the tool — a code- and database-generating agent whose output goes live at the push of a publish button. The question is what the platform's automated control actually verifies before that moment.

This is the finding a procurement team should take out of the whole report, because it is the failure mode of automated control as a category. An RLS policy that says "allow all" is present; it is also worthless. A control that verifies presence will pass it. The platform shipped the existence-check ten days after the researcher re-notified the vendor of a publicly exploited vulnerability, and the disclosure states it "did not address the underlying RLS architectural flaw". [S2]The current security page describes the basic scan as checking "RLS rules" and "known misconfiguration patterns", and the deep scan as analysing the full codebase [S1] — but the published record contains no independent test of whether the present scans validate policy correctness, and the remediation arc is self-reported. [S1][S4]

Credit where the record supports it: the current feature set — deep scan, auto-fix, block publishing on critical findings, scheduled scans for Business and Enterprise — is aimed at the right control point, the publish moment. [S1] A publish gate is exactly where an app-generation platform should put its security tooling. The question this report leaves open is whether the gate tests what the marketing says it tests, because the only independent evidence in the record is of a version that did not. [S2]

OWASP relevance:LLM08 (Excessive Agency). The agent decides what database and access-control configuration an application ships with; the human approver is, by design and market, frequently a non-developer who cannot review it. When the automated review of that agent's output verifies presence rather than correctness, the agency and the control are misaligned in exactly the way LLM08 describes.

Threat model: an app generated in plain language needs third-party credentials — a maps token, an LLM key, a marketplace token. Where do those secrets live, and who can retrieve them?

The finding needs its precise shape, because the two statements describe different layers. The marketing claim concerns the platform's own secrets handling: values stored in Lovable Cloud, encrypted and role-controlled. [S1] The incident is one layer out: a generated application exposing an endpoint that hands a third-party credential to any caller, because the access control around the endpoint is absent or wrong. [S2]The vendor could say, and its dispute position implies it, that the exposed keys were the builders', stored and served by the generated code.

The reason the tension belongs in the report anyway is the buyer's vantage point. A procurement team reading the security page takes away that credentials on this platform "are not exposed in plaintext in logs or interfaces". The record shows that the most common secrets in this ecosystem — Gemini, Google Maps and eBay keys — were being handed out, unauthenticated, by generated endpoints at the rate of the scan findings, and that the platform's publish-time control did not catch the condition that exposed them. [S2] Whatever the correct allocation of responsibility, the absolute claim on the page is broader than the record supports, and the exposure in the record is precisely the one the claim, read as a buyer would read it, rules out.

The practical control is unchanged by the dispute: any third-party key that passed through a generated app before an access-control audit must be treated as disclosed and rotated, and only scoped, expendable credentials belong in a vibe-coded application. [S2]

OWASP relevance:LLM06 (Sensitive Information Disclosure) and LLM07 (System Prompt Leakage's cousin in generated code): secrets embedded in or reachable through generated artefacts whose exposure surface the builder does not understand.

Threat model: a generated app takes payments from its own users. What can an unauthenticated caller do to the payment state of that app?

The record contains a payment-integrity finding that is easy to miss and should not be. In the May 2025 re-test of a generated site — one maintained, the researcher notes, by a Lovable employee — removing the authorization header "allowed unrestricted read access and, critically, unauthorized write operations". The researcher "successfully inserted a new record... including setting 'payment_status': 'paid', thereby bypassing the Stripe integration." [S2]The record is a single demonstration on a single site, and we present it as such. But the class it demonstrates — payment state writable through a generated app's own database endpoint, bypassing the payment provider entirely — is the platform's core architectural weakness (§02) with a financial payload.

We found no vendor documentation, on the page fetched, describing what the basic or deep scan checks about payment-adjacent tables or webhook integrity in generated applications. [S1] The same caveat as §3.2 applies: absence from a marketing page is not absence of coverage, and we do not assert either way — we record that a buyer cannot determine it from the public surface.

OWASP relevance: LLM08 (Excessive Agency) with a D4 payload: an agent-generated application whose financial state can be written by an unauthenticated actor.

Threat model: something goes wrong in an app your team generated on the platform. What does the vendor tell you, and what can you independently rely on?

Public information on continuity — uptime, recovery, backups, status history — is thin in the sources consulted, and we say so rather than rate an absence. The security page's continuity content is limited to monitoring and abuse-detection tooling and WAF protection of Lovable Cloud. [S1] We did not locate a public status page, SLA or uptime commitment in the fetched material, and we made no claim about their existence or absence beyond what we fetched.

The post-incident record has the same shape: the secondary analysis states the vendor "hasn't published a full, public post-mortem for CVE-2025-48757". [S4] Continuity of trust is a continuity control like any other. A buyer should test it directly: ask the vendor for its incident-notification commitments and its post-mortem practice, and weigh a refusal to put either in writing.

Threat model: a generated app leaks its users' data. The users sue — or a regulator does. Who does the vendor say is responsible, and what does it say everywhere else?

The dispute has a defensible core. In a client-driven architecture the RLS policy is application logic, and no platform can guarantee the correctness of every customer's policy. A shared-responsibility statement to that effect would be unremarkable. What makes the position risky for a buyer is the contrast with the marketing: a platform that sells "Secure by design" and automatic publish-time RLS scanning [S1]while disputing, on the record, responsibility for generated applications' data protection [S3] has reserved both positions. In an incident, the customer will learn which one the contract carries — and the disclosure record shows the vendor contesting responsibility while the 45-day window ran.[S2][S3]

The dual-role problem.A business that ships a generated app is simultaneously the vendor's customer and the controller of its own end users' data. Under GDPR the controller cannot delegate its way out of an Article 32 failure by pointing at the platform, and the platform's dispute position pointedly does not offer to carry it. The residency and no-training commitments on the security page [S1] are relevant and favourable; they are not an allocation of liability, and the sub-processor list that would let a buyer map the transfer chain is available only on request. [S1]

We did not fetch or review the vendor's terms of service, DPA or privacy policy, and this report makes no assertion about their contents. That gap is itself the finding for procurement: the security page and the dispute position are the only liability-relevant documents on the public surface we reviewed, and they point in opposite directions.

One incident is on the record, and it is extensively documented by the researcher, by MITRE and in secondary coverage. Its dates are all in 2025; the report is written in 2026 because the marketing framing the incident contradicts is still live. [S1][S2]

4.1 — CVE-2025-48757: missing or insufficient RLS across generated apps

On 20 March 2025 the researcher found that a Lovable-generated site (Linkable, a LinkedIn-profile website generator) allowed any visitor to read its entire users table by editing a query. The platform's Twitter account denied the issue, then deleted its tweets and the site. [S2]A scan of the platform's own showcase directory, run the next day, found 303 endpoints across 170 projects with inadequate RLS — including endpoints named get-google-maps-token, get_gemini_api_key and refresh-ebay-token. [S2]

The notification timeline is documented in full: notified 21 March 2025; receipt confirmed 24 March; on 14 April a Palantir engineer independently found and publicly demonstrated active exploitation of the same class — "extracting personal debt amounts, home addresses, API keys" — and the researcher re-notified, opening a 45-day window; on 24 April the vendor released "Lovable 2.0" with a "security scan" that, per the record, checked policy existence and not correctness; on 29 May 2025, "with no meaningful remediation or user notification from Lovable, we published our CVE." [S2]

A re-test on 24 May 2025 against the same company-maintained site found the original flaw relocated but the class intact: removing the authorization header bypassed all access controls, granting unrestricted read and — critically — write, demonstrated by inserting a record with "payment_status": "paid", bypassing the Stripe integration. [S2]The researcher's conclusion: "critical security issues, extending to data manipulation and injection, persist even on company-maintained sites despite prior notification and the 'Security Scan' feature." [S2]

4.2 — The vendor's response, on the record

Four responses are documented. A denial followed by deletion of its own public statements (March 2025). [S2] A scanner release that the record and secondary analysis describe as testing existence, not correctness (April 2025). [S2][S4]A public self-assessment quoted by the secondary analysis: "Lovable is now significantly better at building secure apps than a few months ago... we're not yet where we want to be in terms of security." [S4]And a formal dispute of the CVE record at NVD, on the ground that data protection is each customer's responsibility. [S3]

Our reading.The dispute is a legitimate procedural device and the shared-responsibility argument behind it has a real core. But the aggregate posture — deny, delete, scan existence, self-congratulate, dispute — is not the response pattern of a vendor treating generated-app security as its own product surface, and every document describing remediation after April 2025 is the vendor's own. There is no public post-mortem. [S4] We found no independent re-test of the scanner. For a platform whose marketing leads with security, that asymmetry is the finding.

• The publish gate's depth is unverifiable.The current page says the basic scan checks "RLS rules" and "known misconfiguration patterns"; the only independent record of the platform's scanner says it checked existence, not correctness. [S1][S2]
• Remediation is self-reported.Every document describing what changed after April 2025 is the vendor's own; there is no public post-mortem and no independent re-test in the record. [S1][S4]
• The marketing and the dispute position are unreconciled."Secure by design" here, "each individual customer... accepts a responsibility over protecting the data" there. [S1][S3]
• Generated apps hold end-user data the builder does not control.The exposed records were the apps' users' — names, emails, phone numbers, payment status. [S2]
• Third-party keys are the ecosystem's default secret, and the documented exposed endpoints are key-delivery endpoints. [S2]
• Payment state is database state.A write-bypass to an app's database can set payment_status without the payment provider. [S2]
• The sub-processor list is not published— "available upon request" — so residency chains cannot be verified from the public surface. [S1]

The compliance language is soft.The security page states that "Lovable supports SOC 2 and GDPR requirements and provides security documentation and data protection agreements for enterprise review" [S1] — a support claim, not an attestation claim, and one that does not name an auditor, a report, or a scope. A Trust Center is linked from the page; we did not fetch it, and no attestation artefact is in the record we reviewed. A buyer should request the SOC 2 report and its scope and rate it only when read — which is the standard we apply to every vendor in this series.

The reputational record is durable and unflattering.Coverage at the time of disclosure described Lovable sites as "a sitting duck for hackers". [S4] The CVE carries a 9.3 CRITICAL CNA score, [S3]and the dispute — a supplier arguing with its own record in a public database — keeps the story current. The "Secure by design" framing remains on the live page as of the observation cutoff, [S1] which means every new enterprise conversation the vendor enters is an opportunity for a buyer to discover the contradiction without our help.

One credibility fact cuts the other way.The vendor's own public self-assessment — "we're not yet where we want to be in terms of security" — quoted by the secondary analysis [S4] is more candid than most security marketing, and worth more than the page it sits apart from. Candour in one document is a reason to test, not to trust, the absolutes in another.

The legal picture on the fetched record rests on three documents: the vendor's security page, [S1] the dispute text in the CVE record, [S3] and the disclosure correspondence published by the researcher. [S2]The vendor's terms of service and DPA were not fetched and are not assessed here.

For a European buyer, three procurement-relevant points follow from the fetched record alone. First, the dual-role problem (§3.6): as controller of its end users' data, the buyer owns the Article 32 exposure of a generated app's access-control failure, whatever the contract says. Second, the verification gap: the sub-processor list is on request and the attestation language is support-grade, so the transfer and processing chains cannot be mapped from the public surface. [S1] Third, the marketing-to-contract gap: until "Secure by design" and automatic RLS scanning appear as contractual representations with consequences, they are decoration, and the dispute text is the operative document. [S1][S3]

We express no view on the merits of the dispute as a matter of vulnerability-database policy. NVD marks the record "Disputed" and has not scheduled enrichment; the CNA's score stands on the record. [S3]For a buyer, the dispute's practical meaning is simpler: the vendor contests the framing of its own platform's worst public security record, and a procurement file should require the vendor to state its position in the contract, where it binds.

A.1 — Sources consulted

All sources are public. They were fetched on 2026-10-08 and re-read for this report; publication dates are given where the source carries one. Findings above are tagged with the source identifiers below. Every quotation in this report was checked against the fetched text.

• S1 — https://lovable.dev/security· fetched 2026-10-08 · vendor marketing page · "Secure by design"; the secrets-handling claim; basic and deep scan descriptions; auto-fix and publish blocking; residency, isolation, training and SOC 2/GDPR statements; sub-processors on request.
• S2 — https://mattpalmer.io/posts/statement-on-CVE-2025-48757/· 2025-05-29 · researcher statement with disclosure appendices · discovery, scan findings (303 endpoints / 170 projects / 1,645 scanned), exposed endpoint names, the May 2025 write-bypass, the full notification timeline, the vendor's denial and deletion, and the researcher's affiliation (see A.3).
• S3 — https://nvd.nist.gov/vuln/detail/CVE-2025-48757· NVD record, published 2025-05-29, last modified 2026-06-17 · status Disputed; the supplier's dispute text; MITRE CVSS 3.1 9.3 CRITICAL and vector; CWE-863; affected versions through 2025-04-15.
• S4 — https://www.superblocks.com/blog/lovable-vulnerabilities· updated 2026-03-09 · secondary analysis by a competing vendor, used for corroboration and quotation at low weight · scanner "only flagged the presence of RLS, not whether it worked"; response "widely criticized as inadequate and non-transparent"; Lovable's X self-assessment; no public post-mortem; contemporaneous coverage.
• Reference framework: OWASP Top 10 for LLM Applications.

A.2 — Methodology

TrustworthAgent Express Security Reports are desk-based assessments conducted using exclusively publicly available information. This report follows our fixed eight-section structure — identity, architecture and threat model, the six-dimension security assessment, incident history, operational risks, reputational and compliance risks, legal risks, and recommendation — so that two vendors can be compared on the same axes. The six security dimensions assessed in §3.1–§3.6 constitute the TrustworthAgent Security Framework and are identical on every report we publish, so that a report written a year from now remains readable against this one. Each dimension is assessed against documented architectural choices, published policy commitments, the public incident record, known vulnerability classes from the OWASP LLM Top 10, and comparable market standards at equivalent company stage and product category.

Risk ratings are drawn from the fixed set LOW / MEDIUM / MEDIUM-HIGH / HIGH and reflect assessed materiality relative to the enterprise deployment scenario described in each threat model, not absolute severity in isolation. The recommendation is drawn from the fixed set GO / CONDITIONAL GO / CONDITIONAL GO STRICT / NO-GO.

A.3 — Limitations

This report is based on public information only. No testing of any kind was performed against Lovable or its platform.No penetration testing, no code review, no internal interviews, no non-public data access, and no use of the product to test any claim. The §3.2 and §3.3 findings are comparisons of the vendor's published statements with the published incident record, not the result of a test. The incident is reported as documented by the researcher, by the MITRE record at NVD, and by secondary coverage; we could not independently verify its details.

Researcher affiliation, disclosed.The disclosure correspondence published with CVE-2025-48757 states that the researcher works in Developer Relations at Replit, and the formal disclosure letter gives the filer's organization as Replit. [S2] Replit, Inc. was the subject of our own ESR-2026-005, published 2026-10-01. We disclose this because our readers weight first-party security research partly on who paid for it. It does not change the findings: the scale figures (303 endpoints, 170 projects) and the exposed endpoint names are in the disclosure record, the vulnerability class is confirmed by the MITRE record at NVD, [S3]and the scanner's existence-check is corroborated by an analysis published by a different party with its own interest to declare. [S4] But the reader is entitled to the fact, and a due diligence firm that hides an inconvenient affiliation has no reason to exist.

This report reflects publicly available information as of the observation cutoff, 2026-10-08. The vendor's security posture, documentation and policy commitments may have changed since. The following were material to our assessment and could not be verified from public sources:

• Whether the current basic and deep scans validate RLS correctness rather than existence, and whether publish blocking can trigger on an incorrect policy. The record describes the April 2025 scanner; the present behaviour is described only by the vendor. [S1][S2]
• The vendor's terms of service, DPA and privacy policy were not fetched and are not assessed; no assertion in this report covers their contents. [S1]
• The Trust Center and its artefacts (linked from the security page) were not fetched; any SOC 2 attestation, its scope and its auditor are unverified. [S1]
• The sub-processor listis "available upon request"; the residency and transfer chain is unmapped. [S1]
• The vendor's X statements are quoted second-hand, via the secondary analysis; the posts were not fetched directly. [S4]
• The CVE is disputedby the supplier; NVD enrichment is not scheduled, and the 9.3 score is the CNA's. [S3]
• The record's vintage. The incident, the scanner behaviour and the affected versions all date to 2025. What the platform does today is described by the vendor alone. [S1][S2][S3]
• The corporate identity, ownership and jurisdiction of the vendor were not verified from the sources consulted, and no figure of scale or adoption is relied on.

Where a fact was unavailable we have said so rather than inferred it. Risk ratings for compliance artefacts reflect verifiability, not quality. Lovable may well hold an excellent, broadly scoped SOC 2 report and a scanner that now tests correctness; we could not read either, so we could not rate either as verified, and we decline to credit what we have not seen.

A.4 — Non-affiliation and right of reply

This is a free, public, unsolicited report published by TrustworthAgent on 2026-10-08 (v1.0) as a demonstration of the Express Security Report methodology. TrustworthAgent has no commercial, financial, shareholding, contractual, partnership or mandate relationship with Lovable or lovable.dev, its officers, its investors or its representatives, and holds no position in the company. We were not asked to write this report and were not paid to write it. We do not invest, we do not rate consumers, and we do not sell signals about the companies we audit.

Observations, risk ratings and recommendations are opinions of analysis founded on the methodology described and the sources cited. They are not exhaustive or definitive statements of fact, and they are not investment, legal, tax, accounting, cybersecurity or regulatory advice. Any reader relying on this for a procurement or investment decision should commission a full mandate, which is scoped in writing and can extend to proprietary architecture documentation and authorized testing where the subject grants access.

Lovable has a right of reply. To request correction of a factual error or publication of a response, write to hello@trustworthagent.com citing this URL, the passages concerned, the supporting facts or sources, and the name and role of the person replying. We undertake to examine any good-faith request and, where it is founded, to correct the error, publish the response or add a dated update note within 5 business days of a complete request.