An IT security expert has examined more than 140,000 German-language websites built with the AI builder Lovable. On around 15 percent of them he was able to view data, including email addresses and ID data. The cause is usually a missing access rule in the database. Anyone who runs such an app is responsible under data protection law and should check it now.
What happened at Lovable?
On tens of thousands of Lovable sites, user data could be retrieved through a publicly visible key. This is reported by Handelsblatt on 2 November 2026, based on an analysis by Thomas Jansen, founder of the security company Crissyfield. According to the report, the gap had existed for at least a year.
By his own account, Jansen examined more than 140,000 German-language Lovable websites and was able to view data on about 15 percent of them. More than 20,000 Lovable users are said to be affected. Among the findings was a site for US visa applications with names, dates of birth and passport numbers, at times even with photos of ID documents. On a radio website, profiles of registered users with names and email addresses lay exposed. For the entire analysis, Jansen needed about five hours, thanks to AI support, by his own account.
The scale of the problem is explained by the platform’s reach. According to Handelsblatt, Lovable reports more than 50 million projects delivered and 1.2 million new ones per week. The Swedish company was valued at 13.3 billion US dollars in a funding round in August 2026. Many users build forms, customer portals and internal tools there without programming themselves.
Why is data exposed when nobody is hacking?
The data is exposed because the app itself hands it to every visitor. Lovable apps usually store their data with Supabase, a provider of databases and backend services. The browser accesses the database with a public key, the so-called anon key. It is deliberately part of the source code of every site.
That is intended and secure in itself. The public key is meant to release only what anyone may see anyway, such as texts or product images. What it may read beyond that is regulated by a second layer, Row Level Security (RLS). These are rules per table and row, for example “every user sees only their own entry”. If these rules are missing or worded too openly, the database hands everything to the public key.
The ethical hacker and IT law expert Dirk Koch reviewed Jansen’s approach technically and legally. He concludes that Jansen only used the access that the sites themselves offer to every visitor. That is what makes the gap so delicate. It takes no special knowledge, only a browser and a little curiosity. With AI tools, the search can also be automated on a large scale.
Anyone who builds without programming knowledge rarely sees this problem. The app works, forms save, logins succeed. That a stranger can retrieve the same data without a login never shows up in normal use.
Is this only a Lovable problem?
No, the pattern occurs wherever apps are built quickly with Supabase in the background. Lovable’s head of security Igor Andriushchenko tells Handelsblatt that it is a known, industry-wide configuration problem. Several independent analyses support this assessment.
The security company UpGuard examined around 300,000 domains with indications of Supabase in autumn 2026. On 16,326 databases, tables were readable from outside. According to UpGuard, more than half of these cases contained indications of personal data. The report also describes a technical reason. In the table editor, RLS is enabled by default, but not for tables created via SQL or automatically, for instance by AI tools.
The provider Symbiotic Security scanned 1,072 Supabase-based apps in June 2026 and reported at least one finding for 98 percent of them, and a critical one for 16 percent. The figure comes from a security vendor’s own study and should be viewed accordingly.
Even independently of Supabase, AI-generated code is often insecure. Veracode’s GenAI Code Security Report from July 2025 tested more than 100 language models with 80 programming tasks. In 45 percent of cases, the generated code contained a vulnerability from the OWASP Top 10. Code that works has therefore not yet been checked.
How much pressure this creates was shown in October 2026 by a critical vulnerability in PHP. On 21 October, the digital association Bitkom expected AI to speed up the search for vulnerable systems many times over.
What have Lovable and Supabase changed since?
Both providers have tightened their defaults, but responsibility still lies with the operator of the app. The gap itself has been known since spring 2025. The security researcher Matt Palmer reported it to Lovable in March 2025. In May 2025 it was published as CVE-2025-48757. A follow-up scan at the time found 303 unprotected endpoints in 170 projects. Lovable disputes the CVE and points to customers’ responsibility for their data.
In April 2025, Lovable introduced a security scan with Lovable 2.0. According to the analysis by Superblocks, it initially checked only whether access rules exist, not whether they work. Today, automatic checks run on every publication, and a deep scan can be started manually. In its own documentation, Lovable states that the scan is not a security guarantee and that an additional professional review is recommended for sensitive data. According to Handelsblatt, the company announces an improved security experience for non-technical users for November 2026.
Supabase has changed its default. Since 30 May 2026, new tables in new projects are no longer automatically reachable through the public interface. Since 30 October 2026, this applies to all existing projects. That helps with new tables. Tables that are already exposed with rules that are too open remain unaffected.
Handelsblatt quotes Lovable’s head of security with the sentence “Security is a shared responsibility”. For companies, that means in concrete terms that they cannot rely on the builder. By its own account, Lovable had warned the operators in three cases reported by Handelsblatt, but they did not act.
What duties do you have if data was exposed?
If personal data was exposed, this can be a reportable data breach. The operator of the app is responsible, not the builder. The following overview is not a substitute for legal advice, but it shows the key points.
| Regulation | What applies |
|---|---|
| GDPR Art. 32 | Appropriate technical protective measures and their regular review |
| GDPR Art. 33 | Notification to the supervisory authority without undue delay and, where possible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk |
| GDPR Art. 34 | Informing the data subjects where a high risk is likely |
| GDPR Art. 83 | Infringements of Art. 32 to 34 can be fined up to 10 million euros or 2 percent of worldwide annual turnover, whichever is higher |
| Switzerland, FADP Art. 24 | Notification to the FDPIC (EDÖB) as soon as possible if a high risk is likely |
Whether a risk exists depends on the type of data. An open list of newsletter addresses weighs differently from passport numbers or health information. In any case, document the finding, close the gap immediately and, if in doubt, involve your data protection officer.
How do you check your own app?
You can carry out a first check in a short time using the built-in tools of Supabase and Lovable. It does not replace a penetration test, but it uncovers the most common errors.
- Take stock. List all Lovable or other AI-built apps that store data. This also includes contact forms, waiting lists and internal tools from departments.
- Open the Security Advisor. In the Supabase dashboard, the Security Advisor shows, among other things, tables without active access rules and rules that do not take effect.
- Read the rules. For each table, check who may read and write. A rule that gives the “anon” role unconditional read access opens the rows to all visitors.
- Start the deep scan in Lovable. Run the manual scan before every publication and fix critical findings before the site goes live.
- Check secret keys. Supabase’s secret service key must never appear in the code that reaches the browser.
- Involve specialists. As soon as ID, payment or health data is involved, a review by security specialists belongs before launch.
When does an AI builder fit, and when not?
An AI builder suits prototypes and sites without sensitive data. It suits poorly as soon as customers log in or leave personal details and nobody on the team understands the database. AI speeds up building considerably. What decides security is who checks the result before launch.
| Project | AI builder alone | What it additionally needs |
|---|---|---|
| Clickable prototype for internal alignment | Well suited | Do not use real customer data |
| Landing page without a form | Well suited | Check legal notice, privacy policy, load time |
| Landing page with a contact form | With caution | Check access rules, store data only as long as necessary |
| Customer portal with login | Not without review | Expert review of the database rules before launch |
| ID, payment or health data | Not suitable without expertise | Security review, data processing agreement, documentation |
For mid-sized companies, this is a budget question that is easy to calculate. A review before launch costs a fraction of what a data breach causes in notification effort, loss of trust and possible fines. Anyone who already has builder apps in use is best off starting with the applications that store customer data.
Frequently asked questions
Is Lovable insecure now?
Lovable itself has not been hacked. The gap arises in individual apps whose database rules are missing or too open. Because Lovable is aimed at people without programming knowledge, such errors often go unnoticed. With checked rules, a Lovable app can be run securely.
What is Row Level Security?
Row Level Security is a database feature that defines, per table and row, who may read or change data. One example is the rule that logged-in users see only their own entries. Without such rules, an app’s public key can retrieve all entries.
Is the anon key a password that has to be protected?
No, the anon key is deliberately public and is part of the code of every site. It is only safe if the database’s access rules are correct. The Supabase service key, on the other hand, must stay secret, because it bypasses all rules and must never end up in the browser.
Is retrieving the exposed data illegal?
In the assessment of IT law expert Dirk Koch in Handelsblatt, Jansen’s approach was not illegal, because he did not bypass any protection. This is an individual opinion on German law. For operators, it changes nothing. They remain responsible for protecting the data and, where applicable, must report a data breach.
Has the Supabase change solved the problem?
Only partly. Since 30 October 2026, new tables in all Supabase projects are no longer automatically exposed through the public interface. Tables that are already exposed and have rules that are too open remain reachable until the operator corrects them.
Do I have to report an open database to the authorities?
If personal data was exposed and this creates a risk for the data subjects, the GDPR requires a notification, where possible within 72 hours. In Switzerland, the notification to the FDPIC (EDÖB) applies where a high risk is likely. Review the individual case with your data protection officer.
Does this affect other AI builders too?
Yes, the pattern affects all tools that generate apps with Supabase or similar backends. UpGuard’s analysis found more than 16,000 Supabase databases with readable tables, built with various tools. What matters is the configuration of the database, not the name of the builder.
Sources
- Handelsblatt, “Experten finden Datenlücke bei beliebter KI-Coding-Plattform”, Lina Knees, 02.11.2026
- UpGuard, Everything Everywhere: Systemic Data Exposure in Supabase Apps, 2026: upguard.com
- Supabase Changelog, Tables not exposed to Data and GraphQL API automatically, 2026: supabase.com
- Superblocks, Lovable Vulnerabilities (CVE-2025-48757), 2025: superblocks.com
- Lovable, Lovable 2.0, April 2025: lovable.dev
- Lovable Docs, Security: docs.lovable.dev
- Symbiotic Security, Scan von 1.072 Apps, June 2026: symbioticsec.ai
- Veracode, GenAI Code Security Report, July 2025: veracode.com
- Bitkom zur PHP-Sicherheitslücke, 21.10.2026: bitkom.org
- Lovable-Bewertung, AI Magazine, 2026: aimagazine.com
- GDPR Art. 32, 33, 34, 83: dsgvo-gesetz.de
- EDÖB, Leitfaden zur Meldung von Datensicherheitsverletzungen nach Art. 24 DSG: edoeb.admin.ch
- Supabase Docs, Row Level Security und Database Linter: supabase.com/docs
