The Controller Is Whoever Typed the Prompt

2 November 2026. Handelsblatt and the Hamburg security firm Crissy Field publish what they found in apps built with Lovable: passport numbers, payment details, more than 200'000 chat messages. No login required.

14 November 2026. The report reaches the front page of Hacker News. Someone asks whether any of it was filed with a data protection authority. The report’s author answers: “No, it has not been reported to the authorities.”

Twelve days, thousands of readable databases, and no regulator on the record.

The researchers had no duty to report. The duty belongs to the operators - potentially thousands of them, wherever the GDPR applies - and most probably have no idea they hold it.

159'041 Projects, a Key in Every Page

Crissy Field pulled Lovable projects out of Common Crawl, the open web archive, for December 2025 to September 2026. The funnel:

• 159'041 Lovable projects identified
• 34'545 of them on Supabase, a hosted Postgres service and, by the researchers’ estimate, the most common database behind Lovable apps
• 24'664 sent database records to the browser on page load - no login, no interaction
• 7'403 of those (30%) returned records with email addresses once the researchers asked for more, across 10'560 tables

The authors are careful, so I will be too. Records on page load are not a flaw in themselves; a restaurant menu is supposed to be public. An email address can be test data or a contact page, and the method misses personal records that carry no email address at all. The report says the 30% figure “should therefore not be read as a confirmed data leak rate” and that a Common Crawl sample does not represent all Lovable apps. Lovable reports more than 50 million projects; the sample is ~0.3% of that.

What the report does not hedge are the individual cases:

• Identity documents: a service provider exposed more than 1'000 records with passport numbers, expiry dates and nationalities
• A German lifestyle forum: more than 80'000 profiles with names, email addresses and dates of birth, plus more than 200'000 chat messages
• Mail: in one case, 280'000 emails sent to a provider’s customers
• The rest: ticket codes, payment information, summaries of internal emails about tenants, contracts, invoices, photo albums

No exploit was involved. The key a Supabase app ships to the browser is meant to be public. The only thing between a visitor and a table is Row Level Security (RLS), the per-row access rules inside the database. Rules missing or too generous, and the public key reads everything. The author again: “no advanced hacking techniques were used.”

Whether anyone misused the data, the researchers could not establish.

Disputed by the Supplier

None of this is new.

On 21 August 2025 the NVD entry for that CVE gained a note worth reading twice: “this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.”

In November 2026 Lovable’s answer, as Cybernews reports it, is that this is “a known, industry-wide configuration problem around the use of Supabase”. LILOX’s summary of the Handelsblatt article attributes the line to Lovable’s head of security, Igor Andriushchenko, and adds a second one: “Security is a shared responsibility”.

UpGuard’s numbers back the first line. This is not a Lovable-only problem.

The second line is a shift. In fifteen months the customer’s responsibility became a shared one. Lovable’s security docs have not caught up: “You are responsible for ensuring that your app meets the security requirements appropriate for its use case”.

In 2023 I wrote that nocode builders “may also overlook important concepts like performance optimization, security, and scalability”. I was worried about their careers. I should have been worried about their customers’ passports.

“Publish Anyway”

Two changes are on the table. Read both.

Supabase. Announced on 28 April 2026: new tables need an explicit grant before the Data API can see them. Default for new projects from 30 May, scheduled for all existing projects on 30 October. The reasoning is candid: “agents, CLI scripts, and AI platforms create tables too, and many of those operations do not have a human reviewing the diff.”

Then the scope: “Existing tables are not affected in your project, they keep their current grants and stay reachable.”

So the 30 October step changes nothing for a table that already exists - which is every table in the scan. Projects created after 30 May were already under the new default; the report does not say how many of the exposed ones those were. And when I read Supabase’s API security page on 14 November, it still described the old default for existing projects. Either the rollout or the documentation is running late.

For new tables, the error message contains the exact GRANT statement to run, so that “an agent can self-correct”. An agent that self-corrects by pasting the hint is back at a reachable table protected by RLS alone. Supabase has added RLS by default in its Table Editor, an exposure badge and Security Advisor warnings. Those help a human in the dashboard. UpGuard’s point is that agents create tables through the API, where RLS is still not on by default.

The exposed Ollama servers I wrote about last year at least had to be opened by an administrator. Supabase ran the opposite default, and users were asking how to switch it off in December 2021: “the supabaseKey needed for creating the client on the frontend also grants users access to the database by default.”

Lovable. A Quick scan runs on every publish and flags “tables without per-record access control” and “access rules that let everyone through”. There is an auto-fix for common RLS misconfigurations. That is more than the 2025 scanner, which Palmer said “merely checks for the existence of any RLS policy, not its correctness”.

The result is a single line in the publish dialog, and “Findings do not block publishing by default”.

According to LILOX’s summary of the Handelsblatt piece, Lovable promised a better security experience for non-technical users in November 2026. What arrived on 12 November: a project on Lovable’s built-in backend with unresolved critical findings now gets a review dialog first. The options are to open the findings, to have Lovable fix them, or to “publish anyway”.

Publish anyway.

The dialog covers the built-in backend, which Crissy Field did not examine; an app on a customer’s own Supabase project - the kind in the scan - gets the single line. Blocking publication outright is a workspace setting that, per the docs, only new Enterprise workspaces start with.

Who the GDPR Names

Under the GDPR, the controller is whoever decides why and how personal data is processed. For a booking tool somebody prompted into existence over a weekend, that is the somebody - or, if they built it at work, their employer. Lovable’s terms say so: “You are responsible for your Customer Data and for the applications and projects you build”. Its Data Processing Agreement (DPA), where one applies: “the Customer acts as a controller and Lovable acts as a processor.” Supabase’s DPA says the same about itself.

The report’s author, more bluntly: “It’s not Lovable that can be sued.” That overstates it - Art. 82(2) keeps a processor liable for its own failures - but it points the right way.

Read Art. 25(2) with the Supabase default in mind. Measures “shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.” The individual is the person the data is about.

It reads like the bug report. It binds the controller. The European Data Protection Board’s (EDPB) guidelines on Art. 25 say in so many words that producers are “not directly addressed”.

On Art. 25, the company that chose the default gets an encouragement. The person who typed the prompt gets the obligation.

Four consequences:

• Open and read is a breach. Art. 4(12) covers “unauthorised disclosure of, or access to” personal data. Misuse is not part of the definition; access is. For a flaw nobody used, the EDPB’s own example in its breach guidelines (Annex B, case vii) says a notifiable breach “may not have occurred”, though it is “likely to be recordable”. That exit is closed here: the researchers retrieved up to the first page of a table to classify it. Hacker News argued about proportionality. The author says a data protection lawyer assisted and the classification ran on local models; the IT law expert who reviewed the method for Handelsblatt found it used only the access the sites give every visitor. For the operator the result is the same: someone without authorisation read the table.
• The clock starts with knowledge, not with damage. The same guidelines set awareness at “a reasonable degree of certainty”, allow “a short period of investigation” after a tip-off, and treat a controller as aware, “in principle”, once its processor has informed it. Handelsblatt got its first tips in mid-August, checked them and put them to Lovable. The researchers say they gave Lovable the full dataset. According to LILOX’s summary, Lovable says it had warned the operators in three of the reported cases, who did not act. If so, those three will struggle to argue they did not know.
• Passports almost certainly mean telling people. Art. 34 applies when the risk is high. The guidelines list “identity documents” next to health and financial data as breaches that “can all cause harm on their own”. Lovable’s terms, for their part, rule out “government identifiers” and “payment card data” unless a plan or separate agreement expressly permits them: the standard service is “not designed to serve as a system of record” for such data.
• The paperwork may be missing too. Art. 28(3) requires a contract with every processor. Supabase’s DPA is part of its terms of service. Lovable’s DPA page opens: “If you’re on a Business or Enterprise plan, your usage includes our Data Processing Agreement (DPA).” It does not say what the other plans include.

Fines under Arts. 25, 28 and 32 to 34 run up to €10 million or, for an undertaking, 2% of worldwide annual turnover, whichever is higher. Add the Art. 5(1)(f) security principle and the ceiling doubles. For a one-person operator those numbers are theatre.

The civil side is not. In C-340/21 the Court of Justice held that it is for the controller to prove its protective measures were appropriate, and that the fear of misuse, if well founded, is capable in itself of constituting non-material damage.

“Anyone with a browser could read it” is a hard place to start that proof.

Why No Regulator Has Spoken

I went looking. Searches for a statement, an investigation or a fine from IMY or the German authorities: nothing. The news page of IMY, the Swedish authority that Lovable’s privacy policy names as its lead supervisory authority: nothing on Lovable as of 14 November.

flowchart LR
    R["Crissy Field and Handelsblatt<br>find the open tables"] -->|"full dataset (per researchers)"| L["Lovable<br>toolmaker, host, sometimes processor"]
    R -.->|"not reported"| A["Data protection<br>authorities"]
    L -->|"warned in 3 cases (own account)"| O["App operators<br>the controllers"]
    O -.->|"Art. 33 - none known"| A
    O -.->|"Art. 34 - none known"| P["People in the tables"]

The structure explains the silence:

• The researchers did not report. A deliberate decision, in a project assisted by a data protection lawyer, to hand the dataset to Lovable so it could contact its customers.
• Lovable is not the controller. Whether, and how fast, it told the remaining customers is not public.
• Each operator answers to their own authority. That is Art. 55. Subtract the test data, the hobby projects and the operators the GDPR does not reach, and a long list of small files in many member states remains. I don’t know an authority staffed for that.
• Notifications are not published. Some operators may have filed quietly. Nobody has said so.

My expectation: complaint-driven cases against individual operators, starting with whoever held the passports. No single big decision.

Of course, things might go differently.

What to Do This Week

You probably don’t build on Lovable. Somebody in marketing, events or HR might. In May I wrote that “if the person responsible can’t verify what the AI proposed, you don’t have a deployment strategy. You have a prayer.” The GDPR adds a correction: the party responsible is not your colleague. It is the organisation. Yours.

1. Find them. Proxy and DNS resolver logs for lovable.app and supabase.co, expense claims for both vendors. Then ask. A vibe-coded app run by a business unit is shadow IT with a customer table.
2. Test signed-out. Private window, network tab, look for calls to supabase.co/rest/v1/. Then request your own tables with the key the page ships. Your app, your data, your right to test.
3. Fix both layers on every table. RLS enabled, policies that actually restrict, and grants only for the roles that need them. The 30 October change does nothing for the tables you already have.
4. If a table was open, you have a breach to assess. Document it - Art. 33(5) requires that even when you don’t notify. Count the 72 hours from the moment you knew. With passports or chat logs, “unlikely to result in a risk” is a hard argument to make.
5. Check the contract. Which plan, which DPA, which region. For Lovable, the terms name Lovable Labs Incorporated as your counterparty, under Delaware law.
6. Put it in the supplier register. For entities under NIS2, Art. 21(2)(d) covers supply chain security and (e) security in the acquisition and development of systems. Then ask your suppliers the question from step 1.

TL;DR

• Crissy Field scanned 159'041 Lovable projects: 24'664 served database records without login, 7'403 returned email addresses. Not a confirmed leak rate, but the passports and 200'000+ chat messages are in the report without a caveat.
• Known since March 2025: CVE-2025-48757, CVSS 9.3. Lovable’s note in the NVD: the customer’s responsibility.
• Supabase’s change covers new tables only. Lovable’s November dialog offers “publish anyway”.
• Under the GDPR the operator is the controller - the builder, or their employer. Art. 25(2) describes the bug and binds the operator; producers are merely “encouraged”.
• A table that was open and read is a breach; misuse need not be proven. 72 hours from awareness.
• Twelve days on: not reported to any authority by the researchers, and nothing from IMY or the German authorities that I could find.

The pitch was that anyone can build software now. The GDPR’s reply is that anyone can be a controller.

Figures are from the Crissy Field report as it stood on 14 November 2026; it carries updated numbers compared with the Handelsblatt article of 2 November. Handelsblatt is paywalled after its opening paragraphs. Lovable’s statements - the “industry-wide” line, “shared responsibility”, the three warned operators and the November promise - are taken from Cybernews and from LILOX’s English summary of the Handelsblatt article, not from the article itself. The regulator check was a search for statements from IMY and the German authorities plus IMY’s news page, on 14 November 2026; silence proves nothing. Lovable’s terms, DPA, privacy policy, docs and changelog and Supabase’s changelog and docs were read on the same day. This is a reading of the GDPR, not legal advice. Research and drafting were done with AI assistance; the reading of the texts and the opinions are human.