Kim Icon 
Rund 380.000 Apps, gebaut mit KI-Tools wie Lovable, Replit oder Base44 – und Tausende davon stellen medizinische Dienstpläne, Finanzdaten und Chat-Protokolle offen ins Netz. Kein Hacker-Angriff nötig, einfach googeln reicht. Das ist das Ergebnis eines der größten Sicherheitsscans von KI-generierten Anwendungen, der im Mai 2026 publik wurde. Vibe Coding senkt die Einstiegshürde für App-Entwicklung dramatisch – und hebelt dabei systematisch grundlegende Sicherheitsprinzipien aus.
Das Risiko entsteht nicht, weil Menschen mit KI programmieren, sondern weil aus Prototypen zu schnell produktive Dienste werden. Genau diesen Sprung beschreibt unser Überblick zu Vibe Coding als neuer Programmierpraxis; bei sensiblen Daten braucht er aber zwingend Sicherheits- und Datenschutz-Gates wie in DSGVO-konformen AI-Workflows.
Das Sicherheitsunternehmen RedAccess hat im Rahmen einer Untersuchung, die unter anderem vom Technologiemagazin Wired aufgegriffen wurde, Tausende von Apps analysiert, die mit populären Vibe-Coding-Plattformen erstellt wurden. Der Scan umfasste rund 380.000 solcher Anwendungen – gebaut auf Lovable, Replit, Base44 und Netlify. Das Ergebnis ist ernüchternd: Etwa 5.000 dieser Apps waren vollständig ohne Authentifizierung öffentlich zugänglich. Via Google- oder Bing-Suche schlicht auffindbar.
Von diesen ungeschützten Apps enthielten rund 40 Prozent tatsächlich sensible Daten. Konkret: Krankenhaus-Dienstpläne mit Arztdaten, Werbebudgets, Chat-Protokolle mit Kundennamen und Kontaktdaten, Fracht- und Finanztransaktionen. Kein Passwort, kein Login, keine IP-Beschränkung. Einfach da.
Das ist kein akademisches Sicherheitsszenario. Das sind reale Daten, realer Menschen, in realen Organisationen. Und die wenigsten dieser Organisationen dürften überhaupt wissen, dass ihre internen Daten gerade in einem öffentlich indexierten Webprojekt stecken.
Vibe Coding bezeichnet das Erstellen von Software per natürlichsprachlicher Beschreibung – man tippt in ein KI-Tool, was die App machen soll, und bekommt funktionierenden Code zurück. Keine Programmierkenntnisse erforderlich. Der Boom dieser Werkzeuge seit 2025 ist unbestreitbar: Plattformen wie Lovable oder Base44 haben Hunderttausende Nutzer gewonnen, die in Stunden eine App bauen, für die früher Wochen Entwicklungszeit nötig waren.
Das Problem liegt nicht im Konzept selbst, sondern in der Architektur dieser Plattformen kombiniert mit dem, was KI-Modelle beim Code-Generieren systematisch übersehen. RedAccess-Mitgründer Dor Zvi brachte es auf den Punkt: Das Hosting unter plattformeigenen Domains sorgt dafür, dass Suchmaschinen diese Apps automatisch indexieren. Wer nicht explizit eine robots.txt-Datei setzt oder Zugriffsschutz einrichtet, macht seine Daten de facto öffentlich – und die meisten Nutzer ohne Entwicklungshintergrund tun das schlicht nicht.
Hinzu kommt, was Kaspersky in einer Untersuchung aus Oktober 2025 dokumentiert hat: KI-generierter Code weist systematisch bestimmte Schwachstellenklassen auf. Besonders häufig tauchen CWE-94 (Code-Injektion), CWE-78 (OS-Befehlsinjektion) und CWE-306 (fehlende Authentifizierung) auf. Das sind keine exotischen Nischenprobleme – das sind die Klassiker der Web-Sicherheit, die jeder Entwicklungslehrgang im ersten Monat behandelt. Kaspersky dokumentiert diese Schwachstellenverteilung ausführlich in seinem Vibe-Coding-Risikoüberblick.
Der aktuelle Scan ist keine Einzelmeldung. Die Vorgeschichte ist länger und konkreter.
Im November 2025 wurde bekannt, dass über die Plattform Lovable Quellcode, Chat-Protokolle und Kundendaten eingesehen werden konnten – darunter Accounts von Mitarbeitenden bei Nvidia, Microsoft, Uber und Spotify. Der Zugriff war über ein kostenloses Konto möglich. Lovable klassifizierte das Problem zunächst nicht als Datenleck, sondern als Feature. Die Lücke wurde laut Berichten erst nach 48 Tagen geschlossen.
Im Juli 2025 traf es Base44. Auch hier: unzureichender Zugriffsschutz auf App-Daten, die über die Plattform-Infrastruktur zugänglich waren. Kaspersky-Sicherheitsexperte Stan Kaminsky kommentierte das damals direkt: Vibe-Coding-Apps müssten gründlich getestet werden – in der Praxis passiere das selten. Die Plattformen binden Nutzer an ihre eigenen Sicherheitsschwächen, ohne dass diese es merken.
Bereits im Oktober 2025 hatte das Sicherheitsunternehmen Escape.tech bei 5.600 Apps über 400 exponierte API-Schlüssel und 175 Fälle mit personenbezogenen Daten gefunden – darunter Krankenakten und IBANs. Die Datenlage verdichtet sich also seit Monaten. Der aktuelle Scan über 380.000 Apps ist die bisher breiteste Bestätigung eines systemischen Problems.
Man muss das nüchtern sagen: KI-Modelle optimieren auf funktionierenden Code, nicht auf sicheren Code. Das ist kein Fehler in einem bestimmten Produkt, das ist eine Eigenschaft des aktuellen Stands der Technik. Wer einem Sprachmodell sagt, „baue mir eine App für Mitarbeiter-Dienstpläne“, bekommt eine App, die Dienstpläne anzeigt. Ob diese App Authentifizierung hat, ob Daten serverseitig validiert werden, ob API-Schlüssel im Client-Code eingebettet sind – das fragt der Prompt nicht, also beantwortet das Modell es oft auch nicht.
Die Cloud Security Alliance hat in einer Analyse aus dem ersten Quartal 2026 geschätzt, dass 40 bis 62 Prozent der KI-generierten Codebasen Sicherheitslücken aufweisen. Die Wiz-Studie aus 2025 bezifferte schwere Lücken in Vibe-Coding-Apps auf rund 20 Prozent. Die Spannbreite der Schätzungen zeigt, wie methodisch schwierig das Messen ist – aber auch dass das Risiko kein Randphänomen ist.
Interessant ist dabei der Kaspersky-Befund zur Wirksamkeit von sicherheitsorientierten Prompts: Wer beim Codieren explizit Sicherheitsanforderungen in den Prompt einbaut, reduziert die Zahl der Schwachstellen messbar – in einem dokumentierten Fallbeispiel von 158 auf 38 Probleme. Das zeigt: KI kann Sicherheit, wenn man sie danach fragt. Das Problem ist, dass die allermeisten Vibe-Coder das nicht tun, weil sie gar nicht wissen, was sie fragen müssten.
Spätestens hier wird es für Unternehmen juristisch ernst. Wer personenbezogene Daten in einer App verarbeitet – und das tun die meisten der betroffenen Anwendungen, ob bewusst oder nicht –, unterliegt der DSGVO. Fehlende Authentifizierung, fehlende Verschlüsselung, fehlende Zugriffsprotokollierung: Das sind keine technischen Unannehmlichkeiten, sondern potenzielle Verstöße gegen Artikel 25 (Datenschutz durch Technikgestaltung) und Artikel 32 (technisch-organisatorische Maßnahmen).
Dass die App mit einem KI-Tool gebaut wurde, ist vor einer Datenschutzbehörde kein Argument. Verantwortlich ist die Organisation, die die App betreibt – nicht die Plattform. Wer also in seiner Abteilung schnell ein Vibe-Coding-Tool nutzt, um ein Datenerfassungstool zu bauen, und dieses Tool dann ungeschützt online stellt, hat ein echtes Compliance-Problem. Keine abstrakte Theorie, sondern das, was die aktuellen Scans in Tausenden realen Fällen dokumentieren.
Eine detaillierte Aufbereitung des 380.000-App-Scans mit konkreten Fallbeispielen findet sich bei Martin Cid Digital. Die dort dokumentierten Fälle zeigen, wie unspektakulär die Vorfälle im Einzelnen wirken – und wie gravierend sie im Aggregat sind.
Um das abstrakte Risiko greifbarer zu machen, hilft ein konkretes Szenario – wie es sich aus den dokumentierten Fällen ableiten lässt: Eine Personalreferentin in einem mittelständischen Unternehmen möchte den monatlichen Schichtplan digitalisieren. Sie nutzt ein Vibe-Coding-Tool, beschreibt ihr Vorhaben in einem Satz, und erhält in wenigen Minuten eine funktionale Webanwendung. Sie trägt die Daten ein, teilt den Link mit den Kolleginnen und Kollegen – und denkt dabei nicht daran, dass diese URL von Suchmaschinen indexiert werden kann.
Was folgt, ist kein dramatischer Hacker-Angriff. Es ist schlicht, dass der Schichtplan inklusive Namen, Telefonnummern und Abwesenheitsdaten wenige Tage später über eine einfache Google-Suche auffindbar ist. Der Datenschutzbeauftragte erfährt davon nicht durch einen internen Hinweis, sondern weil ein aufmerksamer Externer die Datenschutzbehörde informiert. Das Ergebnis: Ein Meldeverfahren, interner Aufklärungsbedarf, im schlimmsten Fall ein Bußgeldverfahren – für eine App, die in zehn Minuten gebaut wurde und nie als risikoreich galt.
Dieses Szenario ist keine Übertreibung. Es ist die strukturelle Logik hinter den Tausenden Fällen, die der RedAccess-Scan und die Escape.tech-Untersuchung dokumentiert haben. Die betroffenen Organisationen sind keine leichtfertigen Akteure – sie haben schlicht unterschätzt, was „online stellen“ im Kontext von Vibe-Coding-Plattformen bedeutet.
Meine persönliche Einschätzung: Die Plattformbetreiber kommen hier zu leicht davon. Lovable hat den Datenzugang monatelang als Feature bezeichnet. Base44 hat gepatcht, nachdem der Schaden eingetreten war. Replit hat seit 2025 Verbesserungen angekündigt. Aber das grundlegende Geschäftsmodell bleibt: Barrieren senken, Nutzer gewinnen, Sicherheit nachrangig behandeln.
Das ist ein Strukturproblem. Plattformen, die sich an technisch nicht versierte Nutzer richten, haben eine besondere Verantwortung, Sicherheits-Defaults richtig zu setzen. Standardmäßig geschlossene Apps, obligatorische Authentifizierungsdialoge beim ersten Deploy, automatische robots.txt-Einträge – das wären Mindestmaßnahmen, die technisch trivial umsetzbar wären. Dass sie nicht Standard sind, ist eine Produktentscheidung, keine technische Unmöglichkeit.
Auf der anderen Seite stehen die Nutzer, die mit Vibe-Coding-Tools interne Geschäftsprozesse digitalisieren, ohne zu verstehen, was unter der Oberfläche passiert. Das ist kein Vorwurf – das ist das Versprechen dieser Tools. Aber KI-Sicherheit entsteht nicht durch guten Willen, sondern durch explizite technische Maßnahmen. Wer das nicht weiß, kann es auch nicht umsetzen.
Ein häufig gehörtes Gegenargument lautet, dass auch traditionell entwickelte Software Sicherheitslücken aufweist – und das stimmt. Der entscheidende Unterschied ist jedoch die Skalierung: Während professionelle Entwicklungsteams Sicherheitsreviews und strukturierte Freigabeprozesse kennen, fehlt dieser institutionelle Rahmen bei Vibe-Coding-Projekten fast vollständig. Das Risiko ist nicht neu, aber die Geschwindigkeit, mit der unsichere Apps in Produktivumgebungen gelangen, ist es.
Die Electronic Frontier Foundation hat 2026 klar formuliert: KI-gestütztes Programmieren ist nur mit harten Sicherheitsauflagen vertretbar. Konkret bedeutet das für Organisationen, die Vibe-Coding-Tools einsetzen oder erwägen:
Das Handelsblatt beleuchtet die IT-Sicherheitsrisiken durch Vibe Coding aus Unternehmerperspektive und zeigt, wie das Thema in der Geschäftswelt bereits wahrgenommen wird.
Das eigentliche Problem hinter allen diesen Vorfällen ist die Reihenfolge: Erst bauen, dann – vielleicht – sichern. Datenschutz by Design, wie ihn die DSGVO in Artikel 25 fordert, bedeutet das genaue Gegenteil: Sicherheitsanforderungen definieren, bevor der erste Code-Prompt abgefeuert wird.
Für traditionelle Softwareentwicklung ist das längst Standard. Bedrohungsmodellierung, Secure Development Lifecycle, Code Reviews – das sind etablierte Prozesse. Vibe Coding hat diesen Prozess abgekürzt, nicht ersetzt. Die Frage, die sich Organisationen stellen müssen: Wie integriert man Sicherheitsgovernance in einen Prozess, der explizit auf Geschwindigkeit und Zugänglichkeit ausgelegt ist?
Meine Einschätzung dazu ist klar: Das lässt sich lösen, aber nicht durch Selbstregulierung der Plattformen allein. Es braucht Mindeststandards auf Plattformebene – etwa verpflichtende Sicherheits-Checklisten vor dem ersten öffentlichen Deploy – und es braucht Bewusstsein bei den Nutzern, dass ein KI-generierter Funktionsprototyp noch keine produktionsreife Anwendung ist. Der Unterschied zwischen „es funktioniert“ und „es ist sicher“ ist in der Welt des Vibe Coding größer als je zuvor.
Die naheliegende politische Reaktion auf systematische Sicherheitsdefizite ist Regulierung. Und tatsächlich gibt es bereits Ansätze: Der EU AI Act adressiert Hochrisiko-KI-Systeme mit expliziten Anforderungen an Transparenz, Robustheit und Sicherheit. Für die meisten Vibe-Coding-Plattformen greift er jedoch nicht direkt, weil die generierten Apps in der Regel nicht als eigenständige KI-Systeme klassifiziert werden, sondern als nutzerverantwortete Software.
Das schafft eine Regulierungslücke: Die Plattform ist nicht verantwortlich, weil sie nur ein Werkzeug bereitstellt. Der Nutzer ist verantwortlich, versteht aber oft nicht, worüber er Verantwortung trägt. Und die betroffenen Personen, deren Daten exponiert sind, erfahren davon häufig gar nichts. Diese Lücke ist kein Zufall – sie ist das Ergebnis einer regulatorischen Landschaft, die mit der Entwicklungsgeschwindigkeit von Vibe-Coding-Tools nicht mithalten kann.
Eine realistische Lösung könnte in plattformspezifischen Zertifizierungsanforderungen liegen: Wer eine Vibe-Coding-Plattform für geschäftliche Anwendungen vermarktet, sollte nachweisen müssen, dass bestimmte Sicherheits-Defaults aktiv sind. Das ist kein radikaler Eingriff – es ist das Äquivalent zu Sicherheitsgurtpflichten in der Automobilbranche. Die Technologie bleibt zugänglich, aber die Grundschutzanforderungen werden nicht dem Ermessen der Einzelnen überlassen.
Der 380.000-App-Scan ist ein Datenpunkt, der sich schwer ignorieren lässt. KI-Sicherheit ist kein Thema mehr für Sicherheitskonferenzen allein – es betrifft jede Abteilung, die mit einem Vibe-Coding-Tool eine interne Lösung baut. Datenlecks durch fehlende Authentifizierung, exponierte API-Schlüssel, öffentlich indexierte Datenbanken: Das sind keine hypothetischen Risiken. Das ist der dokumentierte Status quo.
Und die eigentliche Frage, die dieser Scan aufwirft, hat noch keine befriedigende Antwort gefunden: Wie skaliert KI-Sicherheit in einer Welt, in der Millionen von Menschen ohne Sicherheitskenntnisse produktiven Code schreiben? Haben die Plattformbetreiber eine Antwort darauf – oder wartet die Branche auf den nächsten, größeren Vorfall?
