Lovable-Apps: Pässe, Chats und Zahlungsdaten ohne Login einsehbar

Worum es geht

Lovable ist eine der bekanntesten Plattformen für sogenanntes Vibe Coding. Dabei beschreibt man in normaler Sprache, welche App man haben möchte, und eine KI schreibt den Code, hängt eine Datenbank an und stellt die Anwendung online. Programmierkenntnisse braucht man laut Lovables Werbung nicht. Genau das wird jetzt zum Problem: Tausende so gebaute Apps lassen Fremde ohne Anmeldung in ihre Datenbanken schauen.

Das zeigt eine Untersuchung des deutschen Sicherheitsunternehmens Crissy Field, die gemeinsam mit dem Handelsblatt entstanden ist. Laut Startup Fortune wurde zuerst am 2. November darüber berichtet. In den offen zugänglichen Datenbanken fanden die Forscher Passnummern, Zahlungsinformationen, gültige Ticketcodes und private Chatnachrichten. Ob jemand die Daten missbraucht hat, konnte Crissy Field nicht feststellen. Welche Apps betroffen sind und wie genau der Zugriff funktionierte, veröffentlicht das Unternehmen nicht, damit niemand die Lücken gezielt ausnutzen kann.

Die Zahlen der Untersuchung

Die Forscher haben über Common Crawl gesucht, ein frei zugängliches Archiv, das große Teile des Internets regelmäßig speichert. Darin fanden sie 159.041 Lovable-Projekte, die zwischen Dezember 2025 und September 2026 online waren. Die weiteren Schritte:

Dass eine Seite beim Laden Daten mitschickt, ist für sich genommen noch kein Fehler. Ein Restaurant will seine Speisekarte schließlich öffentlich zeigen. Kritisch wurde es bei den nächsten Schritten: Mit weiteren reinen Leseanfragen, für die sie denselben Schlüssel nutzten, den die Seite ohnehin an jeden Besucher schickt, kamen die Forscher an deutlich mehr Inhalte. Auf 7.403 Websites, also 30 Prozent der genauer untersuchten Seiten, fanden sie Tabellen mit E-Mail-Adressen.

Crissy Field schränkt selbst ein: Diese 30 Prozent sind keine bestätigte Leak-Rate. Manche E-Mail-Adressen sind öffentliche Kontaktadressen oder Testdaten. Außerdem ist die Stichprobe aus Common Crawl nicht repräsentativ für alle Lovable-Apps.

Was konkret offen lag

Die Beispiele aus dem Bericht zeigen, wie heikel die Daten zum Teil sind:

• Ausweisdaten: Ein Dienstleister legte mehr als 1.000 Datensätze mit Passnummern, Ablaufdaten und Staatsangehörigkeiten offen.
• Community: Ein deutsches Lifestyle-Forum zeigte mehr als 80.000 Profile mit vollem Namen, E-Mail-Adresse, Geburtsdatum und Geschlecht, dazu mehr als 200.000 Chatnachrichten.
• Tickets und Essen: Mehrere Eventveranstalter und Restaurants machten Zehntausende Bestellungen zugänglich, mit Telefonnummern, Adressen, Zahlungsinformationen und gültigen Ticketcodes.
• Hausverwaltung: Eine Immobilienfirma legte KI-generierte Zusammenfassungen interner Mails über Mieter, Eigentümer und Geschäftspartner offen.

Dazu kamen Zehntausende Verträge, Rechnungen, private Fotoalben und interne WhatsApp-Verläufe. In einem Fall waren 280.000 Mails an Kunden eines Anbieters einsehbar. Laut Startup Fortune handelte es sich dabei um ein Projekt nach Art eines CRM, also einer Software zur Kundenverwaltung. Neben den Mails lagen dort auch Einträge von Wartelisten und Support-Tickets offen.

Wo die Lücke steckt

Niemand musste bei Lovable oder Supabase einbrechen. Supabase ist ein Datenbankdienst, den Lovable standardmäßig an die Apps anbindet. Apps, die Supabase nutzen, schicken im Browser einen Schlüssel mit, den sogenannten „anon key“. Der ist absichtlich öffentlich. Die eigentliche Absicherung übernehmen Zugriffsregeln in der Datenbank, die Row Level Security (RLS). Diese Regeln legen Zeile für Zeile fest, wer welchen Datensatz sehen darf, zum Beispiel nur die eigenen Bestellungen. Man kann sich das wie ein Mehrfamilienhaus vorstellen: Die Haustür steht für alle offen, abgeschlossen sind nur die Wohnungstüren. Fehlen die Schlösser oder sind sie zu großzügig eingestellt, kann jeder mit dem Schlüssel alle Tabellen lesen.

RLS muss aktiv eingeschaltet und richtig konfiguriert werden. Startup Fortune deutet die Ergebnisse so, dass der KI-Agent ohne gezielte Anweisung funktionierende Apps baut, ohne diese Schlösser anzubringen. Gleichzeitig gibt Supabase dem öffentlichen Schlüssel weitreichende Leserechte, solange niemand sie einschränkt.

Laut Crissy Field folgen die Datenbankanbindungen bei Lovable wiederkehrenden Mustern. Wer eine Fehlkonfiguration in einer App findet, kann deshalb mit wenig Aufwand Tausende andere Apps nach demselben Fehler absuchen. Startup Fortune drückt es so aus: Ein einzelnes vergessenes Häkchen ist ein Bug. Taucht dasselbe vergessene Häkchen in Tausenden unabhängig gebauten Apps auf, ist es ein Muster, das von dem Werkzeug stammt, das den Code schreibt, den keiner der Nutzer liest.

Die Forscher weisen außerdem auf einen Widerspruch hin. Lovable wirbt damit, dass man für den App-Bau kein technisches Wissen braucht. In den Nutzungsbedingungen liegt die Verantwortung für Sicherheit und Datenschutz aber bei den Kunden. Gerade Laien erkennen solche Lücken kaum. Crissy Field rät deshalb, die Zugriffsrechte vor dem Start mit echten Daten von Fachleuten prüfen zu lassen.

Lovables Reaktion und frühere Vorfälle

Lovable sieht laut Cybernews keine Schwachstelle in seiner KI. Es handle sich um ein bekanntes, branchenweites Konfigurationsproblem bei Supabase. Ganz falsch ist das nicht, denn das Phänomen betrifft nicht nur Lovable. Das Sicherheitsunternehmen UpGuard hat rund 300.000 mit Supabase verbundene Domains untersucht und auf 16.326 Datenbanken lesbare Tabellen gefunden. Mehr als die Hälfte davon enthielt Hinweise auf personenbezogene Daten.

Lovable bietet inzwischen einen Security Scan und einen KI-Sicherheitsprüfer an, die Apps vor der Veröffentlichung auf solche Fehler prüfen. Eingeführt wurden beide, nachdem 2025 eine ähnliche Lücke in Lovable-Apps unter der Kennung CVE-2025-48757 öffentlich geworden war. CVE-Nummern sind eine weltweit genutzte Kennzeichnung für bekannte Sicherheitslücken. Startup Fortune merkt kritisch an, dass die neue Untersuchung Apps betrifft, die lange nach Einführung dieser Werkzeuge entstanden sind. Die Prüfungen erwischen also offenbar nicht genug Fehler. Das Magazin schreibt dazu:

Eine Warnung, die trotzdem 7.403 Seiten mit offenen Datenbanken online gehen lässt, ist kein Schutz. Sie ist ein Haftungsausschluss.

Ein Problem der ganzen Branche

Lovable ist der Star der Vibe-Coding-Welle. Das Stockholmer Startup wurde zuletzt mit 13,3 Milliarden Dollar (rund 12 Milliarden Euro) bewertet und kam im Frühjahr auf 400 Millionen Dollar (rund 360 Millionen Euro) Jahresumsatz. Erst vor Kurzem musste das Unternehmen erklären, warum es mit einer von Hand gebauten Designer-Website für seine KI geworben hatte.

Die Konkurrenz steht vor derselben Frage. Bolt.new und Vercels v0 binden ebenfalls Supabase als Datenbank an. Replit und Cursor erzeugen auf Zuruf komplette Backends, also den unsichtbaren Serverteil einer App mit Datenbank und Logik. Supabase selbst profitiert von der Welle und hat erst vor wenigen Wochen 150 Millionen Dollar (rund 135 Millionen Euro) eingesammelt, um seine Datenbank fit für KI-Agenten zu machen.

Einordnung

Die Untersuchung zeigt eine bekannte Schwäche von KI-Werkzeugen, die Software „auf Zuruf“ bauen: Sie liefern, was man verlangt, und das ist meist eine App, die funktioniert. Eine sichere App ist es nicht automatisch. Wer nicht weiß, dass eine Datenbank Zugriffsregeln braucht, merkt auch nicht, wenn sie fehlen. Den Schaden haben dabei vor allem die Nutzer dieser Apps: Kunden, die ein Ticket gekauft, Essen bestellt oder sich in einem Forum angemeldet haben, ohne zu ahnen, wie die Seite gebaut wurde.

Die Schuldfrage ist umstritten. Lovable verweist auf Supabase und auf die Verantwortung der App-Bauer. Kritiker wie Startup Fortune sehen die Plattform in der Pflicht, weil sie den Code schreibt und Laien gezielt Sicherheit ohne Fachwissen verspricht. Offen bleibt, wie viele der gefundenen Daten echt und wie viele bloß Testdaten sind. Crissy Field betont selbst, dass die Zahlen keine bestätigte Leak-Rate darstellen. Unklar ist auch, ob Unbefugte die Lücken schon ausgenutzt haben.

Für alle, die selbst mit Lovable, Bolt.new, v0 oder ähnlichen Werkzeugen Apps bauen, ist die Konsequenz klar: Bevor echte Kundendaten in die App kommen, sollte jemand mit Fachwissen die Zugriffsregeln der Datenbank prüfen. Der eingebaute Sicherheitsscan allein reicht nach diesen Ergebnissen offenbar nicht.