Lovable's April 2026 incident: was my project exposed, and what do I do?
Between February 3 and April 20, 2026, the chat history and source code of public Lovable projects could be read by any logged-in Lovable user who had the project link. Lovable fixed it within two hours of the public report on April 20, published a full account on April 22, and made every public project private. Private projects and Lovable Cloud (the built-in database) were not affected, by Lovable's account.
The question for you is whether your project was public during that window. If you created it on a free plan before November 6, 2025 and never changed its visibility, it was public by default. In that case, assume the chat and the code were readable, and act on what was in them: rotate any key or password you ever pasted into the chat, and check the code for anything hard-coded.
Then decide whether the app stays where it is. For most projects, the fix is done and staying is fine. For an app with paying customers, this is a fair moment to put the code in a repository you own and the data in an account in your name, so the next platform mistake has less to reach.
In founders’ words
“Please please please get someone to check your app or look for exposed API keys.”
“Is it just me, or does it feel like there have been a lot more security breaches + bugs since AI?”
What happened, in Lovable's words
On April 22, 2026, Lovable published its account. 'On April 20, a security researcher publicly reported that data within public Lovable projects could be accessed by any authenticated user. We shipped a fix within two hours, but both our product and initial external response missed the mark.' The window: 'Between February 3, 2026 and April 20, 2026 public project chat history and source code could potentially be accessed by any Lovable user provided they had a project link.' And the limit: 'Private projects and Lovable Cloud were never impacted.'
The cause, per the same post, was a regression. Public projects had once been open by design; Lovable removed that access during 2025, and 'In February 2026, backend regressions re-enabled public access to chat history and source code on public projects.' Researchers reported it through HackerOne, the first on February 22, 2026, and those reports 'were closed without being escalated to our internal security team' because of outdated documentation Lovable had given the triage partner. Lovable also wrote: 'Our first public response was dismissive and failed to acknowledge the real concern.'
What Lovable did: fixed the access, made all public projects private except its own remixable templates, removed the option to create public projects as of April 22, 2026, began reviewing which projects were viewed by someone other than the owner so it can contact those owners, and restructured its HackerOne triage. Press coverage of the researcher's report (The Register, April 20) described database credentials being readable inside chats; Lovable's own statement names chat history and source code.
Sources: lovable.dev/blog/our-response-to-the-april-2026-incident and docs.lovable.dev/features/project-visibility, read on October 2, 2026.
Was your project affected?
Lovable has two separate settings, and the names confused many people. Project access controls who can open the project in the editor, including the code, the chat history and unpublished work. Website access controls who can visit the published app. Publishing does not make the project public, and a public project does not mean a public website.
Your project was in the exposed group if its project access was public at any point between February 3 and April 20, 2026. Before November 6, 2025, projects on free plans were public by default and only paid workspaces could change that. From November 6, 2025, new projects defaulted to workspace visibility, and in December 2025 Lovable moved every workspace's default to workspace. A project created on a free plan before November 2025 and never touched is the usual case.
If Lovable's review finds your project was viewed by someone else, it has said it will contact you. Do not wait for that email to do the next section.
What to do today, whether or not you move
- Read your chat history for anything secret. People paste API keys, database passwords, Stripe keys, customer spreadsheets and login details into the chat because it is the easiest way to get them into the app. Anything you find there, treat as seen.
- Rotate every key that appeared in chat or code: Supabase or Cloud service keys, Stripe, OpenAI or other model keys, email providers, OAuth client secrets. Rotation means creating a new key and deleting the old one, not only adding a new one.
- Change any password that was pasted, including test accounts that still exist.
- Check the code for hard-coded secrets. The frontend ships to every visitor's browser; a key in there was public before and after the incident.
- If customer personal data was in the chat (a list of users, support messages, uploads), read your own privacy policy and the laws that apply to you, and ask a lawyer whether you have a notification duty. We cannot answer that for you.
- Check the project's current access setting. Public is gone; make sure workspace access is what you want, and remove collaborators who no longer need it.
Your options
Stay. The exposure is closed, public projects no longer exist, and Lovable published a detailed account with dates. For a prototype or an app without paying customers, rotating keys and moving on is a reasonable choice.
Stay, but hold your own copies. Git sync works on all plans and keeps a repository you own in step with the project. Paid plans can also download the codebase. With the code in your GitHub and a database export in hand, a platform problem costs you time, not the business.
Move the app to accounts you own. The code to your repository and your own host, the database and files to a Supabase project or a server in your name, secrets in your own settings, AI calls on your own key. Lovable's own guide for this exists and the sequence below follows it.
Why this is a reasonable moment to move
The incident did not touch Lovable Cloud. The lesson is narrower than 'the platform is unsafe': code and chat lived in one multi-tenant system, and a permission regression in that system reached them. On infrastructure you control, the surface is yours to set. Your repository has the collaborators you added. Your database has the keys you issued. A mistake on someone else's platform cannot reach them.
What it takes is the set of steps below, done in order with the Lovable app still live. For an app of ordinary size this is a few weeks of staged work, most of it mechanical, and the hard parts are known in advance. That is the kind of job where guidance matters more than hours. Our free call reads the app and tells you what the move would take, or that you do not need one.
What a move involves, step by step
- Code. Turn on Git sync (all plans) or download the codebase (paid plans). Run the app on your own computer from the clone first. Lovable's guide says a working local run 'confirms what the app needs installed, its dependencies, and the environment variables it reads'.
- Database and files. Cloud's Export project data gives you the full database, structure and records, including user accounts with password hashes. It does not include storage files, Edge Function code or secrets. Download storage files from the Storage view. Create the destination (a Supabase project in your account, or self-hosted Supabase on your own server) and apply the migration files from the repository in order, then restore the export.
- Sign-in and users. Users keep their passwords when the export is restored into Supabase. Sign-in providers (Google, Apple, email) and redirect URLs are configured again at the destination, and signed-in users sign in again after the switch.
- Secrets. Function secrets and API keys are not exported. Enter them in the new host, and use this moment to rotate them.
- Payments. Stripe is already in your name; the webhook endpoint and the function that handles it move with the server code. Test in Stripe test mode on the new deployment before anyone pays through it.
- Domains and email. Point your custom domain at the new host last. Transactional email from your own domain needs DNS records that take time to propagate, so start that early.
- AI providers. Model calls that ran through Lovable's AI gateway become calls on your own provider key, under that provider's terms.
- Test before switching. Lovable's guide is specific: open a nested route and refresh, sign in and out, run the reads, writes and uploads the app depends on, all on a temporary URL. Then take the final export, switch the domain, and unpublish on Lovable when the lovable.app address should stop serving.
When you may not need to move
If your project was private throughout, nothing in this incident touched it. If it was public but the chat held no secrets and no customer data, rotating keys as a precaution is enough. And if nobody pays for the app yet, holding your own copies (Git sync plus a database export) gets you most of the protection for an afternoon of work.
Move when customers pay, when a customer's security review asks who can see the code and data, when the chat held things you could not fully clean up, or when you had already decided the app needs tests, a staging copy and a deployment you control. The incident is a reason to decide; it is not the only reason to move.
| Your project | Exposed between February 3 and April 20, 2026? | First step |
|---|---|---|
| Created on a free plan before November 6, 2025, visibility never changed | Yes, by default it was public | Read the chat for secrets and rotate them today |
| Created after November 6, 2025 on any plan | No, unless you set it to public yourself | Confirm the access setting; nothing else needed |
| Set to private or workspace before February 3, 2026 | No | Nothing needed for this incident |
| Data in Lovable Cloud (database, storage) | No, per Lovable | Rotate keys only if a key was pasted in chat or code |
| Published website | Not affected; website access is a separate setting | Nothing needed |
Questions
Was my customers' data in Lovable Cloud exposed?
Lovable says no: 'Private projects and Lovable Cloud were never impacted.' What could be read was the chat history and source code of public projects. If a database key or customer data was pasted into a public project's chat, that copy was readable, which is why the rotation steps matter.
How do I know if my project was public?
Projects created on a free plan before November 6, 2025 were public by default unless a paid workspace changed them. Public visibility was removed on April 22, 2026, so you cannot see the old setting now. Lovable has said it will contact owners whose projects were viewed by someone else during the window.
Does publishing my app make the code public?
No. Lovable's docs separate project access (who can open the editor, code and chat) from website access (who can visit the live app). Publishing changes only the second.
Is Lovable safe to keep using?
The exposure was fixed within two hours of the public report, public projects no longer exist, and Lovable published a dated account of what went wrong, including its own mistakes. Whether to stay is about your app: who pays for it, what is in it, and who asks you where it lives.
Can I move only the database and keep building in Lovable?
Yes. Lovable's guide covers moving the backend to your own Supabase project while the frontend stays on Lovable or moves separately. There is no one-click switch; you export the data, apply the migrations at the destination, restore, and point the app at the new backend.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.