Am 28. Januar 2026 ging ein soziales Netzwerk für KI-Agenten namens Moltbook an den Start. Der Gründer machte von Anfang an klar: Er hatte keine einzige Zeile Code selbst geschrieben. Die gesamte Anwendung wurde mit KI-Coding-Tools gebaut.
Drei Tage später fanden Sicherheitsforschende bei Wiz eine fehlkonfigurierte Supabase-Datenbank. Keine Row Level Security. Der API-Key lag im clientseitigen JavaScript. Voller Lese- und Schreibzugriff auf alles.
Das Ergebnis: 1,5 Millionen API-Authentifizierungstoken offengelegt. 35.000 E-Mail-Adressen. Private Nachrichten zwischen Agenten. Die Art von Breach, deren Entdeckung normalerweise Monate oder Jahre dauert, passierte hier, bevor das Produkt eine Woche online war.
Moltbook ist kein Einzelfall. Es ist eine Vorschau auf das, was passiert, wenn KI-generierter Code ohne Sicherheitsreview in Produktion geht. Und die Daten zeigen: Das geschieht im großen Stil.
Die Zahlen werden schlechter, nicht besser
Das Systems Software and Security Lab der Georgia Tech startete den Vibe Security Radar im Mai 2025. Das Projekt verfolgt CVEs — öffentlich registrierte Softwareschwachstellen —, die auf KI-generierten Code zurückzuführen sind.
Der Trend ist steil. Januar 2026: sechs CVEs. Februar: fünfzehn. März: fünfunddreißig. Die Aufschlüsselung für März: siebenundzwanzig Claude Code zugeschrieben, vier GitHub Copilot, zwei Devin, je eine Aether und Cursor.
Die Forschenden schätzen, dass sie nur 10 bis 20 Prozent der tatsächlichen Fälle erfassen. Die reale Zahl könnte bei 400 bis 700 CVEs im Open-Source-Ökosystem pro Monat liegen.
Die Branchendaten bestätigen das Muster. Veracode testete über 100 große Sprachmodelle in Java, JavaScript, Python und C#. 45 Prozent des KI-generierten Codes fiel bei Sicherheitstests durch. Bei Cross-Site-Scripting versagten die Modelle in 86 Prozent der Fälle. Bei Log-Injection in 88 Prozent.
Der 2026er-Report von Aikido Security befragte 450 Entwickelnde und Sicherheitsverantwortliche. 69 Prozent hatten Schwachstellen entdeckt, die durch KI-generierten Code eingeführt wurden. Jeder fünfte Vorfall verursachte materiellen Geschäftsschaden. US-Unternehmen waren am stärksten betroffen: 43 Prozent berichteten von schwerwiegenden Vorfällen, verglichen mit 20 Prozent in Europa.
Das ist kein theoretisches Risiko. Das sind Produktionssysteme mit echten Nutzenden und echten Daten.
Was wir tatsächlich finden
Wir sind in einer ungewöhnlichen Position. Wir bauen jeden Tag mit KI-Coding-Tools — Claude Code, Cursor, den kompletten Stack. Und wir pentesten Anwendungen, die genauso gebaut wurden, durch unsere Arbeit bei IJONIS und unser Sicherheitsprodukt DeepMantis. Dieselben Muster tauchen immer wieder auf.
Hartcodierte Secrets im Client-Code
Das war der Moltbook-Fehler, und es ist das häufigste Problem, das wir antreffen. KI-Modelle generieren funktionalen Code, der sich mit Datenbanken, APIs und Drittdiensten verbindet. Der Code funktioniert. Aber er bettet Zugangsdaten direkt in Dateien ein, die an den Browser ausgeliefert werden.
Das Problem ist nicht, dass KI-Tools keine Umgebungsvariablen kennen. Fragt man explizit, nutzen sie diese. Aber in einer Vibe-Coding-Session — wo Vorschlag um Vorschlag akzeptiert wird, ohne jeden einzelnen zu prüfen — wählt das Modell den schnellsten Weg zum lauffähigen Code. Oft bedeutet das: Connection-String direkt hartcodiert.
Das Moltbook-Muster
Supabase veröffentlicht einen "publishable" API-Key, der sicher exponiert werden kann — aber nur, wenn Row Level Security aktiviert ist. KI-Tools generieren regelmäßig Supabase-Integrationen, die den Key nutzen, ohne RLS zu konfigurieren. Das Ergebnis: voller Datenbankzugriff aus jedem Browser.
Fehlende oder defekte Authentifizierung
Wir finden regelmäßig Anwendungen, bei denen komplette API-Routen keinerlei Authentifizierung haben. Die KI generierte die Route, verband sie mit der Datenbank und lieferte Daten ans Frontend. Niemand bat sie, Auth-Middleware hinzuzufügen, also tat sie es nicht.
In einer Prüfung fanden wir 14 nicht authentifizierte API-Endpunkte in einer einzigen Anwendung. Keine obskuren Admin-Routen — Kerngeschäftslogik. Nutzerdaten, Zahlungsbelege, interne Dokumente. Die Entwickelnden hatten die App eingeloggt getestet, und alles funktionierte. Die KI hatte nie Schutzmaßnahmen hinzugefügt, und es fiel niemandem auf.
SQL-Injection an unerwarteten Stellen
Traditionelle Scanner testen Parameterwerte auf Injection. KI-generierter Code führt Injektionsvektoren oft an Stellen ein, die Scanner nicht prüfen: JSON-Schlüssel, Header-Werte, Dateinamen, Query-Sortierparameter.
Der McKinsey-Lilli-Breach — den wir in unserem vorherigen Beitrag über KI-Agenten im Pentesting ausführlich behandelt haben — war genau dieses Muster. Die SQL-Injection steckte in JSON-Feldnamen, nicht in Werten. Ein KI-Agent fand sie in zwei Stunden. Traditionelle Scanner hatten sie über zwei Jahre übersehen.
Übermäßig offene Datenbank-Konfigurationen
KI-Tools optimieren darauf, die Anwendung zum Laufen zu bringen. Wenn Datenbankberechtigungen Fehler verursachen, ist der Instinkt des Modells, den Zugriff so lange zu erweitern, bis die Fehler verschwinden. Wir finden Datenbanken, bei denen der Anwendungsnutzer volle Admin-Rechte hat, Tabellen ohne Row-Level-Policies und Storage-Buckets, die standardmäßig öffentlich sind.
Dependency Confusion
KI-Modelle schlagen Pakete namentlich vor. Manchmal sind diese Namen ähnlich, aber nicht identisch mit einem echten Paket. Manchmal existiert das Paket, wurde aber aufgegeben oder kompromittiert. Das Modell hat keine Möglichkeit, die Paketintegrität zu prüfen, bekannte Schwachstellen zu checken oder zu beurteilen, ob eine Abhängigkeit aktiv gepflegt wird.
Warum KI-Code strukturell verwundbar ist
Das sind keine zufälligen Bugs. Es gibt einen strukturellen Grund, warum KI-generierter Code zur Unsicherheit neigt, und er liegt in der Art, wie die Modelle trainiert und eingesetzt werden.
Trainingsdaten-Bias
Sprachmodelle lernen aus öffentlichem Code. Der Großteil öffentlichen Codes — Tutorials, Stack-Overflow-Antworten, Getting-Started-Guides, Beispiel-Repositories — priorisiert Klarheit und Einfachheit vor Sicherheit. Der Code, der zeigt, wie man sich mit einer Datenbank verbindet, enthält kein Rate-Limiting, keine Eingabebereinigung, kein Least-Privilege-Konzept. Er zeigt den Happy Path.
Wenn Sie vibe-coden, bekommen Sie Code, der wie Tutorial-Code aussieht. Weil er auf Tutorial-Code trainiert wurde.
Kein Bedrohungsmodell
Sicherheitsbewusste Entwickelnde schreiben Code mit einem Angreifenden im Hinterkopf. Was passiert, wenn diese Eingabe bösartig ist? Was, wenn diese Person nicht die ist, die sie vorgibt zu sein? Was, wenn diese Anfrage wiederholt wird?
KI-Modelle haben kein Bedrohungsmodell. Sie generieren Code, der die im Prompt beschriebene funktionale Anforderung erfüllt. Sicherheit ist orthogonal zur Funktion, und wenn der Prompt sie nicht explizit fordert, fügt das Modell sie nicht von sich aus hinzu.
Die Review-Lücke
Die gesamte Prämisse des Vibe Codings ist Geschwindigkeit. Sie beschreiben, was Sie wollen, die KI generiert es, Sie akzeptieren und machen weiter. Je mehr Sie reviewen, desto langsamer werden Sie — was den Sinn zunichte macht.
Das erzeugt eine systematische Review-Lücke. In traditioneller Entwicklung fängt Code-Review einen erheblichen Anteil der Sicherheitsprobleme ab, bevor sie in Produktion gelangen. In Vibe-Coding-Workflows ist genau dieser Schritt derjenige, der übersprungen wird.
Die Tools selbst sind Angriffsziele
Das Sicherheitsproblem geht über den Code hinaus, den KI-Tools generieren. Die Tools selbst sind zu Angriffsflächen geworden.
2025 ermöglichte eine Schwachstelle in Claude Code (CVE-2025-55284) die Datenexfiltration vom Rechner der Entwickelnden über DNS-Anfragen. Forschende bei AIM Security enthüllten eine Remote-Code-Execution-Lücke in Cursor, die keinerlei Nutzerinteraktion erforderte. OX Security fand kritische Schwachstellen in VS Code, Cursor und Windsurf, die Datenexfiltration ermöglichen könnten.
Supply-Chain-Risiko
Ein kompromittiertes KI-Coding-Tool betrifft nicht nur eine Datei. Es sitzt in der Entwicklungsumgebung mit Zugriff auf die gesamte Codebasis, Umgebungsvariablen, SSH-Keys und Cloud-Credentials. Ein einziger Exploit hat den Blast Radius einer vollständigen Workstation-Kompromittierung.
Das ist die unbequeme Wahrheit über das aktuelle Vibe-Coding-Ökosystem: Die Tools, die unsicheren Code generieren, sind selbst unsicher. Die Angriffsfläche multipliziert sich.
Was Sie dagegen tun können
Wir argumentieren nicht gegen KI-gestützte Entwicklung. Wir nutzen sie jeden Tag. Das Problem sind nicht die Tools — es ist der Workflow. Das hier funktioniert, basierend auf dem, was wir in Assessments sehen.
1. KI-Code behandeln wie Junior-Developer-Code
Jede Zeile wird gereviewed. Nicht überflogen — gereviewed. Wenn Sie keinen Praktikanten direkt in Produktion pushen lassen würden, lassen Sie es auch kein KI-Tool tun. Das klingt offensichtlich, ist aber die wirkungsvollste Einzelmaßnahme, die die meisten Teams umsetzen können.
2. Security-Scanning bei jedem Commit
Statische Analyse, Secret-Detection und Dependency-Auditing müssen automatisch bei jedem Commit laufen. Nicht vierteljährlich, nicht vor dem Release — bei jedem Commit. Tools wie Semgrep, Snyk und GitHubs eigenes Secret-Scanning fangen einen erheblichen Teil der Probleme ab, die wir manuell finden.
3. Pentest vor Launch, nicht nach dem Breach
Wenn Ihre Anwendung mit KI-Tools gebaut wurde — auch nur teilweise —, lassen Sie sie von jemandem testen, der KI-spezifische Schwachstellenmuster versteht. Traditionelle Pentests prüfen traditionelle Angriffsflächen. KI-generierter Code führt Vektoren ein, nach denen traditionelle Testende möglicherweise nicht suchen. Autonome Pentesting-Tools können diesen Prozess beschleunigen — unser Vergleich von sechs Plattformen zeigt, welche Tools für schnell deployende Teams geeignet sind.
4. KI-Tool-Umgebung absichern
Prüfen Sie, worauf Ihre KI-Coding-Tools Zugriff haben. Brauchen sie Ihre Produktionsdatenbank-Credentials? Ihre Cloud-Provider-Keys? Ihre SSH-Konfiguration? Wenden Sie das Least-Privilege-Prinzip auf Ihre Entwicklungsumgebung an, nicht nur auf Ihre Produktionsinfrastruktur.
5. Sicherheitsleitplanken in Ihren KI-Tools aktivieren
Die meisten KI-Coding-Tools unterstützen mittlerweile projektweite Konfigurationsdateien (CLAUDE.md, .cursorrules und ähnliche). Nutzen Sie sie. Definieren Sie Sicherheitsanforderungen explizit: Umgebungsvariablen für Secrets verlangen, Authentifizierung auf allen Routen erzwingen, Eingabevalidierung an Grenzen fordern. Die KI befolgt Anweisungen, die man ihr gibt.
Die regulatorische Uhr tickt
Der EU AI Act ist bereits in Kraft. Auch wenn er primär KI-Systeme und nicht KI-generierten Code adressiert, ist die Richtung klar: Die Verantwortlichkeit für KI-Outputs wächst. Wenn Ihre KI-generierte Anwendung personenbezogene Daten verarbeitet und ein Breach durch eine KI-eingeführte Schwachstelle eintritt, ist es der DSGVO egal, ob ein Mensch oder ein Modell den Code geschrieben hat.
Versicherer beginnen, in ihren Cyber-Liability-Fragebögen nach KI-Tool-Nutzung zu fragen. Die Frage ist nicht mehr, ob Sie KI zum Codeschreiben nutzen. Sondern ob Sie Kontrollen haben, wie dieser Code in Produktion gelangt.
Der Moltbook-Breach brauchte drei Tage. Die Georgia-Tech-CVE-Zahl verdoppelt sich von Monat zu Monat. Jeder fünfte Breach ist mittlerweile auf KI-geschriebenen Code zurückzuführen. Die Abrechnung kommt nicht erst. Sie ist da.
Wir bauen mit KI und wir brechen, was KI baut. Wenn Sie ein vibe-gecodetes Produkt ausliefern und wissen wollen, wo die Lücken sind, bevor jemand anders sie findet — melden Sie sich.