Künstliche Intelligenz generiert massenhaft Apps – und legt damit auch massenhaft Fallen
Im vergangenen Jahr war die faszinierendste Erzählung im Bereich der KI-Programmierung „Jeder kann Apps entwickeln“ – Personen ohne Programmierkenntnisse können durch die Eingabe weniger Schnittstellen Seiten generieren, Datenbanken verbinden und die Anwendung bereitstellen. Zum ersten Mal schien die Softwareentwicklung nicht mehr nur wenigen Ingenieuren vorbehalten zu sein.
Ein Produkt namens Moltbook legte die erste Rechnung für diesen Rausch vor.
Es positionierte sich als „soziales Netzwerk speziell für KI-Agenten“: Die Agenten posteten Beiträge, kommentierten und stimmten ab, bauten Vertrauen über ein Reputationssystem auf und wurden als „Startseite des Agenten-Internets“ bezeichnet. Der Gründer erklärte offen, dass dieses Produkt durch „Vibe-Coding“ entstanden sei – er selbst habe keine einzige Zeile Code geschrieben, sondern alles von KI generieren lassen.
Daraufhin stellte das Sicherheitsforschungsinstitut Wiz fest, dass eine fehlerhaft konfigurierte Supabase-Datenbank vollständigen Lese- und Schreibzugriff ermöglichte, sodass die Produktivumgebung für jedermann uneingeschränkt zugänglich war: 1,5 Millionen API-Authentifizierungstoken, 35.000 E-Mail-Adressen und zahlreiche private Nachrichten zwischen KI-Agenten lagen ungeschützt im öffentlichen Netz. Jeder konnte sich als beliebiges KI-Agenten-Konto auf der Plattform ausgeben und alle öffentlichen Inhalte manipulieren.
Dies ist kein Einzelfall, sondern etwas, das sich 2026 in großer Zahl ereignet. In der Softwarewelt gilt eine harte Wahrheit: Dass etwas läuft, bedeutet nicht, dass es nutzbar ist; dass etwas bereitgestellt werden kann, bedeutet nicht, dass man dafür verantwortlich sein kann. KI generiert massenhaft Apps – und legt gleichzeitig massenhaft Zeitbomben.
Hacking Moltbook: The AI Social Network Any Human Can Control
1. Das Gefährlichste ist nicht, dass es nicht funktioniert – sondern dass es „bereits fertig zu sein scheint“
Das Faszinierende am Vibe-Coding ist, dass es die Softwareentwicklung zu einem Spiel mit sofortigem Feedback macht: Du gibst eine Anfrage ein, die KI generiert Code; du sagst, der Button sieht schlecht aus, sie ändert das Design; du meldest einen Bereitstellungsfehler, sie gibt dir einen Befehl. Viele Frustrationen, die im herkömmlichen Entwicklungsprozess auftraten, werden durch wiederholte Dialoge in natürlicher Sprache beseitigt.
Diese Erfahrung erzeugt eine starke Illusion: Wenn die Seite geöffnet werden kann, ist das Produkt fertig. Aber echte Software ist mehr als nur eine Seite – die Seite ist nur der am leichtesten sichtbare Teil. Ob ein Produkt sicher läuft, hängt von einer Vielzahl unsichtbarer Faktoren ab: Authentifizierung, Rechteisolierung, Schlüsselverwaltung, Anonymisierung von Protokollen und Angriffsschutz. Diese Elemente sehen nicht so ansprechend aus wie Screenshots und erscheinen nicht automatisch in einer Demo.
Eine Untersuchung des israelischen Sicherheitsunternehmens RedAccess hat die Kosten dieser Illusion offengelegt: Die Forscher fanden heraus, dass etwa 380.000 öffentlich zugängliche Assets etwa 5.000 mit sensiblen Unternehmensinformationen enthalten – darunter medizinische Aufzeichnungen, Finanzdaten, interne Dokumente und Kundenservice-Gespräche. Ein Bericht von Axios erwähnt ebenfalls, dass diese Assets Anwendungen betreffen, die auf KI-/Low-Code-Plattformen wie Lovable, Base44, Replit und Netlify generiert oder gehostet werden. Der CEO von RedAccess sagte direkt: Die Datenschutzeinstellungen dieser Anwendungen sind „standardmäßig öffentlich zugänglich“.
Das heißt, die Hürde, eine funktionsfähige App zu erstellen, wurde durch KI fast auf Null gesenkt. Aber die Hürde, „zu wissen, dass man ungeschützt dasteht“, ist überhaupt nicht gesunken. Eine Reihe von Apps, die wie fertige Produkte aussehen, aber eigentlich eher halbfertige Experimente sind, werden direkt in die reale Welt gebracht – sie laufen nicht schlecht, sondern sie laufen viel zu früh.
Vibe-Coded
2. Die Hürde der Erstellung ist gesunken – aber die Hürde der Verantwortungsübernahme hat nicht Schritt gehalten
KI-Programmierwerkzeuge lösen das Problem „Wie erzeuge ich Code?“ – nicht das Problem „Wer trägt die Konsequenzen?“ Das ist der am leichtesten übersehene Punkt in diesem Rausch.
Eine eigene Sicherheitslücke bei Lovable verdeutlicht dies besser als jede Erklärung. Laut Offenlegungen in der Sicherheitscommunity konnte der Forscher weezerOSINT im April dieses Jahres nach der Registrierung eines kostenlosen Lovable-Kontos mit wenigen API-Aufrufen auf den Quellcode anderer Nutzer, Datenbankanmeldeinformationen und KI-Chatverläufe zugreifen. Dafür waren keine Angriffstechniken nötig – das Problem lag an fehlender Rechteprüfung der Schnittstellen, einer typischen BOLA-Schwachstelle (Broken Object Level Authorization), die angeblich alle Projekte betrifft, die vor November 2025 erstellt wurden. Der Forscher gab an, das Problem bereits 48 Tage zuvor über HackerOne gemeldet zu haben.
Lovable betonte zunächst, dass die Plattform keine Datenschutzverletzung im herkömmlichen Sinne erlitten habe, und erklärte einige Probleme als Missverständnisse der Nutzer bezüglich öffentlicher Projekte und Rechteeinstellungen. Daraufhin traten weitere Probleme im Zusammenhang mit der Anpassung der Backend-Rechte der Plattform und dem Ablauf von Schwachstellenmeldungen zutage. Das Unternehmen räumte ein, dass bei der einheitlichen Anpassung der Backend-Rechte im Februar dieses Jahres der Zugriff auf Chatverläufe öffentlicher Projekte „versehentlich wieder aktiviert“ wurde; der Forscher erwähnte zudem, dass HackerOne die Meldung als „doppelte Einreichung“ markiert hatte.
Eine Sicherheitslücke verwandelte sich am Ende in eine Kette von Verantwortlichkeiten, zwischen der Plattform, den Nutzern und dem Schwachstellenmeldeprozess – aber niemand sagte, dass dieses Produkt von Anfang an nicht die Priorität gesetzt hat, „die Code und Daten der Nutzer zu schützen“.
Das ist kein moralisches Problem, sondern ein Problem der Fähigkeitsstruktur. Ein unabhängiger Entwickler kann gleichzeitig Produktmanager, Designer, Frontend-, Backend- und Betriebsingenieur sein – aber er versteht wahrscheinlich nur die ersten zwei Rollen und hat kaum Vorstellungen von den anderen. KI kann ihm helfen, eine Anmeldelogik zu generieren, aber sie sagt ihm nicht automatisch, ob diese Logik den echten Sicherheitsanforderungen entspricht; sie kann ihm helfen, eine Datenbank anzubinden, aber sie entwirft nicht das Prinzip der minimalen Rechte für ihn. Subtiler noch: Der von KI generierte Code erzeugt eine psychologische Distanz: „Es läuft, also sollte es in Ordnung sein; es wurde von einem Modell generiert, also versteht es das wahrscheinlich besser als ich.“ KI hat die Menschen nicht von der Verantwortung befreit – sie hat nur viele dazu gebracht, die Verantwortung erst viel später zu erkennen.
3. Halb-Erfolg ist gefährlicher, als wenn niemand das Produkt nutzt
Früher fürchteten unabhängige Entwickler am meisten, dass niemand ihre Produkte nutzt. Im Zeitalter der KI-Programmierung wird eine andere Art des Scheiterns gefährlicher: Wenn Menschen das Produkt tatsächlich nutzen. Denn sobald jemand es nutzt, entstehen Daten; sobald Daten vorhanden sind, entsteht Verantwortung; und wenn niemand diese Verantwortung übernimmt, wird sie zum Risiko.
The Verge berichtete von einem einfachen Fall: Der Entwickler Bob Starr fand erst Monate nach der Bereitstellung seiner mit KI erstellten Website eine SQL-Injection-Schwachstelle. Der Artikel traf den Kern: Zwischen Amateurprojekten und Software, die echte Finanz- oder medizinische Daten verarbeitet, gibt es eine Grenze – aber Programmierer merken oft nicht, wann sie diese Grenze überschreiten.
Das Problem vieler KI-generierter Produkte ist nicht, dass sie zu schlecht sind – sondern dass sie halb erfolgreich sind. Wenn niemand sie besucht, sind sie nur verwaiste Projekte; wenn plötzlich jemand sie nutzt, können sie zu unbeaufsichtigten Datencontainern werden. Solche Produkte werden immer mehr, weil KI die Kosten für Ausprobieren extrem gesenkt hat: Eine Person kann in einem Dutzend kleiner Tools entwickeln, von denen die meisten nie richtig groß werden – aber alle werden kurzzeitig bereitgestellt, kurzzeitig Daten sammeln und kurzzeitig mit Drittanbieterdiensten verbunden, bevor sie in einer Cloud-Plattform oder einer Datenbankinstanz vergessen werden. Abhängigkeiten werden nicht aktualisiert, Schlüssel nicht ausgetauscht, Rechte nicht überprüft – aber die Schnittstellen sind immer noch zugänglich.
Das traditionelle Internet hinterlässt Zombie-Websites; die KI-Programmierung könnte Zombie-Apps hinterlassen. Der Unterschied: Zombie-Websites werden höchstens nicht besucht – aber Zombie-Apps könnten die Daten echter Nutzer enthalten. Die API-Token und privaten Agenten-Nachrichten, die bei Moltbook offengelegt wurden, sind im Grunde ein Datencontainer, der von dem rauschartigen Wachstum zurückgelassen wurde und niemand rechtzeitig aufräumte.
Moltbook
4. Die Fehler, die Low-Code gemacht hat – macht die KI-Programmierung jetzt noch einmal
„Nicht-professionelle Entwickler erstellen Software“ ist nichts Neues. Low-Code, No-Code und Excel-Makros haben ähnliche Versprechen gemacht und tatsächlich auch Probleme verursacht. In vielen Unternehmen gibt es Systeme, die „niemand anzufassen wagt“ – der ursprüngliche Entwickler ist seit Jahren weg, es gibt keine Dokumentation, die Rechte sind chaotisch, aber sie unterstützen immer noch kritische Abläufe.
KI-Programmierung hat diese Sache nur aus dem Unternehmensintranet ins öffentliche Netz getragen: Früher hat ein Mitarbeiter ein internes Formular kaputt gemacht, was nur eine Abteilung betraf. Jetzt erstellt eine Person ohne Kenntnisse der Sicherheitskonfiguration ein KI-Tool, aktiviert die offene Registrierung und weist eine Domain zu – was alle Fremden betrifft, die Daten hochgeladen haben.
Schlimmer noch: Diese „technischen Schulden“ sind schwer zu erkennen. Ein herkömmliches schlechtes System wirkt auf den ersten Blick unausgereift; KI-generierte Produkte sind anders – sie haben eine schöne Oberfläche, flüssige Interaktionen und verpacken sich in modernes UI-Design. Aber eine schöne Front-End-Oberfläche kann das fragile Back-End nicht verdecken: Die Anwendungen im RedAccess-Bericht, die medizinische Aufzeichnungen und Bankdaten durchsickern ließen, sahen äußerlich nicht anders aus als normal bereitgestellte Produkte.
5. Plattformen dürfen nicht nur das Wachstum genießen – sondern müssen auch Schutzmaßnahmen übernehmen
Man kann nicht nur die Nutzer beschuldigen – und schon gar nicht nur sie.
KI-Programmierplattformen nutzen das Gefühl „Jeder ist Entwickler“ für Wachstumsmarketing, und ihr Verkaufsargument ist „Die Hürde ist gefallen“. Aber wenn etwas schiefgeht, reagieren sie zunächst oft mit der Betonung „Das ist keine Datenschutzverletzung im herkömmlichen Sinne“ oder „Der Nutzer missversteht die Rechteeinstellungen“. Das bedeutet im Grunde: Eine Person ohne jeglichen technischen Hintergrund wird standardmäßig als verantwortlich betrachtet, das Rechtemodell selbst zu verstehen. Das ist, als ob die Plattformen die Wachstumsvorteile des „Null-Hürden“-Prinzips einstreichen – aber die Sicherheitskosten, die mit diesem Prinzip einhergehen, denjenigen überlassen, die sie am wenigsten tragen können. Die Reaktion von Lovable ist ein typisches Beispiel: Zuerst betonte man, es handele sich nicht um eine Verletzung, dann schob man die Schuld auf das Missverständnis der Nutzer – erst danach kam heraus, dass die Plattform bei der Rechteanpassung im Februar „versehentlich“ die Standardeinstellung von „privat“ auf „öffentlich“ zurückgesetzt hatte. Die eigene Verantwortung der Plattform wurde erst umständlich erwähnt.
Wenn eine Plattform als Verkaufsargument angibt, dass „man keine Technikkenntnisse braucht“, hat sie kein Recht, von den Nutzern zu erwarten, dass sie die Rechte-Risiken selbst verstehen. Standardmäßig auf privat statt öffentlich zu setzen, standardmäßig nach fest kodierten Schlüsseln zu scannen und standardmäßig den Nutzer vor der Bereitstellung zu warnen – das sind keine überflüssigen Zusatzfunktionen, sondern Verantwortungen, die die Plattform mit dem „Null-Hürden“-Versprechen eingehen müssen. Die meisten Plattformen priorisieren heute noch das Wachstum – sie zeigen lieber, wie man in zehn Minuten eine schöne App erstellt, als dem Nutzer ehrlich zu sagen, bevor er auf „Veröffentlichen“ klickt: „Ihre Datenbank ist derzeit öffentlich.“
Erwähnenswert ist, dass Sicherheit und Datenschutz nur ein Teil der Rechnung sind. Fragen zum Urheberrecht des von KI generierten Codes, zu den Pflichten aus Open-Source-Lizenzen und zur Einhaltung von Vorschriften bei der Verarbeitung von Nutzerdaten durch Dritt-KI-Systeme werden ebenfalls neu aufgeworfen. Zum Beispiel zieht sich der Rechtsstreit Doe v. GitHub durch das US-Gerichtssystem – einer der Streitpunkte ist, ob Copilot beim Generieren von Code urheberrechtliche Informationen aus Open-Source-Code entfernt hat. Apple hat in den App-Store-Überprüfungsregeln festgelegt, dass Entwickler die Nutzer ausdrücklich informieren und deren Zustimmung einholen müssen, bevor sie personenbezogene Daten an Dritt-KI-Systeme weitergeben. Mit anderen Worten: Die Risiken von Vibe-Coding gehen über „Gibt es eine Schwachstelle?“ hinaus – sie umfassen auch „Woher kommt der Code? Wohin gehen die Daten? Wer ist verantwortlich, wenn etwas schiefgeht?“
6. Die neue Hürde für unabhängige Entwickler: Nicht, Code zu generieren – sondern, Verantwortung zu übernehmen
Das bedeutet nicht, dass KI-Programmierung keine Hoffnung wert ist. Sie hat tatsächlich einen riesigen Raum geöffnet: Viele kleine Anforderungen waren früher aufgrund hoher Entwicklungskosten nie erfüllbar – heute kann eine Person Ideen schnell validieren und Nischengruppen bedienen.
Aber gerade weil die Hürden gesunken sind, wird eine neue Aufteilung schneller stattfinden. In Zukunft werden alle KI zum Schreiben von Code nutzen können – Fähigkeiten wie das Generieren von Seiten oder das Verbinden von APIs werden immer weniger zu einer seltenen Fähigkeit werden. Was wirklich wertvoll wird, ist: Wer kann eine Demo zu einem nachhaltig laufenden Produkt machen? Der Unterschied liegt nicht in der Kreativität, sondern in der technischen Verantwortung – ob man die Sensibilität von Nutzerdaten versteht, Rechtegrenzen entwerfen