Lovable Data Breach: Was Your App Exposed?

Lovable confirmed that, between February 3 and April 20, 2026, any authenticated Lovable user who had a public project link could potentially access that project’s source code and chat history. Lovable fixed the permission regression within two hours of the April 20 public report. Private projects and Lovable Cloud were outside the incident’s scope.

The April 20 demonstration, posted on X by @weezerOSINT, the security researcher who published the walkthrough, took five API calls and no exploit chain, just an ID any signed-in account could already see.

That is the clearest answer available to “Was my Lovable app exposed?” Your project was potentially affected if it was public during that window. Potential access and confirmed viewing are different facts. In its April 22 incident response, Lovable said it was still reviewing which public projects had actually been viewed by people other than their owners and would contact affected owners.

The incident concerned Lovable’s editor-side project data. It does not prove that a project’s deployed database was accessed. Source code or chat history can still contain server secrets, connection strings, personal data pasted into prompts, and enough configuration to reach another system. Those exposures need to be investigated separately.

If your project was public during the affected window, preserve available logs before changing retention settings, inventory the source and chat history, and rotate any server-side credential that appeared there. Do not treat a visible browser-safe publishable key as a server secret; the distinction is covered below.

Checked August 16, 2026: no change. Lovable has published no further security incident report since its April 22, 2026 postmortem, and the affected window is unchanged at February 3 to April 20, 2026.

Were you affected?

How do I check whether my Lovable project was public?

Open the project and click Share in the top bar. That is where a project’s access setting lives. The workspace-wide default sits under Settings, then Privacy & security, then Default project access. Public remixing, the toggle that lets anyone with the link copy the project and read its source, is under Project settings, then Sharing. Lovable documents all three.

Today’s setting does not prove what the setting was in February. Lovable converted historically public projects to private on April 20, 2026, except official remixable templates, so a project that reads private now may have been public for the whole window. Treat the current value as a starting point, not as evidence.

Three other places to look:

• Your Lovable account email and in-product notices. Lovable said it would contact owners of public projects that may have been viewed. A message narrows the scope for you. No message does not clear you, because the viewing investigation was still running when the postmortem went out.
• Your public Lovable profile and any remix links you shared. A public project was showcased on the owner’s profile page, so a project you once promoted that way was public.
• What “public” applied to. Project visibility controls who can open the editor, the code, and the chat. Website access controls who can load the deployed app. They are independent settings, so a live app does not imply a public project and a private project does not imply a private app.

The Lovable incident timeline

A public Lovable project meant the project workspace itself was open: its source code, its chat history, and a remix link, showcased on the owner’s profile. That is not the same as a deployed app being live on the internet. Every published app is reachable by the public; not every project was.

That is intentional behavior. We have experimented with different UX for how the build history is surfaced on public projects, but the core behavior has been consistent and by design.

That is Lovable’s own first-day language, reported by The Register. The company’s response moved through three positions in a single day: first that no breach had happened and that the documentation of what public implies was unclear, then that the access was intentional behavior, then, in a second statement later the same day, that its bug-bounty partner HackerOne had closed the reports without escalation. The April 22 postmortem, which accepts the regression and the triage failure, is the more accountable primary source; the first-day statements are part of the record of how the incident was handled.

Lovable says code and chat history for public projects had been accessible by design early in the product’s life, then deliberately restricted during 2025. Enterprise users moved to private-by-default in May 2025, and all new projects did so in November 2025. The February regression undid those restrictions for public projects until the April fix.

This timeline matters because “my project was created before November 2025” is not enough to establish exposure. The relevant question is whether the project was public between February 3 and April 20, 2026. A project that was private throughout that window falls outside the scope Lovable disclosed.

Why the reports sat unactioned

The first valid HackerOne report reached Lovable on February 22, 2026. Lovable says every report was closed without being escalated to its internal security team, because the guidance given to the triagers still described public chat visibility as intended behavior. The triagers were reading an outdated document and closing correct reports against it.

The researcher’s public post said the bug had been reported 48 days earlier, which counts back to March 3, 2026 and refers to their own report rather than the first one. From the February 22 HackerOne report to the April 20 fix is 57 days. Both numbers describe the same failure: correct reports arrived, and nobody with the authority to act on them ever read one.

What could have been visible

Lovable’s postmortem confirms two affected surfaces: public-project source code and chat history. Source code can reveal API endpoints, database credentials, database project identifiers, business logic, and any secret that was hardcoded instead of stored in a secret manager. Chat history can contain prompts, pasted logs, copied customer records, and credentials shared while debugging.

The reach of an exposed project is concrete. The Next Web’s report documented how hardcoded Supabase database credentials from a single exposed public project opened a Danish nonprofit’s live database, where the records included real names, job titles, LinkedIn profiles, and Stripe customer IDs of professionals from Accenture Denmark and Copenhagen Business School. Neither organization built anything on Lovable; their people’s data was sitting in someone else’s project.

Supabase’s current key model makes one detail easy to get wrong. A publishable key, and the older anon key it replaces, is designed to appear in browser code. Its safety depends on Row Level Security and least-privilege grants. A Supabase secret key or legacy service_role key bypasses RLS and must never appear in browser code or a shared project history. Supabase documents the distinction and rotation path.

How to check whether your Lovable project was affected

If the project was public at any point in the window, work through these six steps in order.

1. 01 Check whether the project was public at any point between February 3 and April 20, 2026. Review Lovable emails and in-product notices as well as the current visibility setting.
2. 02 Export or review the project source and chat history. Inventory server-only keys, database URLs, webhook secrets, OAuth client secrets, personal data, and internal instructions that appeared there.
3. 03 Rotate exposed server-side credentials. Replace each secret in every service that uses it, deploy the replacement, verify traffic, then revoke the old value.
4. 04 Do not rotate a Supabase publishable or legacy anon key solely because it appears in frontend code. Check RLS and grants instead. Rotate any exposed Supabase secret or service-role key because it bypasses RLS.
5. 05 Review provider logs for the affected window and the period afterward. Look for unfamiliar database reads, API calls, logins, exports, or billing activity. Preserve the logs before changing retention settings.
6. 06 If other people’s data may have been accessed, document the facts and dates and get incident-response or legal advice for the jurisdictions and contracts that apply. A public incident does not create one universal notification rule.

Step 5 will dead-end for most readers, and that is expected rather than a mistake on your part. Supabase keeps API and database logs for 1 day on the Free plan, 7 days on Pro, and 28 days on Team, per its pricing page. Nothing from February to April 2026 survives on any of those tiers. Most other hosts are in the same range.

When the log window has already closed, look at state instead of events. Check for user accounts created during or after the affected window that you cannot place, rows and storage objects you did not expect, outbound email or SMS volume, and charges on connected services. Write down what you checked and what you found. Absence of logs is an unresolved question, not a clean result, and recording it that way is more defensible later than claiming nothing happened.

Lovable said it would contact owners whose public projects may have been viewed. That message can help scope the incident, but its absence does not replace your own credential and log review if the project was public during the window.

What to search for in your exported code and chat history

Export the project source and the chat history, then search both for literal strings. This takes minutes, and it turns “there might be a secret in there” into a list you can act on.

# Server-side keys and tokens
SUPABASE_SERVICE_ROLE_KEY
service_role
STRIPE_SECRET_KEY
sk_live_
sk_test_
OPENAI_API_KEY
ANTHROPIC_API_KEY
RESEND_API_KEY

# Database connection strings
postgres://
postgresql://

# Raw key material and env files
eyJ
BEGIN PRIVATE KEY
.env

eyJ is the opening of any base64-encoded JWT, so it catches Supabase legacy keys and most session tokens even when the variable name is something you never thought to search for. sk_live_ is a Stripe live secret key and is the worst string on that list to find. sk_test_ is a sandbox key and is lower severity, but finding one tells you keys were being pasted into the project at some point, so keep reading.

Search the chat history separately, and search it for language rather than variable names. People paste secrets while debugging and describe them in plain words. Try here is my key, my key is, paste, connection string, and password, plus a bare @ to surface pasted CSV rows and customer email addresses.

The platform fix does not test your app’s authorization

The April fix closed a Lovable platform permission regression. Your deployed app can still have a separate object-level authorization flaw. OWASP calls this Broken Object Level Authorization: a signed-in user changes an order, document, or tenant ID and the server returns an object that user does not own.

The June and July 2026 AxonBuild audit cohort saw a confirmed cross-user or cross-tenant path in 7 of 21 third-party apps, with RLS gaps in 9 of 21. Those counts describe that one historical cohort; no conclusion about all Lovable apps follows from them.

One app in that cohort accepted an unsigned session object from a browser cookie. Changing its workspace field granted access to another tenant’s alerts, customer records, and orders. The app had clean TypeScript and little duplication. Its tenant boundary still depended on one value the browser could edit.

The two-account test

The useful test needs two accounts:

1. Create a private record with account A.
2. Sign in as account B.
3. Repeat the same read, update, and delete request using account A’s record ID.
4. Confirm that the server denies every operation and that no private fields appear in the response.

A hidden button is not an authorization check. The server or database policy must enforce ownership on every operation that accepts an object identifier. What Lovable’s production checks cover and why AI coding tools miss cross-cutting access rules own those broader questions, and whether an outside audit of that boundary is worth paying for is its own decision.

What Lovable’s trust center does and does not answer

Lovable’s trust center describes platform controls and certifications. Lovable’s current security documentation also covers scanning for dependencies, secrets, database configuration, RLS, and code vulnerabilities. Those controls are relevant evidence about the vendor and can catch common mistakes.

They do not establish that every access rule in one customer app matches its business model. A scanner can see a policy and still miss that the policy grants one tenant access to another tenant’s rows. The two-account test checks the decision your users rely on. The same platform-versus-app split is why whether Base44 is safe resolves into two answers despite its own SOC 2 and ISO 27001 attestation.

The April incident was also not the platform’s only authorization story of 2026. In February, Taimur Khan reported inverted authentication logic in a separate Lovable-hosted app, featured on Lovable’s own Discover page with over 100,000 views, that let anonymous visitors in while blocking logged-in users. It exposed 18,697 records, 4,538 of them student accounts, from UC Berkeley and UC Davis, and his report went in through support and closed with no response. That app’s flaw was its own, not Lovable’s infrastructure; the triage failure is the part that rhymes with the April postmortem.

The practical conclusion is narrow. Lovable fixed the April platform incident quickly and published a detailed postmortem two days later. Owners of public projects in the disclosed window still need to determine what their own code and chat history contained. Every owner also needs to test the authorization rules inside the deployed app, because that is a different boundary. Is your AI-built app ready to launch covers the rest of that launch list.

Common questions about the Lovable breach

Was Lovable hacked?

Lovable described the event as a backend permission regression, not an attacker breaking into its infrastructure. The regression let authenticated users with a public project link potentially access that project’s source code and chat history. That is a security exposure regardless of whether the root cause was a software change rather than an intrusion.

Was this a data leak or a data breach?

Both words describe the same disclosed facts here. Lovable denied a mass data breach and its posted line was “We did not suffer a data breach”, while its April 22 postmortem accepts that a backend permission regression left public-project source code and chat history readable by any signed-in user with the link for 76 days. Nobody broke in, and data that should have been restricted was readable anyway, so leak, breach, and exposure all point at the same event. The label matters less than whether your project was public in that window.

Which Lovable projects were affected?

Lovable’s confirmed scope was public projects between February 3 and April 20, 2026. Private projects and Lovable Cloud were not affected. Project age alone does not settle the question; visibility during the affected window does.

Were database credentials exposed?

Only where the owner had put them in the project’s source code or chat history. The incident opened public-project code and chat, not a credential store, so what leaked depends entirely on what each project had written down. Hardcoded Supabase connection strings and service-role keys were the common case in reported examples, which is why rotating server-side keys comes before everything else on the checklist.

Did the incident expose my customer database?

Lovable’s postmortem confirms potential access to public-project code and chat history, not universal access to connected databases. If those surfaces contained a database secret or service-role key, the connected database may have been reachable. Inspect your project, rotate any server-side key you find, and review database logs before making a claim about actual access.

Are my Lovable chats private now?

Yes, for the issue Lovable disclosed. Lovable fixed the permission regression on April 20, 2026 and converted historically public projects to private, except official remixable templates. A project’s visibility setting now governs editor access to both the code and the chat history, and you can check or change it from the Share button in the project’s top bar. Chats written during the affected window on a project that was public then are still part of what may have been read.

Do I have to tell my users?

Possibly. The controller and processor roles depend on who determines the purposes and means of the relevant processing, not on app ownership alone. Under EDPB guidance, a controller must notify the relevant authority within 72 hours when a personal-data breach is likely to risk people’s rights and freedoms. A processor must notify the controller without undue delay. Every breach still needs to be documented, even when authority notice is not required because risk is unlikely. Exposure of a credential is not the same as proven access, so record what was exposed, the dates, and what the logs show. Then seek advice for your jurisdiction and customer contracts.

Have there been any Lovable security incidents since April 2026?

None that Lovable has published: checked again on August 16, 2026, and there is no change. The April 22, 2026 postmortem is still its most recent security incident report, and the disclosed window has not been extended beyond February 3 to April 20, 2026. This page carries the date it was last checked so you can judge how current that answer is.

Is Lovable safe to use now?

The disclosed permission regression was fixed on April 20, 2026. Lovable also converted historically public projects to private except official templates and changed its vulnerability-triage process. The broader Lovable safety verdict covers current platform controls and the separate question of whether your own app’s authorization rules work.