Lovable hat 76 Tage lang Quellcode und Secrets aus allen alten Projekten geleakt
Eine Backend-Regression bei Lovable legte Quellcode, Datenbank-Credentials und KI-Chatverläufe in sämtlichen vor November 2025 erstellten Projekten offen. Bug-Bounty-Meldungen gingen an Tag 19 ein – und wurden als vermeintliches Feature geschlossen. Eine Analyse der blinden Flecken in Lovables Bug-Bounty-Triage.
Am 20. April 2026 erstellte ein Sicherheitsforscher ein kostenloses Lovable-Konto, feuerte fünf API-Calls ab und las den Quellcode, die hartcodierten Datenbank-Credentials sowie den kompletten KI-Chatverlauf eines fremden Nutzers aus. Es war nicht sein eigenes Projekt, sondern irgendeines – Hauptsache, es wurde vor November 2025 erstellt. Genau diese Schwachstelle hatte er bereits 48 Tage zuvor über Lovables Bug-Bounty-Programm gemeldet. Dort wurde das Ticket jedoch als Duplikat eines vermeintlich „beabsichtigten Verhaltens“ geschlossen. Erst als er den funktionierenden Exploit auf X veröffentlichte, schob Lovable innerhalb von gut zwei Stunden einen Fix nach. Die eigentlich interessante Metrik in dieser Geschichte sind jedoch nicht die zwei Stunden. Es sind die 76 Tage davor – und der Grund, warum die Schwachstelle so lange unentdeckt blieb: Intern galt dieser Bug schlichtweg als Feature.
Wir bauen absichtlich verwundbare Referenz-Anwendungen, um zu verstehen, was diese Tools unter der Haube wirklich generieren. Kürzlich haben wir eine Lovable-App analysiert, die aufgrund von deaktiviertem RLS sämtliche Nutzerdaten preisgab. Damals lag der Fehler in dem Code, den Lovable für seine Nutzer erzeugt. Der aktuelle Fall ist jedoch ein Fehler in Lovable selbst – also in der Plattform, die den Code hostet. Das macht diesen Vorfall so brisant: Hier hat kein ahnungsloser Gründer etwas falsch konfiguriert. Der Anbieter hatte den korrekten Schutzmechanismus implementiert, ihn durch ein Update wieder ausgehebelt und anschließend exakt die Warnmeldungen ignoriert, die genau davor warnten.
Der Schutz existierte, bis ein Refactoring ihn aufhob
Lovable startete keineswegs ungeschützt. Cyber Kendras Zusammenfassung des Post-Mortem-Berichts skizziert die Chronologie: Im März 2025 sperrte Lovable den öffentlichen Zugriff auf die Chatverläufe von Projekten. Im November 2025 wurde dann “Private-by-default” auf sämtliche Abo-Modelle ausgeweitet. Zwei bewusste Schritte zur Härtung der Plattform, im Abstand eines knappen Jahres. Die Logik dahinter war solide, doch genau diese zeitliche Abfolge wurde zum Problem: Da “Private-by-default” erst im November eingeführt wurde, behielt jedes davor erstellte Projekt ein gesetztes Public-Flag. Der neue Standardwert griff nicht rückwirkend.
Am 3. Februar 2026 sollte eine Backend-Anpassung die Berechtigungsstruktur vereinheitlichen. Stattdessen öffnete sie versehentlich wieder den öffentlichen Zugriff auf Chatverläufe und Quellcode all dieser alten Projekte. In Lovables eigenen Worten: „A backend regression reintroduced access to chat histories on public projects“. Damit wurden genau die Schutzmaßnahmen wieder abgerissen, die das Team „deliberately put in place between March and November 2025“. Das ist der klassische Verlauf einer Regression: Ein Team konsolidiert zwei Berechtigungssysteme, doch der neue Code-Pfad enthält eine Lücke, die das alte System bereits geschlossen hatte.
Ein Negativtest, der sicherstellt, dass ein unautorisierter Nutzer einen 403-Fehler erhält, hätte dies sofort aufgedeckt. Das Problem: Solche Tests schreibt kaum jemand für Eigenschaften, die als grundlegende Architekturgegebenheiten wahrgenommen werden. Und selbst wenn Tests existieren, nutzen deren Fixtures meist die aktuellen Standardwerte. Sie testen also nur neue “Private-by-default”-Projekte und ignorieren die Altlasten der ehemals öffentlichen Kohorte. Der Schutz war ein Jahr alt, das Thema intern abgehakt. Das Refactoring riss die Lücke wieder auf – und die CI-Builds blieben grün.
Die API prüfte die Identität, aber nie den Besitz
Der Bug, den der Forscher hier ausnutzte, ist eine klassische Broken Object Level Authorization (BOLA) – der unangefochtene Spitzenreiter der OWASP API Security Top 10. Der API-Endpunkt für Projektnachrichten authentifizierte zwar den Aufrufer und stellte sicher, dass es sich um einen eingeloggten Nutzer handelte. Anschließend lieferte er jedoch munter jedes noch als öffentlich markierte Projekt mitsamt Quellcode und Chatverlauf aus. Es fand schlicht keine Prüfung statt, ob das angefragte Projekt dem Aufrufer überhaupt gehörte. Die Authentifizierung funktionierte also, die Autorisierung auf Objektebene fehlte komplett. Der Schutzmechanismus, den das Refactoring versehentlich entfernte, stammte aus dem März 2025. Er hatte dafür gesorgt, dass Chat und Quellcode selbst bei “öffentlichen” Projekten privat blieben. Ohne diesen Schutz bedeutete das Public-Flag plötzlich wieder: „lesbar für jeden registrierten Nutzer“.
Das erinnert stark an den rein kosmetischen Schutz, den wir bereits in einem anderen Fall dokumentiert haben: Das Frontend leitet zwar brav auf einen Login-Screen um, doch die API im Hintergrund antwortet ungeprüft auf jede Anfrage. Das wiederkehrende Muster: Das Sicherheitsnetz, das der Nutzer im UI sieht, ist nicht identisch mit dem, was das Backend tatsächlich erzwingt. In unserem früheren Beispiel betraf die Lücke eine isolierte App. Hier traf es die Control Plane der gesamten Plattform – der denkbar schlechteste Ort für eine solche Schwachstelle. Ein Projekt aus der Zeit vor November antwortete mit einem 200 OK und warf den kompletten Payload aus; ein neueres Projekt verweigerte den Zugriff mit einem 403. Diese scharfe Trennlinie entlang der November-Einführung von “Private-by-default” war der unmissverständliche Beweis: Hier handelte es sich um Altlasten in der Datenbank und nicht etwa um vergessene Einstellungen einzelner Entwickler. Der Leak basierte auf einem Public-Flag, das zum Zeitpunkt der Projekterstellung für eine bestimmte Kohorte gesetzt und vom neuen Standard nie bereinigt wurde.
Die Struktur des zurückgelieferten Payloads zeigt deutlich den Unterschied zwischen einem gewöhnlichen Quellcode-Leak und einem “Vibe-Coding”-Leak: Er enthielt nicht nur den generierten Code, sondern auch die darin hartcodierten Datenbank-Credentials, die zugehörigen Kundendaten und – besonders brisant – den vollständigen KI-Chatverlauf. Bei einer App, die primär durch Prompts generiert wird, ist der Chatverlauf kein belangloses Nebenprodukt. Er ist das eigentliche Build-Log. Entwickler fügen dort am laufenden Band Secrets ein: Connection-Strings, API-Keys von Drittanbietern, den kompletten Inhalt von .env-Dateien, um dem KI-Modell den Kontext zu liefern, oder Error-Logs mit Live-Tokens im Stacktrace. Die hier betroffenen Supabase-Keys haben exakt den gleichen fatalen Schadensradius, den wir bereits in unserem Beitrag über RLS-Fehlkonfigurationen durchgespielt haben. Der Chatverlauf ist das offene Buch, in dem sämtliche Architekturdetails im Klartext dokumentiert werden. Wenn diese Konversationen an die Öffentlichkeit geraten, ist der Schaden oft massiver als bei einem reinen Repository-Leak.
Die Warnungen kamen an Tag 19 – und versickerten in der Triage
Spätestens hier verlässt die Geschichte das Terrain einer handelsüblichen Regression. Bereits am 22. Februar – gerade einmal 19 Tage nach dem fehlerhaften Update – begannen Sicherheitsforscher, das Problem über das HackerOne-Programm von Lovable zu melden. Am 3. März reichte ein Hunter einen äußerst präzisen Report ein. Der Titel: „Broken Object Level Authorization on Lovable API leads to unauthorized access to user data and project source code“. Kein vages Stochern im Nebel. Die CWE-Klassifizierung, der betroffene API-Endpunkt, der Business Impact – alles steckte bereits kompakt in der Überschrift.
Das Ticket wurde sang- und klanglos als Duplikat geschlossen. Keine Eskalation, kein tiefgehender Review. Lovables offizielle Erklärung dazu: „The decision to close the reports was based on internal static documentation and context we had provided to our HackerOne partners, which still described public project chat visibility as intended behavior.“ Diese interne Dokumentation stammte aus einer Zeit, in der sichtbare Chats bei öffentlichen Projekten tatsächlich das gewünschte Verhalten waren. Nach der Härtung der Plattform – die dieses Verhalten überhaupt erst in eine Schwachstelle verwandelte – wurde die Doku schlichtweg nie aktualisiert. Das führte dazu, dass absolut korrekte Bug-Reports mit einer veralteten Spezifikation abgeglichen und kurzerhand als „False Positive“ aussortiert wurden.
Diese Fehlerkategorie verdient einen eigenen Namen, denn etliche Entwicklerteams da draußen pflegen unbewusst exakt dasselbe Setup. Nennen wir es „Closed as Intended“: Die angebliche „Wahrheit“ über die Autorisierungslogik existierte nur in einem Dokument, das Dokument war inkorrekt, und das Triage-Team vertraute dem Text anstatt dem Code. Die Erstsichtung bei Bug-Bounty-Programmen ist in der Regel ausgelagert. Die First-Line-Analysten filtern das Rauschen schlicht anhand des Runbooks, das der Kunde ihnen in die Hand drückt. Lovable rollte im November ein großes Security-Update aus, vergaß aber, das Runbook für HackerOne zu aktualisieren. Als die Bug-Reports eintrudelten, glich das Triage-Team diese mit einer Dokumentation ab, die den Fehler weiterhin als Feature deklarierte – und schloss sie als Duplikate. Die Meldungen wurden also keineswegs übersehen. Sie wurden empfangen, gelesen, an der offiziellen Definition von „korrekt“ gemessen und abgelehnt, weil sie ihr widersprachen. Zwei verschiedene Instanzen, die den Begriff „sicher“ definierten, waren gleichzeitig veraltet: Die Test-Suite, die hätte fehlschlagen müssen, und die Triage-Doku, die einen Incident hätte triggern sollen. Keine der beiden Instanzen verstieß gegen ihre eigenen, niedergeschriebenen Regeln. Das Problem war: Diese Regeln waren seit einem Jahr obsolet.
Das ist im Kern exakt dieselbe Fehlerquelle, die wir in unserem Teardown zur Meta-Support-KI analysiert haben. Dort steckte die Autorisierungslogik in einem KI-Modell, das sich durch clevere Prompts umstimmen ließ. Hier lag sie in einem statischen Dokument, das niemand je aktualisierte. Beide Vorfälle basieren auf demselben Grundproblem: Der Türsteher tat seinen Job, aber seine Anweisungen drifteten immer weiter von der Realität im Backend ab – und es gab keinen deterministischen Mechanismus, der diese Divergenz jemals abgefangen hätte.
Der Fix brauchte zwei Stunden – und das ist das eigentlich Erschreckende
Als der Sicherheitsforscher am 20. April einen funktionierenden Proof-of-Concept postete, schob Lovable innerhalb von nur zwei Stunden einen Patch nach. Diese rasante Reaktionszeit ist jedoch keine Heldengeschichte, sondern ein Armutszeugnis. Wenn eine Schwachstelle binnen zwei Stunden behoben werden kann, sobald die Chefetage den Ernst der Lage begreift, beweist das nur eins: Das Problem war nie technischer Natur. Der Fix hing schlichtweg daran, dass 76 Tage lang kein Entscheidungsträger an die Existenz des Bugs glaubte. Die Zustandsverwaltung im Code war klar, der nötige Eingriff minimal. Der kaputte Teil der Kette war der Feedback-Loop von „Ein unberechtigter Dritter kann Nutzerdaten auslesen“ zu „Ein Entwickler nimmt sich des Problems an“. Keine noch so schnelle Patch-Dauer kann am Ende die 76 Tage wiedergutmachen, in denen kritische Warnsignale systematisch ins digitale Nirvana geschlossener Tickets geroutet wurden.
Der eigentliche Fix bestand darin, die Regression rückgängig zu machen. Der API-Endpunkt prüft nun wieder korrekt die Besitzverhältnisse, bevor er Projektnachrichten ausliefert. Die umfassendere Maßnahme war jedoch, sämtliche historischen Projekte zwangsweise auf privat zu setzen – mit Ausnahme von Lovables eigenen Templates. Erst dieser zweite Schritt eliminierte das Risiko für die alte Kohorte endgültig. Man verließ sich nicht mehr blind auf eine fehlerfreie Autorisierungsprüfung pro Request, sondern entfernte schlicht das Public-Flag, das diese Altprojekte überhaupt erst angreifbar gemacht hatte. Zusätzlich verpflichtete sich Lovable zu einem reinen Opt-in-Modell fürs Projekt-Remixing, zu Nachschulungen für das HackerOne-Triage-Team und zu einer forensischen Auswertung der Access-Logs, um betroffene Nutzer über unautorisierte Zugriffe während des Leak-Zeitfensters zu informieren.
Die erste Reaktion machte alles nur noch schlimmer
Auch die externe Kommunikation am Tag des Leaks taugt perfekt als Negativbeispiel für das Incident-Management. The Register hat die Abwärtsspirale treffend zusammengefasst: Lovable behauptete zunächst lapidar, es habe „did not suffer a data breach“, deklarierte den Leak wiederholt als gewolltes Feature, schob die entstandene Verwirrung dann auf eine missverständliche Dokumentation des Begriffs „öffentlich“ – und zeigte schließlich mit dem Finger auf HackerOne, weil diese die Tickets geschlossen hätten. Drei völlig unterschiedliche Narrative an nur einem Tag. Jedes für sich genommen vielleicht technisch irgendwie vertretbar, in Summe jedoch ein kommunikativer Totalschaden, weil man krampfhaft versuchte, die Schuld überall zu suchen – nur nicht bei der eigenen Code-Regression. Das Post-Mortem zwei Tage später las sich deutlich aufrichtiger und räumte offen ein: „our first public response was dismissive and failed to acknowledge the real concern.“ Die schonungslose Wahrheit lag also die ganze Zeit auf dem Tisch. Sie war nur leider erst die vierte Version der Geschichte.
Das reflexartige Beharren auf „beabsichtigtem Verhalten“ zeigt eindrucksvoll, dass das interne mentale Modell des Unternehmens komplett von seiner eigenen, veralteten Triage-Doku korrumpiert war. Die PR-Leute logen nicht absichtlich, als sie den Leak anfangs herunterspielten. Sie nutzten lediglich dieselbe völlig veraltete Definition von „korrekt“, die auch zur Ablehnung der Bug-Reports geführt hatte. Der eigentliche Leak und das verunglückte Dementi hatten also dieselbe Ursache: Sowohl die Gatekeeper des Bug-Bounty-Programms als auch die Kommunikationsabteilung beriefen sich auf eine ein Jahr alte Antwort auf die simple Frage, was ein Fremder auf der Plattform lesen darf.
Was wir nicht bestätigen können – und auch nicht behaupten
Einige Details lassen sich nicht abschließend verifizieren. Eine Analyse, die das einfach übergeht, würde denselben Fehler begehen wie Lovables Triage-Team. Der Proof-of-Concept extrahierte angeblich echte Klarnamen, LinkedIn-Profile und Zugangsdaten aus der Live-App einer dänischen Non-Profit-Organisation. Dieses spezifische Detail stützt sich jedoch nur auf eine einzige Quelle – man sollte es also als Bericht einordnen, nicht als bewiesenen Fakt.
Lovables eigene Darstellung besagt, dass ein Angreifer im Vorfeld die exakte Projekt-URL kennen musste. Der präsentierte PoC mit seinen fünf simplen API-Calls legt hingegen nahe, dass sich Projekt-IDs entweder per Brute-Force erraten oder schlicht abfragen ließen. Keine verlässliche Quelle klärt bisher zweifelsfrei, ob ein Fremder ganze Projektlisten enumerieren konnte oder zwingend direkte Links beschaffen musste. Genau dieses Detail macht jedoch den Unterschied zwischen einem gezielten Angriff und einem massenhaften Datenabfluss aus. Lovable hat bislang keine harten Zahlen publiziert: Weder zur Anzahl der kompromittierten Projekte, noch zu den informierten Nutzern oder den Ergebnissen der Log-Analysen. Bis diese Metriken auf dem Tisch liegen, lautet das einzig belastbare Fazit: „Jedes öffentliche Projekt von vor November war ungeschützt erreichbar“ – und nicht zwangsläufig: „Jedes Projekt wurde auch abgegriffen“.
Wer auf einer Plattform hostet, erbt deren Regressionen
Das Takeaway für Gründer lautet an dieser Stelle nicht zwingend „Finger weg von Lovable“. Die eigentliche Lektion ist: Sobald Code auf einer Managed-Plattform läuft, delegiert man eine komplette Risikoklasse. Man kann diese Gefahren weder direkt einsehen noch selbst patchen. Der Quellcode, die API-Keys und der gesamte Prompt-Verlauf unterliegen den Autorisierungsregeln eines Drittanbieters. Wenn dieses Regelwerk eine Regression erleidet, erfährt man das nur nach dem Zeitplan des Anbieters, gefiltert durch dessen Triage-Prozess und bewertet nach dessen (womöglich völlig veralteter) Auffassung von „beabsichtigtem Verhalten“.
Diese Vertrauensgrenze lässt sich von außen nicht verlässlich auditieren. Man kann lediglich den möglichen Schaden dahinter minimieren. Zwei konkrete Maßnahmen sind hier entscheidend: Erstens, rotiere sämtliche Credentials, die jemals mit einem vor November 2025 erstellten Lovable-Projekt in Berührung kamen. Ein kompromittierter Key bleibt kompromittiert, bis er widerrufen wird – und das reine Löschen aus dem Code ist kein Widerruf. Zweitens: Keine Live-Secrets mehr in Prompts kopieren. Der KI-Chatverlauf ist ein permanenter Datenspeicher, dessen Zugriffsregeln völlig außerhalb der eigenen Kontrolle liegen. Wer vor November eine App auf Lovable gebaut und die verwendeten Keys bisher nicht rotiert hat, sollte pauschal davon ausgehen, dass diese öffentlich zugänglich sind.
Der Anbieter hatte den richtigen Schutzmechanismus etabliert, legte ihn bei einem Update versehentlich lahm und wurde bereits nach 19 Tagen explizit von Sicherheitsforschern darauf hingewiesen. Die letzte Verteidigungslinie, die hier versagte, war nicht der Code. Es war die Dokumentation, die definierte, was der Code eigentlich tun sollte – sowie die Triage-Kette, die einem veralteten Artikel mehr Glauben schenkte als einem knallharten Bug-Report. Überprüft, was in euren eigenen Runbooks steht. Und stellt sicher, dass jemand die Autorität hat, ihnen zu widersprechen, wenn die Realität eine andere Sprache spricht.