CVE-2025-48757 ist eine als kritisch eingestufte Lovable-Schwachstelle (CVSS 9.3), die mehr als 170 Anwendungen offengelegt hat. Das Problem: Jeder konnte ohne Login Daten in deiner Datenbank lesen – und in vielen Fällen auch verändern: Namen, E-Mail-Adressen, API-Schlüssel von Drittanbietern, sogar den Zahlungsstatus. Die eigentliche Ursache ist kein versteckter Bug in Lovable, sondern ein Muster, das fast jede "vibe-coded" App teilt: die gesamte Datenbanksicherheit den RLS-Policies von Supabase zu überlassen … und sie dann unvollständig zu lassen.
Was wirklich passiert ist
Lovable baut Apps, bei denen der Browser direkt mit der Datenbank (Supabase) spricht, und zwar über REST-Aufrufe mit dem öffentlichen anon-Schlüssel. Das ist ein solides Design, solange jede Tabelle Row-Level-Security-(RLS-)Policies hat, die festlegen, welche Zeilen jeder Nutzer lesen oder anfassen darf. Die Schwachstelle entstand, weil viele Projekte mit Tabellen ausgeliefert wurden, die keine oder unzureichende RLS hatten. Ein Angreifer musste nur die REST-Anfrage bearbeiten – einen Filter in der URL ändern –, um "alle Zeilen" einer Tabelle abzufragen, die eigentlich hätte geschützt sein sollen.
Gemeldet wurde sie im März 2025 von Matt Palmer und Kody Low sowie unabhängig davon von Danial Asaria, die öffentliche Bekanntmachung erfolgte am 29. Mai 2025 (technische Analyse, CVE-Eintrag). Jedes Lovable-Projekt mit einer Datenbank, die am oder vor dem 15. April 2025 erstellt wurde, könnte betroffen sein.
Warum es dich auch betrifft, wenn du Lovable gar nicht nutzt
Das ist kein reines Lovable-Problem. Jede App, die direkt aus dem Browser mit Supabase spricht – egal, ob du sie mit Bolt, v0, Cursor oder von Hand gebaut hast –, ist darauf angewiesen, dass RLS auf jeder Tabelle korrekt eingerichtet ist. Die App sieht perfekt aus, der Login funktioniert, aber die echte Sicherheit steckt in der Datenbank, nicht in der Oberfläche. Einen Button im Frontend zu verstecken schützt gar nichts: Die REST-Anfrage ist trotzdem noch da, für jeden, der weiß, wo er suchen muss.
So erkennst du, ob deine App verwundbar ist
- Öffne die DevTools (F12) → Tab "Network", während du deine App nutzt, und beobachte die Aufrufe an
*.supabase.co/rest/v1/. Kopiere eine dieser URLs, öffne sie in einem Inkognito-Fenster (ohne Session) und schau, ob sie Daten zurückgibt. - Versuch, zu viel abzufragen: Wenn ein Aufruf deine Daten zurückgibt, entferne den Filter aus der URL. Wenn er dir die Zeilen anderer Nutzer ausliefert, ist deine RLS nicht wirksam.
- Prüfe das Supabase-Dashboard → Authentication → Policies. Jede Tabelle mit echten Daten, die "RLS disabled" oder gar keine Policy anzeigt, ist eine offene Tür.
So behebst du es
- Aktiviere RLS auf jeder Tabelle, nicht nur auf den "wichtigen". Die Regel lautet standardmäßig verweigern: Ohne eine Policy, die es erlaubt, kommt niemand rein.
- Schreib explizite Policies pro Operation (select/insert/update/delete), gebunden an
auth.uid(), damit jeder Nutzer nur seine eigenen Zeilen anfasst. - Verwende den
service_role-Schlüssel niemals im Frontend: Er umgeht RLS komplett. Dieser Schlüssel gehört ausschließlich auf den Server. - Teste erneut mit dem Inkognito-Schritt von oben: Wenn die Anfrage ohne Session jetzt leer bleibt oder einen Fehler zurückgibt, bist du auf dem richtigen Weg.
Wie Scanaris das prüft
Scanaris scannt deine Seite read-only und erkennt den Fingerabdruck dieses Musters: aus dem Browser erreichbare Supabase-Endpunkte, freizügiges CORS, Schlüssel und Tokens, die in deinem JavaScript offenliegen, und Daten, die die App ohne Session ausliefert. Füg deine URL ein, und es sagt dir in Sekunden und nach Schweregrad sortiert, was offen zutage liegt – bevor es jemand anderes findet.