Dies ist unsere laufende Übersicht realer, öffentlich dokumentierter Vorfälle und Studien zur Sicherheit von KI-generiertem Code — Datenschutzverletzungen, Herstellertests und peer-reviewte Studien, jeweils mit Verweis auf die Originalquelle. Wir führen diese Liste, weil sich in jedem einzelnen Fall dasselbe Muster zeigt: KI schreibt Code, der funktioniert und live geht, und die darin verborgenen Schwachstellen zeigen sich erst später — in Produktion, vor den Augen der Kunden. Diese Seite wird laufend aktualisiert, sobald neue Vorfälle und Studien erscheinen — sie ist keine einmalige Zusammenstellung.
Selbst wenn die Aufgabe ausdrücklich lautet, eine bekannte Schwachstelle zu beheben, lag die KI häufiger falsch als richtig: Von 6,080 getesteten Patches lösten nur 26.0% die Schwachstelle vollständig und sauber, während 53.9% entweder komplett versagten oder eine neue Schwachstelle einführten. Das ist keine Lücke, die ein größeres Modell von selbst schließt — es ist das Argument dafür, dass ein Mensch jeden Patch liest, bevor er live geht, denn ein Tool, das seinen eigenen Patch bewertet, ist immer noch dasselbe Tool, das den Fehler geschrieben hat.
Eine Broken-Object-Level-Authorization-Schwachstelle — eine der ältesten und am besten dokumentierten API-Fehlerklassen überhaupt — lag 48 Tage lang live auf der mit $6.6B bewerteten Vibe-Coding-Plattform offen und legte dabei durchgängig Quellcode und Datenbank-Zugangsdaten anderer Nutzer frei. Größe und Finanzierung ersetzen nicht die manuelle Prüfung, ob eine Anfrage nach "deinen Daten" tatsächlich auch an meine gelangen kann; das ist ein Prüfschritt, keine Scanner-Einstellung.
28.65 Millionen hartcodierte Secrets landeten 2025 auf öffentlichem GitHub, und Secrets speziell im Zusammenhang mit KI-Diensten stiegen im Jahresvergleich um 81% — ein deutlich steilerer Anstieg als bei der Gesamtzahl. KI-Tools brauchen API-Keys, um zu laufen, und ein erheblicher Teil dieser Keys landet offenbar direkt in den Commits, die die Assistenten mitschreiben; ein Reviewer, der einen Diff vor dem Commit auf Secrets prüft, ist immer noch günstiger als das Rotieren von Zugangsdaten nach dem Leak.
Amazons eigenes KI-Coding-Tool nahm eine ungeprüfte Änderung vor, die eine produktive Live-Umgebung löschte und neu anlegte — und die Lösung des Unternehmens war nicht ein besseres Modell, sondern eine verbindliche Vier-Augen-Prüfpflicht durch Menschen, eingeführt in rund 335 Systemen. Das ist Amazon, mit mehr KI-Infrastruktur als fast jeder andere, das zu dem Schluss kommt: Die Antwort auf von KI verursachte Risiken ist mehr menschliche Kontrolle, nicht weniger.
Eine Firebase-Regel, die als allow read, write: if true stehen blieb, ist kein subtiler Bug — es ist eine Sicherheitsregel, die im Grunde sagt "keine Sicherheitsregel", und sie stand lange genug in Produktion, um sensible Daten von rund 600,000 Nutzern einer App zur Bekämpfung von Pornosucht offenzulegen. Niemand, der verstanden hätte, was diese Zeile bewirkt, hätte sie live geschaltet; das ist die ganze Begründung für ein zweites Paar menschlicher Augen, bevor irgendetwas KI-Generiertes live geht.
Hartcodierte Supabase-Zugangsdaten und eine fehlende Row-Level-Security-Richtlinie — beides Ein-Zeilen-Fixes, auf die ein erfahrener Backend-Entwickler reflexhaft prüft — gingen zusammen auf dieser KI-gebauten Social-Plattform live und legten rund 1.5 Millionen Auth-Tokens und 35,000 E-Mail-Adressen offen. Die App funktionierte und machte in der Demo einen guten Eindruck; funktionieren und sicher sein sind zwei verschiedene Maßstäbe, und nur einer davon lässt sich prüfen, indem man der App beim Laufen zusieht.
Broken Access Control hat Injection als häufigsten CodeQL-Sicherheitshinweis in öffentlichen Repositories abgelöst — ein Anstieg von 172% im Jahresvergleich, geflaggt in über 151,000 Repos. Zugriffskontroll-Logik ist genau die Art von geschäftlichem Kontextwissen, das ein Modell aus einem Prompt nicht ableiten kann — sie muss dagegen geprüft werden, wer tatsächlich was tun darf, und 151,000 Repos sind kein Rundungsfehler.
45% der KI-generierten Code-Beispiele enthielten eine OWASP-Top-10-Schwachstelle, und speziell bei Java stieg die Fehlerquote auf über 72%. Das sind keine obskuren Grenzfälle — die OWASP-Top-10 ist genau die Liste, auf die ein Junior-Entwickler im Code-Review trainiert wird zu achten, und das ist exakt der Schritt, der fehlt, wenn Code direkt vom Prompt in den Merge wandert.
Diese peer-reviewte Studie, vorgestellt auf der ACM CCS '23, kam zu dem Ergebnis, dass Entwickler mit KI-Unterstützung weniger sicheren Code schrieben — und sich dabei sicherer waren, dass er sicher sei. Das Vertrauen stieg genau in dem Maß, in dem die Sicherheit sank — das Gegenteil dessen, was ein funktionierender Review-Prozess liefern sollte, und genau in dieser Lücke zwischen "ich habe es geprüft" und "es ist tatsächlich sicher" zahlt sich ein unabhängiges menschliches Audit aus.
KI hat das Risiko eingebaut. Wir finden es, bevor Ihre Kunden es tun.
Jeder Eintrag oben folgt demselben Muster: Code, der funktionierte, live ging und eine Schwachstelle verbarg, die ein erfahrener Entwickler im Review erkannt hätte. Unsere Vibe Code Security Audits bringen drei Jahrzehnte Erfahrung in Security Engineering — jetzt angewandt auf das Zeitalter des KI-Codings — in eine manuelle Prüfung Ihrer Codebasis ein, keinen weiteren automatisierten Scanner. Sehen Sie in unseren Fallstudien, wie sich das in echten Deployments bewährt, oder nehmen Sie Kontakt auf, um über Ihre eigene Codebasis zu sprechen.
