SecurityDSGVOIncident ReportAnalyse

Wenn 'sicher' nicht sicher genug ist: der Lovable-Vorfall und warum technische Sicherheit nicht reicht

Veröffentlicht am 24. April 2026 · 7 min Lesezeit · von Torben Schwellnus

Wenn "sicher" nicht sicher genug ist

Der Lovable-Vorfall und warum technische Sicherheit nicht reicht

Am 3. März 2026 meldete ein Sicherheitsforscher eine Schwachstelle in Lovables API an HackerOne. Sie war trivial auszunutzen: fünf API-Aufrufe über ein kostenloses Konto genügten, um auf Quellcode, Datenbank-Credentials und KI-Chat-Verläufe fremder Projekte zuzugreifen. Jeder Nutzer. Jedes Projekt, das vor November 2025 angelegt wurde.

Dann passierte: nichts. 48 Tage lang.

Am 20. April ging die Sache öffentlich. Lovables Reaktion verlief in drei Stufen. Erst: Das sei "intended behavior" gewesen — öffentliche Projekte seien schließlich öffentlich. Dann: Die Dokumentation sei vielleicht "unklar" gewesen. Schließlich: Schuld sei HackerOne, deren Triage-Team habe sich an veraltete interne Dokumente gehalten, die genau dieses Verhalten als beabsichtigt beschrieben hätten.

Der Sicherheitsforscher sah das anders. Die Security-Branche sah das anders. Und die Unternehmen, die auf Lovable produktive Apps betreiben, sahen es auch anders.

Ich baue Lastable gerade genau wegen solcher Geschichten. Aber diese hier ist besonders, weil sie keine klassische Breach-Story ist. Es ist eine Geschichte über eine viel grundlegendere Frage: Wer entscheidet eigentlich, was "sicher" ist?

Drei Definitionen von Sicherheit

Wenn du eine vibe-gecodete App in Produktion betreibst, hast du es mit drei Parteien zu tun, die jeweils eine andere Definition von Sicherheit haben. Und nur eine davon zählt für dich — aber es ist nicht die, die am lautesten spricht.

Platform-Sicherheit. Das ist die Lovable-Definition. "Unser System funktioniert wie entworfen." Wenn ein öffentliches Projekt als öffentlich markiert ist, dann ist es öffentlich. Wenn das so gedacht war, dann war es so gedacht. Platform-Sicherheit fragt: Verhält sich die Software wie spezifiziert? Die Antwort kann "ja" sein — und trotzdem kann das Ergebnis katastrophal sein.

Technische Sicherheit. Das ist die Sicht des Forschers. Eine BOLA-Schwachstelle (Broken Object-Level Authorization) liegt vor, wenn ein nicht-autorisierter Akteur auf Daten zugreifen kann, auf die er nicht zugreifen dürfte. Hier ist die Sache eindeutig: fünf API-Aufrufe, fremder Quellcode, fremde DB-Credentials. Technisch ist das ein Textbuch-Fall. Dass Lovable das als "beabsichtigt" einstuft, ändert daran nichts — BOLA ist ein OWASP-API-Security-Top-10-Kriterium, unabhängig davon, ob der Anbieter das Verhalten dokumentiert hat.

Business-Sicherheit. Das ist deine Definition. "Meine Kunden, meine Daten, mein Compliance-Stand sind geschützt." Und hier wird es interessant: diese Definition hat mit den ersten beiden überraschend wenig zu tun. Selbst wenn Platform und Tech beide sauber sind, kannst du ein Business-Sicherheitsproblem haben — wenn die Platform ihre Defaults leise ändert, wenn eine Regression temporär Zugänge öffnet, oder wenn dein Verständnis davon, was "öffentlich" bedeutet, nicht mit dem des Anbieters übereinstimmt.

Im Lovable-Fall haben wir den seltenen Fall, dass alle drei Definitionen kollidieren. Platform-Sicherheit: bestanden (laut Lovable). Technische Sicherheit: glatt durchgefallen. Business-Sicherheit: katastrophal.

Für dich als Betreiber ist nur die dritte relevant. Die ersten beiden sind nicht deine Aufgabe — aber sie bestimmen, ob du die dritte überhaupt erreichen kannst.

⚠️ Beware the tech: Wie die Schwachstelle konkret aussah

Lovables API behandelte Anfragen unterschiedlich, je nachdem wann das Projekt erstellt wurde. Neuere Projekte (nach November 2025) gaben auf denselben Endpunkt ein 403 Forbidden zurück. Ältere Projekte gaben ein 200 OK zurück — inklusive des vollständigen Quellbaums. Die Authorization-Prüfung war für Legacy-Projekte nie korrekt implementiert, und eine Backend-Regression im Februar 2026 hat das Problem nochmals verschärft, indem Chat-Historie und Source-Code auf "öffentlichen" Projekten wieder zugänglich gemacht wurden.

Der Angriffspfad: Auth an der Plattform mit einem beliebigen Free-Account → Nutzer-ID eines fremden Projekts enumerieren → API-Aufruf auf den Projekt-Endpunkt → vollständiger Quellbaum und Credentials. Fünf Calls, keine dokumentierten Rate-Limits.

Das ist kein esoterischer Angriff. Das ist der erste BOLA-Test, den jedes Security-Audit macht.

Warum diese Lücke bleiben wird

Das Lovable-Muster ist nicht die Ausnahme. Es ist strukturell.

Vibe-Coding-Plattformen sind auf Geschwindigkeit optimiert, nicht auf operative Sicherheit. Ihre Kennzahlen messen neue Builder, nicht bestehende Apps. Ihre Roadmaps priorisieren das nächste Feature, nicht das 18-Monats-Patch-Regime für eine App, die du vor einem Jahr gebaut hast. Das ist keine Böswilligkeit — es ist Ökonomie. Die Platform wächst mit Neukunden, nicht mit dauerhaft betreuten Bestands-Apps.

Hinzu kommt ein Problem, das Veracode 2025 quantifiziert hat: 45 % des KI-generierten Codes enthält mindestens eine OWASP-Top-10-Schwachstelle. Wiz hat separat gemessen, dass 20 % aller vibe-gecodeten Apps gravierende Sicherheitslücken mitbringen. Und Q1 2026 zeigte, dass 91,5 % aller vibe-gecodeten Apps mindestens einen halluzinationsbedingten Fehler enthalten.

Du lädst dir also statistisch erwartbar Schwachstellen in den Code, hostest auf einer Platform, die für Ops-Exzellenz keine wirtschaftlichen Anreize hat, und triffst dann auf Vorfälle wie Lovable — wo der Anbieter unter Druck entscheiden kann, dass das beobachtete Verhalten "beabsichtigt" sei.

Das ist keine Platform-Kritik. Es ist eine Arbeitsteilung. Lovable baut Werkzeuge. Für den dauerhaften Betrieb deiner Anwendung ist das Werkzeug nicht zuständig. Die Frage ist nur: wer dann?

Lovable ist kein Einzelfall

Der Lovable-Vorfall ist nur der jüngste in einer Serie, die mittlerweile ein Muster erkennen lässt.

Im Juli 2025 löschte ein Replit-Agent während eines offiziellen Code-Freezes die komplette Produktionsdatenbank eines SaaStr-Projekts — 1.206 Executive-Datensätze, 1.196 Firmen-Datensätze. Der Agent fabrizierte anschließend gefälschte Testergebnisse, um den Vorgang zu verschleiern. Replit-CEO Amjad Masad musste öffentlich reagieren und neue Safeguards ankündigen.

Im August 2025 wurde die Tea-Dating-App gehackt: 72.000 sensible Bilder (darunter 13.000 Ausweisdokumente) und 1,1 Millionen private Nachrichten gelangten auf 4chan. Ursache: ein offener Firebase-Bucket ohne Authentifizierung. Die KI hatte den Upload-Code korrekt generiert — nur ohne die negative Constraint "nicht öffentlich zugänglich machen".

Im März 2026 führte Claude Code ein terraform destroy auf der Produktionsumgebung von DataTalks.Club aus und löschte 2,5 Jahre an Schüler-Daten inklusive aller automatischen Snapshots — 1,94 Millionen Datensätze weg, nur per Amazon-Support wiederhergestellt.

Die Muster wiederholen sich: fehlende Umgebungstrennung, client-seitige Sicherheitslogik, unkonfigurierte Default-Rechte, keine Backups oder nur Backups am selben Ort wie die Produktion, unkontrollierte Agent-Aktionen ohne Delete-Protection. Escape.tech hat 5.600 vibe-gecodete Apps systematisch gescannt und dabei 2.000 Schwachstellen mit hoher Kritikalität, 400 offengelegte Secrets und 175 Fälle exponierter personenbezogener Daten gefunden — in produktiven Systemen. Tenzai hat 15 identische Apps auf fünf verschiedenen Vibe-Coding-Plattformen gebaut und 69 Schwachstellen identifiziert, sechs davon kritisch.

Wenn du all diese Fälle nebeneinanderlegst, fällt auf, dass die Platform-Anbieter in fast allen Vorfällen eine Variante derselben Antwort gegeben haben: "Das System hat wie vorgesehen funktioniert" oder "der Nutzer hätte es anders konfigurieren müssen". Technisch betrachtet mag das stimmen. Geschäftlich ist es kein Trost.

Was ein deutsches Unternehmen jetzt tun muss

Wenn du in Deutschland eine vibe-gecodete App betreibst, hast du zwei Probleme gleichzeitig: ein technisches und ein regulatorisches. Das regulatorische ist kurzfristig das teurere.

DSGVO Art. 32 verlangt von dir eine "geeignete" Absicherung der Verarbeitung. "Lovable hat gesagt, es sei sicher" ist keine rechtliche Verteidigung. Als Verantwortlicher musst du die Sicherheit deines Auftragsverarbeiters eigenständig bewerten — das bedeutet: du brauchst einen AV-Vertrag, eine TOM-Dokumentation und eine eigene Einschätzung der Angemessenheit. Keines dieser Artefakte bekommst du von Lovable standardmäßig mitgeliefert.

DSGVO Art. 33 verpflichtet dich zur Meldung binnen 72 Stunden nach Kenntnis einer Verletzung. Wenn dein Projekt vor November 2025 angelegt wurde und personenbezogene Daten enthält, kann der Lovable-Vorfall für dich ein meldepflichtiger Fall sein — unabhängig davon, ob Lovable ihn als solchen klassifiziert. Dass Lovable ihn "intended behavior" nennt, befreit dich nicht von deiner Prüfpflicht.

Ab August 2026 kommt der EU AI Act obendrauf. Die Bußgeldrahmen addieren sich: DSGVO bis 20 Mio € oder 4 % des Weltumsatzes, AI Act bis 35 Mio € oder 7 %. Die beiden sind unabhängig voneinander durchsetzbar.

Praktisch heißt das:

Wenn deine App vor November 2025 auf Lovable gebaut wurde: heute einen Audit-Trail anlegen, prüfen ob personenbezogene Daten verarbeitet wurden, Art. 33-Prüfung dokumentieren.
Unabhängig vom Erstellungsdatum: prüfen, wo die Daten physisch liegen (Lovable hostet standardmäßig außerhalb der EU), AV-Vertrag einholen, TOMs dokumentieren.
Für jede neue vibe-gecodete App, die produktiv geht: vor dem Go-Live einen unabhängigen Security-Check durchführen lassen. Die Platform macht das nicht für dich.

Das sind nicht meine Empfehlungen. Das ist, was passiert, wenn ein Datenschutzbeauftragter oder ein externer Auditor deine Anwendung bewertet.

Was wir bei Lastable machen

Ich habe Lastable genau deshalb angefangen, weil diese Lücke — zwischen "Platform funktioniert wie entworfen" und "Business ist sicher" — nicht von selbst zugeht. Sie wird größer.

Wir machen einen kostenlosen Health Check für deine vibe-gecodete App: Sicherheitsscan, DSGVO-Bewertung, Hosting-Analyse, Wartungs-Score. PDF-Bericht per E-Mail in fünf Werktagen. Keine Kosten, keine Verpflichtung.

Wenn du danach Hilfe willst bei der Migration auf EU-Hosting oder beim laufenden Betrieb — sind wir da. Wenn nicht, hast du einen Bericht, mit dem du weiterarbeiten kannst, auch ohne uns.

Die ersten 20 Apps bekommen einen Deep-Dive-Audit. Plätze sind noch frei.

Auf die Warteliste →