Die kurze Antwort
Im Juli 2026 ließ die Sicherheitsfirma Theori ihre autonome Pentest-Plattform Xint gegen 28 mit KI-Coding-Tools gebaute Anwendungen laufen und bestätigte 434 ausnutzbare Schwachstellen — 196 in neu gebauten Apps und 238 in einem einzigen Legacy-System, das mit KI-Unterstützung neu geschrieben wurde. Das Bemerkenswerte ist die Form der Fehler. Die Modelle, verteilt über fünf Frontier-Releases von Anthropic und OpenAI, hatten sich klar verbessert: klassische SQL-Injection und Cross-Site-Scripting waren selten, weil Prepared Statements und Input-Sanitisierung standardmäßig kamen. Was fehlte, war alles, was den Blick auf das Gesamtsystem braucht — fehlende Rate Limits und unbegrenzte Abfragen (Denial of Service), ungeprüfte Objektreferenzen (IDOR) und Default Secrets, direkt aus Quick-Start-Vorlagen übernommen.
Für Teams, die KI-Assistenten fest in die tägliche Entwicklung eingebunden haben, lautet die Botschaft nicht „hört auf, sie zu nutzen". Sondern: KI produziert Code, der richtig aussieht und kompiliert, während er die Sicherheitseigenschaften auslässt, die ein menschlicher Architekt ohne Nachdenken durchsetzt. Diese Lücke ist mit Review günstig zu schließen und teuer zu ignorieren — weshalb KI-geschriebener Code in einen sicheren Software-Entwicklungsprozess gehört und nicht direkt vom Prompt in die Produktion.
Was Theori getestet hat
Theori baute die Studie um seine Xint-Plattform auf, die autonome, KI-gesteuerte Penetrationstests durchführt und dabei Laufzeit-Probing mit Quellcode-Analyse kombiniert. Das Team richtete sie auf 28 Anwendungen, die über verschiedene KI-Coding-Workflows entstanden — von einem einzeiligen „bau mir eine App"-Prompt bis zu strukturierterer, spezifikationsgetriebener Generierung — mit fünf Frontier-Modellen von Anthropic und OpenAI. Jede App erhielt einen rund 30-minütigen Scan. Die Rohausgabe war verrauscht: 8.827 potenzielle Befunde. Nach Deduplizierung und Ausnutzbarkeits-Triage blieben 434 Probleme als tatsächlich ausnutzbar übrig, und das sind die Zahlen, auf die es ankommt.
Die Aufteilung ist aufschlussreich. Zwei Greenfield-Apps, von Grund auf generiert, kamen auf 196 bestätigte Schwachstellen. Ein einzelner Brownfield-Fall aber — das Legacy-PHP-Forum Gnuboard7, mit KI-Hilfe auf einen Laravel-und-React-Stack migriert — trug 238 allein, mehr als beide Greenfield-Apps zusammen. Das ist das klarste Signal des Berichts: KI-gestützte Neuschreibungen bestehender Systeme erben nicht nur altes Risiko, sie vervielfachen es, weil sich dieselben fehlenden Prüfungen über eine größere Oberfläche wiederholen. Für alle, die eine KI-beschleunigte Legacy-Modernisierung abwägen, ist das die Zeile, die man vor dem Start unterstreicht.
Welche Bugs die KI hinterließ
Der Schwachstellen-Mix ist die eigentliche Geschichte, denn er sagt Ihnen, wo Sie in Ihrem eigenen KI-generierten Code suchen müssen. Ressourcen-Erschöpfung und Denial of Service führten mit rund 21 % der Befunde die Liste an — unbegrenzte Paginierung, die eine ganze Tabelle zurückgibt, Endpunkte ohne Rate Limit und synchrone blockierende Operationen, die eine einzelne Anfrage einen Worker blockieren lassen. Die Auswirkung, wie Theori es fasste, sind nicht gestohlene Daten, sondern „ausufernde Serverkosten oder ein Server, den ein Angreifer umwerfen kann". Für ein SaaS auf getakteter Cloud ist das ein Abrechnungs- und ein Verfügbarkeitsvorfall zugleich.
Fehlerhafte Autorisierung, vor allem Insecure Direct Object References (IDOR), folgte als Nächstes. Hier ist der Größeneffekt deutlich: etwa 11 % der Befunde in den kleinen Greenfield-Apps, ansteigend auf rund 28 % im neu geschriebenen CMS, weil die KI Eigentumsprüfungen über Hunderte Endpunkte hinweg inkonsistent anwandte — oder vergaß. Vertrauensgrenzen-Probleme wie Path Traversal und Server-Side Request Forgery kamen als weiterer Block hinzu. Und unter den 23 kritischen Befunden ist das Muster, das jedes Team beunruhigen sollte, das simpelste: 11 waren Hardcoded oder Default Secrets — Default-SECRET_KEY-Werte, JWT-Signaturschlüssel und eingebettete Zugangsdaten aus Starter-Vorlagen — plus 6 Fälle von aktiviertem Debug-Modus, der einen Stack-Trace in Remote Code Execution verwandelt.
Die Befunde im Überblick
Die zentralen Klassen aus Theoris bestätigtem Set von 434 ausnutzbaren Problemen:
| Befund | Was Theori berichtete |
|---|---|
| Analysierte Apps | 28 KI-generierte Apps, 5 Frontier-Modelle (Anthropic & OpenAI) |
| Roh → bestätigt | 8.827 Befunde triagiert auf 434 ausnutzbare |
| Greenfield vs. Brownfield | 196 in zwei neuen Apps; 238 in einer KI-neu-geschriebenen Legacy-App |
| Häufigste Klasse | Ressourcen-Erschöpfung / DoS (≈21 %) |
| Zweite Klasse | Fehlerhafte Autorisierung / IDOR (11 % klein → 28 % groß) |
| Kritische Befunde | 23 gesamt — 11 Hardcoded/Default Secrets, 6 Debug-Modus-RCE |
| Gut bewältigt | SQL-Injection und XSS — selten, dank Default-Prepared-Statements & Sanitisierung |
Warum KI-Code auf diese Weise scheitert
Das Muster ist nicht zufällig, und es zu verstehen sagt Ihnen, welches Review Priorität hat. Ein Sprachmodell generiert Code Token für Token aus lokalem Kontext. Es ist sehr gut in der Form einer sicheren Datenbankabfrage oder eines escapten Templates, weil das lokale, wiederholte Muster sind, die es millionenfach gesehen hat. Es ist schlecht bei Eigenschaften, die nur auf der Ebene des Gesamtsystems existieren: welcher Nutzer diesen Datensatz besitzt, wie viele Zeilen dieser Endpunkt je zurückgeben sollte, welche Route niemals mit aktiviertem Debug laufen darf, wo die Vertrauensgrenze zwischen Mandantendaten tatsächlich liegt. Das sind architektonische Fakten, keine zeilenweisen Idiome.
Theoris CTO Andrew Wesie brachte es auf den Punkt: die „Schwachstellen-Klassen, mit denen Modelle noch kämpfen, sind jene, die ein Verständnis auf Systemebene erfordern". Dieser eine Satz sollte umformen, wie Teams die Arbeit mit KI aufteilen. Die Modelle haben Vertrauen bei den mechanischen, Injection-artigen Bugs verdient; bei Autorisierung, Ressourcen-Governance oder Secrets-Hygiene haben sie es nicht. Theoris eigene Empfehlung folgt daraus direkt — automatisierte Tools nutzen, um große Mengen KI-generierten Codes auf die wiederkehrenden Klassen zu screenen, und menschliche Experten auf Threat Modeling und Architektur fokussieren statt auf zeilenweises Review. Genau diese Arbeitsteilung bauen wir in die Art ein, wie wir KI-Agenten und -Assistenten für Kunden ausliefern: das Modell darf entwerfen, aber nie das letzte Augenpaar an einer Vertrauensgrenze sein.
Was das für DACH- & EU-Software-Teams bedeutet
Aus der Vogelperspektive ist die Studie eine Warnung vor Geschwindigkeit ohne Sicherheitsnetz. KI-Assistenten lassen ein kleines Team in Tagen eine funktionierende Anwendung ausliefern, und jede der 28 Apps funktionierte — die Fehler blieben unsichtbar, bis ein autonomer Pentester nachsah. Teams, die nur „läuft es" messen, häufen eine Sicherheitsschuld an, die sie nicht sehen, und das Brownfield-Ergebnis zeigt, dass diese Schuld mit wachsender Codebasis kumuliert. Die Antwort ist nicht langsamere Entwicklung; es ist, automatisierte Sicherheitsprüfung zu einer nicht verhandelbaren Stufe in der Pipeline zu machen, damit die DoS-, IDOR- und Secrets-Klassen von Maschinen im Tempo des geschriebenen Codes abgefangen werden.
Für regulierte Produkte steht mehr auf dem Spiel als ein Bug-Ticket. In FinTech und HealthTech ist ein IDOR, der die Datensätze eines anderen Kunden offenlegt, ein Datenschutzvorfall mit den genannten Fristen. Ein Hardcoded-Signaturschlüssel in einem öffentlichen Repository ist eine Offenlegung, die nur auf ihren Moment wartet. Der EU AI Act und Rahmenwerke wie ISO 27001 und SOC 2 erwarten bereits einen dokumentierten, kontrollierten Entwicklungslebenszyklus. Die Teams, die schnell vorankommen und konform bleiben, sind jene, die KI-Ausgabe als nicht vertrauenswürdigen Input für einen echten Secure-SDLC behandeln — nicht als fertige Arbeit.
Was diese Woche zu tun ist
Eine kurze, praktische Abfolge, die die Studie in Handeln statt in Angst verwandelt:
- In der CI nach Secrets scannen. Secret-Erkennung in die Pipeline aufnehmen und Commits blockieren; jeden Schlüssel rotieren, der je in Quellcode oder Vorlage auftauchte. Das neutralisiert die größte einzelne kritische Klasse der Studie.
- Entwicklungs-Defaults abschalten. Jede Umgebung auf aktivierten Debug-Modus, ausführliche Fehlerausgaben und stehen gelassene Framework-Defaults prüfen — die Quelle der Debug-Modus-RCEs.
- Last testen und Rate Limits setzen. Rate Limits, Paginierungs-Obergrenzen und Timeouts in KI-generierte Endpunkte einbauen; auf unbegrenzte Abfragen prüfen, bevor es ein Angreifer oder eine Cloud-Rechnung tut.
- Autorisierung von Hand prüfen. IDOR ist genau das, was Automatisierung übersieht und was mit der Größe wächst — ein Mensch verifiziert Eigentumsprüfungen an jedem Endpunkt, der Nutzerdaten zurückgibt.
- AppSec zur Pipeline-Stufe machen. Automatisierte Sicherheitsprüfung vor den Merge von KI-geschriebenem Code setzen und alles, was eine Vertrauensgrenze berührt, an einen menschlichen Verantwortlichen leiten.
Nichts davon spricht gegen KI-Coding-Tools — der Produktivitätsfall ist real, und die Modelle haben die Injection-Bugs, die eine Generation von Apps plagten, tatsächlich geschlossen. Aber die Studie ist ein klares Signal: KI schreibt Code, der eine Demo besteht, nicht Code, der einen Angreifer übersteht. Die Teams, die die fehlende Review-Schicht ergänzen, bekommen beides — Geschwindigkeit und Sicherheit; jene, die sie auslassen, liefern 434-Schwachstellen-Apps aus, ohne es zu wissen.
Häufig gestellte Fragen
Was hat die Theori-Studie zu KI-generiertem Code ergeben?
Theori ließ ihre autonome Pentest-Plattform Xint gegen 28 mit KI-Tools gebaute Apps über fünf Frontier-Modelle von Anthropic und OpenAI laufen, triagierte 8.827 Rohbefunde und bestätigte 434 ausnutzbare Schwachstellen — 196 in Greenfield-Apps und 238 in einer KI-neu-geschriebenen Legacy-App. Ressourcen-Erschöpfungs-DoS führte, gefolgt von fehlerhafter Autorisierung; von 23 kritischen Befunden waren 11 Hardcoded oder Default Secrets und 6 Debug-Modus-RCE.
Warum enthält KI-generierter Code Sicherheitslücken?
Die Modelle bewältigten SQL-Injection und XSS gut mittels Prepared Statements und Sanitisierung, kämpfen aber mit systemischem Denken — Vertrauensgrenzen, Ressourcenlimits und Dateneigentum. Deshalb lassen sie Rate Limits weg, prüfen Objektreferenzen nicht (IDOR) und übernehmen Default Secrets aus Vorlagen. Wie Theori-CTO Andrew Wesie anmerkte, sind die schweren Klassen jene, die ein Verständnis auf Systemebene erfordern.
Werden Schwachstellen in größeren KI-generierten Codebasen schlimmer?
Ja. IDOR trat in etwa 11 % der Befunde in den kleinen Greenfield-Apps auf, stieg aber auf rund 28 % im neu geschriebenen CMS, wo sich dieselbe Lücke über Hunderte Endpunkte wiederholte. Die einzelne Brownfield-App trug 238 bestätigte Schwachstellen — mehr als beide Greenfield-Apps zusammen (196) — und zeigt, dass KI-gestützte Neuschreibungen das Risiko mit wachsendem Umfang konzentrieren.
Ist es sicher, KI-Coding-Tools in der Produktion einzusetzen?
Ja, mit Review. Der Produktivitätsgewinn ist real und die Modelle bewältigen gängige Injection-Bugs, aber ihre Ausgabe sollte nicht ungeprüft ausgeliefert werden. Halten Sie KI-geschriebenen Code in einem sicheren SDLC: automatisierte Sicherheitsprüfung in großem Umfang für die wiederkehrenden DoS-, Autorisierungs- und Secrets-Probleme, plus menschliche Ingenieure, die Threat Modeling und Architektur verantworten — dort, wo die Modelle versagen.
Was sollten Teams gegen Hardcoded Secrets in KI-generierten Apps tun?
Hardcoded und Default Secrets machten fast die Hälfte der kritischen Befunde aus. Nehmen Sie Secret-Scanning in die CI auf, um Commits zu blockieren, verlagern Sie Schlüssel in einen verwalteten Secrets-Store oder eine Environment-Injection, rotieren Sie jedes Credential, das je in Quellcode oder Vorlage auftauchte, und lassen Sie niemals einen Entwicklungs-Default eines Frameworks in die Produktion gelangen. Das sind günstige, automatisierbare Kontrollen, die die schwerste Klasse der Studie entfernen.
Quellen
SecurityWeek — Vibe-Coded Apps Riddled With Exploitable Security Flaws, 22. Juli 2026
Help Net Security — The AI code vulnerabilities that grow with your app, 23. Juli 2026
Cybersecurity News — What 434 AI-Generated Vulnerabilities Reveal About Secure Software Development, Juli 2026