Aktuelles

Vibe Coding: KI-gebaute Apps stellen Ausweisdaten ins Netz

Vibe Coding SicherheitThomas Jansen trägt keine Guy-Fawkes-Maske und keinen schwarzen Kapuzenpullover, hat kein Passwort geknackt, keine Firewall umgangen und keine Schadsoftware eingeschleust. Der Gründer des Hamburger Sicherheitsunternehmens Crissy Field hat einfach mal nachgeschaut. Rund fünf Stunden lang, mit KI-Unterstützung, quer durch mehr als 140.000 deutschsprachige Websites, die mit der KI-Plattform Lovable zusammengeschustert wurden. Am Ende lagen vor ihm Passnummern, Geburtsdaten, Fotos von Ausweisen, E-Mail-Adressen und private Chats. Frei abrufbar für jeden, der weiß, wo er hinklicken muss.

Fünf Stunden, ein Browser, 20.000 Betroffene

Das Handelsblatt hat Jansens Analyse Anfang November exklusiv veröffentlicht. Die Zahlen: Bei rund 15 Prozent der untersuchten Lovable-Seiten konnte er Daten einsehen. Betroffen sind demnach mehr als 20.000 Lovable-Nutzer, also Betreiber von Apps und Websites. Die Zahl der Menschen, deren Daten in diesen Apps stecken, dürfte um ein Vielfaches höher liegen.

Ein paar Funde aus der Recherche:

  • Eine Seite für US-Visa-Anträge mit Namen, Geburtsdaten und Passnummern, zeitweise auch mit Fotos der Ausweise.
  • Die Website eines Radiosenders, auf der die Profile registrierter Nutzer mit Namen und E-Mail-Adressen offen lagen.
  • Laut dem Crissy-Field-Report ein Lifestyle-Forum mit mehr als 200.000 Chatnachrichten und 80.000 Nutzerprofilen.
  • Ein CRM-artiges Projekt mit über 280.000 Kunden-E-Mails, Wartelisten-Einträgen und Support-Tickets.
  • Tausende Ticketbuchungen und Restaurantbestellungen mit Wohnadressen und Zahlungsinformationen.

Laut Handelsblatt hätten Datendiebe diese Lücke seit mindestens einem Jahr ausnutzen können. Ob das jemand getan hat, weiß niemand. Und genau das ist das Problem.

Warum hier niemand hacken musste

Um zu verstehen, was schiefläuft, braucht es zwei Begriffe. Keine Sorge, es bleibt kurz und ohne Nerd-Sprech.

Lovable-Apps speichern ihre Daten meist bei Supabase, einem Datenbank- und Backend-Dienst. Der Browser jedes Besuchers spricht diese Datenbank direkt an, und zwar mit einem öffentlichen Schlüssel, dem sogenannten Anon-Key. Der steht ganz bewusst im Quellcode jeder Seite. Das ist kein Fehler, sondern so gedacht.

Was dieser öffentliche Schlüssel lesen darf, regelt eine zweite Schicht: Row Level Security, kurz RLS. Das sind Regeln pro Tabelle und Zeile, etwa „jeder Nutzer sieht nur seinen eigenen Eintrag“. Fehlen diese Regeln oder sind sie zu großzügig formuliert, gibt die Datenbank jedem alles. Man stelle sich ein Mehrfamilienhaus vor, bei dem jeder Bewohner denselben Haustürschlüssel hat. Völlig normal. Nur hat leider niemand Schlösser in die Wohnungstüren eingebaut.

Der Ethical Hacker und IT-Rechtsexperte Dirk Koch hat Jansens Vorgehen geprüft. Sein Ergebnis laut Handelsblatt: Jansen hat nichts Illegales getan, weil er keinen Schutz umgangen hat. Es gab schlichtweg keinen!

Und das Tückische für die Ersteller: Im Alltag merken sie nichts. Das Formular speichert, der Login klappt, die App sieht gut aus. Dass ein Fremder dieselben Daten ohne Login abrufen kann, zeigt sich im normalen Betrieb nicht.

Ein altbekanntes Problem in neuer Größenordnung

Neu ist das nicht. Im März 2025 meldete der Sicherheitsforscher Matt Palmer genau dieses Muster an Lovable. Im Mai 2025 bekam es eine offizielle Kennung, CVE-2025-48757. Damals fand ein Scan 303 ungeschützte Schnittstellen in 170 von 1.645 geprüften Projekten. Lovable reagierte mit einem Security-Scanner, der laut einer Analyse von Superblocks anfangs nur prüfte, ob es überhaupt Zugriffsregeln gibt, nicht aber, ob sie auch funktionieren.

Im April 2026 folgte der nächste Ärger: Ein Forscher zeigte, dass man mit einem frischen Gratis-Account Quellcode, Datenbank-Zugangsdaten und KI-Chats fremder öffentlicher Projekte einsehen konnte, die vor November 2025 entstanden waren. Lovable sprach zunächst von gewolltem Verhalten und unklarer Dokumentation, dann von einem Fehler beim Bug-Bounty-Partner HackerOne. Eine Lehrstunde in Krisenkommunikation, nur leider eine negative.

Was sich verändert hat, ist die Größenordnung. Lovable meldet mehr als 50 Millionen umgesetzte Projekte und 1,2 Millionen neue pro Woche. Im August 2026 wurde das schwedische Start-up mit 13,3 Milliarden US-Dollar bewertet. Wenn bei dieser Masse auch nur ein kleiner Anteil die Tür offen lässt, reden wir über Zehntausende Datenlecks.

„Geteilte Verantwortung“ heißt: Ihre Verantwortung

Lovables Sicherheitschef Igor Andriushchenko spricht gegenüber dem Handelsblatt von einem bekannten, branchenweiten Konfigurationsproblem. Damit hat er nicht ganz unrecht. Das Sicherheitsunternehmen UpGuard hat in diesem Herbst rund 300.000 Domains mit Supabase-Bezug untersucht und bei 16.326 Datenbanken von außen lesbare Tabellen gefunden, gebaut mit ganz unterschiedlichen Werkzeugen. Supabase hat inzwischen reagiert: Seit dem 30. Oktober 2026 werden neue Tabellen in allen Projekten nicht mehr automatisch über die öffentliche Schnittstelle freigegeben. Bereits offene Tabellen bleiben aber offen, bis jemand sie schließt.

Der Kernsatz von Lovable lautet: Sicherheit sei eine geteilte Verantwortung. Klingt partnerschaftlich. Heißt in der Praxis: Die Plattform baut, die Plattform veröffentlicht, die Plattform kassiert. Und wenn es knallt, war es die Konfiguration des Kunden. Lovable bietet vor jeder Veröffentlichung einen Sicherheitsscan an, erzwingt aber nicht, dass gefundene Probleme behoben werden. In drei vom Handelsblatt gemeldeten Fällen hatte Lovable die Betreiber nach eigenen Angaben sogar gewarnt. Gehandelt haben die jedoch nicht.

Man kann das Achselzucken der Plattform kritisieren, und das sollte man auch. Aber es ändert nichts an der Rechtslage. Und die ist eindeutig.

Wer veröffentlicht, haftet

Datenschutzrechtlich verantwortlich ist der Betreiber der App, nicht das Werkzeug, mit dem sie gebaut wurde. Die DSGVO verlangt angemessene technische Schutzmaßnahmen und deren regelmäßige Überprüfung (Art. 32). Liegen personenbezogene Daten offen, kann das eine meldepflichtige Datenschutzverletzung sein: Meldung an die Aufsichtsbehörde möglichst binnen 72 Stunden (Art. 33), bei hohem Risiko auch an die Betroffenen (Art. 34). Verstöße gegen diese Pflichten können mit bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes geahndet werden. Dazu kommen Schadensersatzansprüche der Betroffenen nach Art. 82 DSGVO, auch für immaterielle Schäden. Und spätestens wenn Ausweiskopien im Netz liegen, ist der Schaden schnell sehr konkret.

Strafrechtlich wird es enger. Schlampige Konfiguration allein ist in aller Regel ein Fall für die Bußgeldbehörde, nicht für den Staatsanwalt. Die Strafvorschrift in § 42 BDSG setzt Vorsatz voraus, etwa wer Daten vieler Menschen wissentlich unberechtigt zugänglich macht und dabei gewerbsmäßig handelt. Wer allerdings einen Hinweis auf die offene Datenbank bekommt und die Tür trotzdem offen lässt, sollte sich auf das Wort „versehentlich“ nicht mehr allzu lange verlassen.

Und es wird nicht lockerer. Die neue EU-Produkthaftungsrichtlinie stuft Software ausdrücklich als Produkt ein, Deutschland muss sie bis zum 9. Dezember 2026 umsetzen. Hersteller haften dann verschuldensunabhängig für Schäden durch fehlerhafte Produkte, auch durch fehlende Sicherheitsupdates. Ein Haftungsausschluss nach dem Motto „hat die KI geschrieben“ hilft dabei nicht. Wessen Name auf dem Produkt steht, der steht auch in der Verantwortung.

Software muss deshalb getestet, geprüft und dokumentiert sein. Egal ob ein Mensch sie geschrieben hat, eine KI oder beide zusammen.

Die KI schreibt Code, der läuft. Sicher ist er deshalb noch lange nicht.

Dass die Lücken kein Zufall sind, zeigen auch breitere Studien. Veracode ließ für seinen GenAI Code Security Report 2025 über 100 Sprachmodelle jeweils 80 Programmieraufgaben lösen. In 45 Prozent der Fälle enthielt der Code eine Schwachstelle aus den OWASP Top 10, den häufigsten Sicherheitsrisiken für Webanwendungen. Im Bericht für 2026 stagniert die Sicherheitsquote bei rund 56 Prozent, während der Code syntaktisch fast immer fehlerfrei ist.

Das ist die eigentliche Pointe: Die Modelle werden immer besser darin, Code zu schreiben, der funktioniert. Beim Code, der niemandem schadet, kommen sie kaum voran. Und Vibe Coding belohnt genau das, was man sieht: die Oberfläche, die Demo, den Moment, in dem alles läuft.

Das Wissensproblem hinter dem Sicherheitsproblem

Früher hat die Hürde „Programmieren lernen“ eine ganze Menge Unfug verhindert. Wer eine Datenbank aufsetzen konnte, hatte meist auch mal etwas von Zugriffsrechten gehört. Diese Hürde ist weg. Heute baut jemand in ein, zwei Stunden ein Kundenportal, die KI stellt es gleich online, und am Abend sammelt es Ausweisfotos ein.

Das Gemeine daran: Wer nicht weiß, dass es Row Level Security gibt, fragt auch nicht danach. Weder einen Experten noch die KI. Man kann nichts prüfen, von dessen Existenz man nichts ahnt. Und die Plattformen haben wenig Interesse daran, den Zauber des „Einfach beschreiben, fertig“ mit unbequemen Sicherheitsabfragen zu stören.

Wenn jeder Software veröffentlichen kann, muss also auch jeder ein Grundwissen darüber haben, worauf es dabei ankommt. So wie jeder, der ein Auto fährt, wissen muss, dass Bremsen gewartet werden müssen, auch wenn er sie nicht selbst reparieren kann.

Die Mindest-Checkliste vor dem Go-live

Diese Punkte ersetzen keinen Penetrationstest. Sie decken aber die häufigsten Fehler ab, und sie gelten für jede Plattform, nicht nur für Lovable.

Prüfpunkt Worauf Sie achten sollten
Datenbestand Welche personenbezogenen Daten speichert die App überhaupt? Alles, was Sie nicht brauchen, erheben Sie gar nicht erst.
Zugriffsregeln Ist Row Level Security auf jeder Tabelle aktiv? Darf die Rolle „anon“ irgendwo ohne Bedingung lesen oder schreiben?
Gegenprobe ohne Login Rufen Sie Ihre App ausgeloggt oder mit einem zweiten Testkonto auf. Sehen Sie Daten, die Ihnen nicht gehören?
Geheime Schlüssel Steht ein Service-Key, API-Key oder Passwort im Code, der im Browser landet? Dann ist er öffentlich.
Sicherheitsscan Scans der Plattform laufen lassen und kritische Funde vor dem Start beheben, nicht danach.
Sensible Daten Ausweis-, Zahlungs- oder Gesundheitsdaten? Dann gehört eine Prüfung durch Fachleute vor den Go-live. Ohne Ausnahme.
Rechtliches Datenschutzerklärung, Impressum, Auftragsverarbeitungsverträge mit Hosting- und Datenbankanbieter.
Dokumentation Was wurde wann geprüft, von wem, mit welchem Ergebnis? Im Ernstfall ist das Ihr wichtigstes Beweismittel.
Notfallplan Wer meldet einen Vorfall innerhalb von 72 Stunden an die Aufsichtsbehörde, und wer informiert die Betroffenen?

Ein kleiner Tipp am Rande: Sie können die KI, die Ihre App gebaut hat, auch genau danach fragen. „Prüfe meine Datenbank auf fehlende Zugriffsregeln und erkläre mir, welche Daten ein nicht angemeldeter Besucher abrufen kann“ ist ein Prompt, der fünf Minuten kostet und im Zweifel ein Bußgeld spart. Blind vertrauen sollten Sie der Antwort allerdings auch nicht.

Wie die Großen prüfen: ein Blick auf CMMI

Zum Vergleich lohnt sich ein Blick darauf, wie große Softwarehersteller, Rüstungs- und Luftfahrtzulieferer oder Banken-Dienstleister arbeiten. Viele von ihnen richten ihre Entwicklung am Capability Maturity Model Integration aus, kurz CMMI. Das Reifegradmodell entstand ursprünglich an der Carnegie Mellon University im Auftrag des US-Verteidigungsministeriums, heute pflegt es das CMMI Institute unter dem Dach des IT-Verbands ISACA. Die aktuelle Version 3.0 erschien im April 2023 und umfasst 31 sogenannte Practice Areas, von Anforderungsmanagement über Konfigurationsmanagement bis zu Verifikation und Validierung, Peer Reviews und Prozess-Qualitätssicherung. Mit Version 3.0 kamen eigene Bereiche für Informationssicherheit dazu, darunter das gezielte Management von Sicherheitsbedrohungen und Schwachstellen.

CMMI kennt fünf Reifegrade. Auf Stufe 1 läuft Entwicklung eher nach Gefühl, also ungefähr dort, wo Vibe Coding heute steht. Auf Stufe 2 werden Projekte geplant, gesteuert und dokumentiert. Ab Stufe 3 gibt es unternehmensweit verbindlich definierte Prozesse: Festgelegt ist, welche Arbeitsergebnisse in ein Review gehen, wer prüft, nach welchem Verfahren, wann getestet wird, wie Fehler nachverfolgt und wie Änderungen versioniert werden. Jede Anforderung lässt sich bis zum Test zurückverfolgen, der sie absichert. Auf den Stufen 4 und 5, im Fachjargon High Maturity, wird die Qualität dann mit Kennzahlen statistisch gesteuert und die Ursachen von Fehlern werden systematisch analysiert, damit sie gar nicht erst wieder auftreten. Ob ein Unternehmen das wirklich lebt, prüfen externe Appraiser anhand von Nachweisen aus echten Projekten. Einfach nur ein schönes Prozesshandbuch im Schrank reicht dafür nicht mehr aus.

Das ist aufwendig und schweineteuer, keine Frage. Und niemand muss für ein Vereinsformular eine CMMI-Bewertung anstreben. Aber es zeigt den Abstand: Zwischen „Die KI hat es gebaut, es läuft“ und einer Software, deren Prüfung von der Anforderung bis zur Auslieferung nachvollziehbar dokumentiert ist, liegen Welten. Die Checkliste oben ist das absolute Minimum. Wirklich professionelle Softwareentwicklung beginnt drei Etagen höher.

Schneller bauen heißt nicht schneller fertig

Klar ist Vibe Coding ein großartiges Werkzeug. Für Prototypen, für Ideen, für interne Spielereien ohne echte Kundendaten. Kritisch wird es in dem Moment, in dem fremde Menschen der App ihre Daten anvertrauen. Diese Menschen wissen nicht, dass hinter dem hübschen Formular niemand stand, der die Datenbank je verstanden hat. Sie vertrauen einfach.

Jansen brauchte fünf Stunden, um Zehntausende offene Datensätze zu finden. Er hat sie gemeldet. Der Nächste, der mit denselben Werkzeugen sucht, wird das vermutlich nicht tun.

Quellen und weitere Informationen:


05.11.2026

RSS Newsfeed
Alle News vom TAGWORX.NET Neue Medien können Sie auch als RSS Newsfeed abonnieren, klicken Sie einfach auf das XML-Symbol und tragen Sie die Adresse in Ihren Newsreader ein!