Aufregung um die schwedische Vibe-Coding Plattform Lovable, denen ein Datenschutzvorfall vorgeworfen wird. Ein Benutzer hatte sich ein neues Konto bei der Plattform zugelegt und staunte nicht schlecht, als er auf Daten anderer Benutzer zugreifen konnte. Lovable bestreitet aber nach meinen Information einen Datenschutzvorfall.
Wer oder was ist Lovable?
Lovable ist ein schwedisches Startup im Bereich künstliche Intelligenz, das die Softwareentwicklung optimiert. Es ist Europas neuestes Einhorn, ich habe Bewertungen von 1,8 Milliarden US-Dollar gesehen.
Das Konzept von Lovable basiert auf einer auf KI basierenden Vibe Coding Plattform. Mit Lovable AI sollen sich, so der Anbieter, leistungsstarke KI-Funktionen ganz einfach und schnell in ein App integrieren lassen. So sollen Entwickler sofort damit beginnen können, intelligentere und ansprechendere Apps zu entwickeln.
Eine Meldung über einen Sicherheitsvorfall
Mir ist die Tage nachfolgender Tweet untergekommen, der Lovable ein Datenschutzproblem mit seinem KI-App-Baukasten vorgeworfen wird. Millionen von Nutzern seien von einer massiven Datenpanne betroffen, die alle Projekte betrifft, die vor dem Patch im November 2025 erstellt wurden.
Das Problem: Jedes kostenlose Konto bei Lovable kann über fünf nicht authentifizierte API-Aufrufe auf den Quellcode anderer Nutzer, Datenbank-Zugangsdaten, KI-Chat-Verläufe und echte Kundendaten zugreifen. Der Fehler sei vor 48 Tagen auf HackerOne gemeldet worden, heißt es und sei nach wie vor offen.
Die Sicherheitslücke betrifft laut Tweet die Autorisierung auf Objektebene. Die API von Lovable überprüfe zwar Firebase-Authentifizierungstoken, kontrolliere jedoch nicht, ob der anfragende Nutzer tatsächlich Eigentümer des Projekts ist. Jeder authentifizierte Nutzer kann jedes beliebige Projekt abfragen.
Der Nutzer mit dem X-Handle @weezerOsint hat ein kostenloses Konto erstellt und auf den vollständigen Quellcode-Baum eines anderen Nutzers zugreifen können. Dies habe auch ein Admin-Panel von "Connected Women in AI" umfasst. Dieses wurde von einer dänischen, gemeinnützige Organisation, erstellt. Das Projekt sei zuletzt vor 10 Tagen bearbeitet worden und verzeichnete in 2026 insgesamt 3.703 Bearbeitungen heißt es. Es handelt sich also um ein aktives Projekt.
Der Quellcode habe fest codierte Supabase-Anmeldedaten (SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_SERVICE_ROLE_KEY) enthalten. Der fremde Entwickler konnte anhand dieser Daten eine Abfrage in der Datenbank durchführen und erhielt echte Namen, echte Unternehmensinformationen und echte LinkedIn-Profile als Ergebnis. Darunter waren auch Referenten von Accenture Dänemark und der Copenhagen Business School, also keine eine Testdaten, heißt es im Tweet.
Zu den betroffenen Endpunkten gehören /projects/{id}/*, /git/files, /git/file und /documents. Bei Projekten, die vor dem Patch erstellt wurden, geben alle den Status 200 OK zurück.
Jede KI-Konversation wird gespeichert und ist über denselben Fehlerzugang einsehbar. Entwickler besprechen Datenbankschemata, fügen Fehlerprotokolle ein, geben Zugangsdaten weiter und gehen mit der KI die Geschäftslogik durch. All dies sei lesbar, heißt es im Tweet. Mitarbeiter von Nvidia, Microsoft, Uber und Spotify haben alle Lovable-Konten. Die Sicherheitslücke beschränkt sich nicht auf Hobbyprojekte.
Lovable hat neue Projekte laut Tweet gepatcht, bestehende Projekte jedoch ungeschützt gelassen. Ein im April 2026 erstelltes Projekt gibt 403 Forbidden zurück. Das ältere Projekt desselben Entwicklers – gleiche API, gleicher Endpunkt, gleiches kostenloses Konto, gleiche Sitzung – gibt 200 OK mit dem vollständigen Quellcode-Baum zurück.
Der erste HackerOne-Bericht (#3583821) sei am 3. März 2026 eingereicht worden. Lovable habe diesen geprüft, Eigentumsprüfungen für neue Projekte eingeführt und alle bestehenden Projekte weit offen gelassen.
Das sagt Lovable dazu
In nachfolgendem Tweet auf X bestreitet Lovable einen Datenschutzvorfall auf seiner Plattform. Man sei auf Bedenken hinsichtlich der Sichtbarkeit von Chat-Nachrichten und Code in Lovable-Projekten mit öffentlichen Sichtbarkeitseinstellungen aufmerksam gemacht worden. "Um es klar zu sagen: Es gab keinen Datenleck." heißt es, lediglich die Dokumentation darüber, was "öffentlich" bedeutet, sei unklar gewesen, was als Versäumnis eingeräumt wurde.
Insbesondere bei öffentlichen Projekten seien Chat-Nachrichten früher sichtbar gewesen, das sei nun nicht mehr möglich. Was den Code öffentlicher Projekte betrifft: Dies sei beabsichtigt. Lovable habe mit verschiedenen Benutzeroberflächen experimentiert, um die Build-Historie in öffentlichen Projekten darzustellen, aber das Kernverhalten sei konsistent und beabsichtigt. Wichtig für Unternehmenskunden sei, dass die Möglichkeit, die Sichtbarkeit für neue Projekte auf "öffentlich" zu setzen, seit dem 25. Mai 2025 deaktiviert ist.
In einem zweiten Statement auf X musste Lovable aber zurück rudern. Das Problem seien öffentliche Projekte, und Benutzer, die nicht wissen, was das sei. Die öffentlichen Projekte wurden eingerichtet, damit die Leute stöbern und sehen könnten, was möglich ist. Wenn man ein Projekt auf GitHub erstellt, kann man es privat oder öffentlich machen. Bei Lovable sei dies genau so – was aber den Benutzern wohl nicht klar war. Uns so kommt es, dass eine Menge "Vibe-Coding-Projekte" (wo die Nutzer keine Ahnung haben, was sie eigentlich treiben), mit allen privaten Daten, Zugangsdaten etc. öffentlich einsehbar sind – was soll schon groß passieren, wenn alle Welt Vibe-Coding betreibt – ist ja schließlich cool und kann jeder probieren.
Mit der Zeit wurde den Betreibern von Lovable aber klar, dass dies verwirrend war und was sie angerichtet hatten. Laut Tweet dachten viele Nutzer, dass "öffentlich" lediglich bedeute, dass andere ihre veröffentlichte App sehen könnten, nicht aber den Chat eines unveröffentlichten Projekts. Hinzu kommt das Eingeständnis, dass Nutzer in der kostenlosen Stufe ursprünglich keine privaten Projekte erstellen konnten. Dazu mussten sie auf einen kostenpflichtigen Tarif upgraden.
Im Mai 2025 wurde dies geändert und Nutzer der kostenlosen Stufe konnten ihre Projekte nun privat machen. Für Unternehmenskunden wurde die Einstellung für die öffentliche Sichtbarkeit komplett deaktiviert. Und im Dezember 2025 stellten die Betreiber die Projektsichtbarkeit in allen Tarifen standardmäßig auf "privat" um. Außerdem wurde die API rückwirkend angepasst, sodass auf Chats öffentlicher Projekte unter keinen Umständen mehr zugegriffen werden konnte. Leider haben die Betreiber im Februar 2026 bei der Vereinheitlichung der Berechtigungen im Backend versehentlich den Zugriff wieder aktiviert. Also: Works as designed und we are sorry, dass wir offen wie ein Scheunentor waren, wer ist auch so naiv, da seine privaten Sachen rein zu nageln … das komplette Statement ist nachfolgend zu lesen.
We're sorry our initial statement didn't properly address our mistake. Here's what a public project on Lovable means, and how we got to where we are today: In the early days, people didn't know what Lovable was capable of. So we wanted to make it easy to explore what others were building, as a way to spark ideas and lower the barrier to getting started. Like scrolling GitHub or Dribbble: you browse projects to see what's possible, then go build your own. When you create a project on GitHub, you can make it private or public. Lovable worked the same. Users had a "Public" or "Private" option right in the chatbox. A public project meant the entire project was public, both chat and code. "Just like a public project on GitHub," we thought. Over time, we realized this was confusing. Many users thought "public" just meant others could see their published app, not the chat of an unpublished project. That's reasonable. On the free tier, users originally couldn't create private projects. They had to upgrade to a paid plan to do so. In May 2025, we changed this: users on the free tier could choose to make their projects private. For enterprise customers, the public visibility setting was disabled altogether. And in December 2025, we switched to private by default across all tiers. We also retroactively patched our API so public project chats couldn't be accessed, no matter what. Unfortunately, in February, while unifying permissions in our backend, we accidentally re-enabled access to chats on public projects. This was reported through our vulnerability disclosure program (via HackerOne). Unfortunately, the reports were closed without escalation because our HackerOne partners thought that seeing public projects' chats was the intended behaviour. Upon learning this, we immediately reverted the change to make all public projects' chats private again. We appreciate the researchers who uncovered this. We understand that pointing to documentation issues alone was not enough here. We'll do better.
Ergänzung: The Register hat den Sachverhalt ebenfalls in diesem Artikel aufgegriffen.
MVP: 2013 – 2016
