Die verborgenen Gefahren der KI-Codierung

Obwohl die Vorteile von KI-Assistenten am Arbeitsplatz umstritten bleiben, bestehen in der Softwareentwicklung eher keine Zweifel. Dabei spielen LLMs viele Rollen – von der Umgestaltung und Dokumentation bis hin zum Erstellen ganzer Anwendungen. Zu den traditionellen Problemen der Informationssicherheit in der Entwicklung kommen jetzt jedoch die einzigartigen Schwachstellen von KI-Modellen hinzu. An dieser Schnittstelle tauchen fast wöchentlich neue Fehler und Probleme auf.

Anfälliger KI-generierter Code

Von LLM generierter Code kann Fehler oder Sicherheitslücken enthalten. Schließlich werden diese Modelle mit öffentlich verfügbaren Daten aus dem Internet trainiert – einschließlich Tausenden von Beispielen für minderwertigen Code. Eine aktuelle Studie von Veracode hat ergeben, dass führende KI-Modelle heute Code produzieren, der sich in 90 % der Fälle erfolgreich kompilieren lässt. Vor weniger als zwei Jahren waren es weniger als 20 %. Die Sicherheit dieses Codes hat sich jedoch nicht verbessert – 45 % enthalten immer noch klassische Schwachstellen aus der OWASP-Top-10-Liste, mit geringen Änderungen in den letzten zwei Jahren. Die Studie umfasste über hundert gängige LLMs und Codefragmente in Java, Python, C# und JavaScript. Unabhängig davon, ob das LLM für die „Code-Vervollständigung“ in Windsurf oder für die „Vibe-Codierung“ in Loveable verwendet wird, muss die endgültige Anwendung gründlichen Schwachstellentests unterzogen werden. In der Praxis kommt dies jedoch selten vor: Laut einer Wiz-Studie weisen 20 % der Vibe-codierten Apps schwerwiegende Schwachstellen oder Konfigurationsfehler auf.

Als Beispiel für solche Schwachstellen wird häufig die Dating-App Tea genannt, die nur für Frauen zugänglich ist und nach zwei großen Datenlecks in Verruf geraten ist. Diese App ist jedoch älter als die Vibe-Codierung. Ob die KI schuld an Teas Schwächen war, wird vor Gericht entschieden. Im Fall des Startups Enrichlead war jedoch eindeutig die KI schuld. Der Gründer prahlte in den sozialen Medien damit, dass der Code seiner Plattform zu 100 % von Cursor AI geschrieben sei und „null handgeschriebenen Code“ enthalte. Nur wenige Tage nach seiner Veröffentlichung wurde festgestellt, dass der Code voller stümperhafter Sicherheitslücken war, und es jedem ermöglichte, auf kostenpflichtige Funktionen zuzugreifen oder Daten zu ändern. Das Projekt wurde beendet, nachdem es dem Gründer nicht gelungen war, den Code mit Cursor auf einen akzeptablen Sicherheitsstandard zu bringen. Er lässt sich jedoch nicht beirren und hat seitdem neue Projekte auf der Grundlage von Vibe-Coding gestartet.

Häufige Schwachstellen in KI-generiertem Code

Obwohl es die KI-unterstützte Programmierung erst seit ein oder zwei Jahren gibt, gibt es bereits genügend Daten, um die häufigsten Fehler zu identifizieren. Typischerweise sind dies:

• Fehlende Eingabevalidierung, keine Bereinigung von Benutzereingaben durch überflüssige Zeichen und andere grundlegende Fehler, die zu klassischen Schwachstellen wie Cross-Site-Scripting (XSS) und SQL-Injektion führen.
• API-Schlüssel und andere Geheimnisse, die direkt in die Webseite integriert und für Benutzer im Code sichtbar sind.
• Vollständig auf Client-Seite implementierte Authentifizierungslogik, direkt im Code der Webseite, der im Browser ausgeführt wird. Diese Logik kann leicht geändert werden, um alle Prüfungen zu umgehen.
• Protokollierungsfehler – von unzureichender Filterung beim Schreiben in Protokolle bis hin zum vollständigen Fehlen von Protokollen.
• Zu leistungsstarke und gefährliche Funktionen – KI-Modelle sind so optimiert, dass sie Code ausgeben, der eine Aufgabe auf dem kürzesten Weg löst. Doch der kürzeste Weg ist oft unsicher. Ein Beispiel aus dem Lehrbuch ist die Verwendung der eval-Funktion für mathematische Operationen mit Benutzereingaben. Sie öffnet die Tür zur Ausführung beliebigen Codes in der generierten Anwendung.
• Veraltete oder nicht vorhandene Abhängigkeiten. KI-generierter Code verweist oft auf alte Versionen von Bibliotheken, führt veraltete oder unsichere API-Aufrufe aus oder versucht sogar, fiktive Bibliotheken zu importieren. Letzteres ist besonders gefährlich, da Angreifer eine schädliche Bibliothek mit einem „plausiblen“ Namen erstellen können, die der KI-Agent in ein echtes Projekt einfügt.

In einer systematischen Studie haben die Autoren KI-generierten Code auf Schwachstellen untersucht, die in der MITRE CWE Top 25-Liste enthalten sind. Die häufigsten Probleme waren CWE-94 (Code-Injektion), CWE-78 (OS-Befehls-Injektion), CWE-190 (Ganzzahlüberlauf), CWE-306 (fehlende Authentifizierung) und CWE-434 (unbeschränkter Datei-Upload).

Ein markantes Beispiel für CWE-94 war die kürzliche Unterwanderung der Nx-Plattform, über die wir bereits berichtet haben. Angreifern ist es gelungen, ein beliebtes Entwicklungstool mit einem Trojaner zu unterwandern, indem sie einen Token entwendeten, um neue Produktversionen veröffentlichen zu können. Beim Token-Diebstahl wurde eine Schwachstelle ausgenutzt, die durch ein einfaches, von der KI generiertes Codefragment verursacht wurde.

Gefährliche Eingabeaufforderungen

Auch für die Arbeit mit einem KI-Assistenten gilt der unter Entwicklern bekannte Spruch „Ausführung exakt entsprechend der Spezifikation“. Wenn die Aufforderung zum Erstellen einer Funktion oder Anwendung vage ist und Sicherheitsaspekte nicht erwähnt werden, steigt die Wahrscheinlichkeit, dass Code mit Schwachstellen generiert wird. Eine spezielle Studie ergab, dass selbst allgemeine Bemerkungen wie „Stelle sicher, dass der Code den Best Practices für sicheren Code folgt“ die Rate der Schwachstellen um die Hälfte reduzierte.

Der effektivste Ansatz besteht jedoch darin, detaillierte, sprachspezifische Sicherheitsrichtlinien zu verwenden, die sich auf MITRE- oder OWASP-Fehlerlisten beziehen. Eine große Sammlung solcher Sicherheitsanweisungen von Wiz Research ist auf GitHub verfügbar. Es wird empfohlen, sie über Dateien wie claude.md, .windsurfrules oder Ähnliches zu den Systemaufforderungen der KI-Assistenten hinzuzufügen.

Verschlechterung der Sicherheit während der Revision

Wenn KI-generierter Code wiederholt anhand von Folgeabfragen überprüft wird, verschlechtert sich die Sicherheit. In einer aktuellen Studie sollte GPT-4o zuvor geschriebenen Code bis zu 40 Mal ändern, während die Forscher alle diese Versionen auf Schwachstellen überprüften. Nach nur fünf Iterationen enthielt der Code 37 % mehr kritische Schwachstellen als die ursprüngliche Version. In der Studie wurden vier Aufforderungsstrategien getestet, von denen drei jeweils unterschiedliche Schwerpunkte hatten: (i) Leistung, (ii) Sicherheit und (iii) neue Funktionalität; der vierte wurde mit unklaren Aufforderungen geschrieben.

Bei Eingabeaufforderungen, die sich auf das Hinzufügen neuer Funktionen konzentrierten, wurden 158 Schwachstellen angezeigt – darunter 29 kritische. Als in der Eingabeaufforderung die Bedeutung von sicherer Codierung hervorgehoben wurde, ging die Zahl deutlich zurück – umfasste jedoch immer noch 38 neue Schwachstellen, von denen sieben kritisch waren.

Interessanterweise führten die „sicherheitsorientierten“ Eingabeaufforderungen zum höchsten Prozentsatz an Fehlern bei kryptografischen Funktionen.

Ignorieren des Branchenkontexts

In Branchen wie dem Finanzwesen, dem Gesundheitswesen und der Logistik gibt es technische, organisatorische und rechtliche Anforderungen, die bei der Entwicklung von Apps berücksichtigt werden müssen. KI-Assistenten sind sich dieser Einschränkungen nicht bewusst. Dieses Problem wird oft als „fehlende Tiefe“ bezeichnet. Infolgedessen werden die Speicher- und Verarbeitungsmethoden für persönliche, medizinische und finanzielle Daten, die durch lokale oder branchenspezifische Vorschriften vorgeschrieben sind, nicht im KI-generierten Code berücksichtigt. Ein Assistent kann beispielsweise eine mathematisch korrekte Funktion zur Berechnung der Einlagenzinsen schreiben, aber die von den Aufsichtsbehörden vorgeschriebenen Rundungsregeln ignorieren. Die Vorschriften für Daten im Gesundheitswesen erfordern oft eine detaillierte Protokollierung jedes Zugriffsversuchs – etwas, das KI nicht automatisch mit der richtigen Detaillierung implementiert.

Falsche Programmkonfiguration

Schwachstellen beschränken sich nicht auf den Vibe-Code selbst. Anwendungen, die durch Vibe-Codierung erstellt wurden, werden oft von unerfahrenen Benutzern erstellt, die die Laufzeitumgebung entweder überhaupt nicht konfigurieren oder sie gemäß den Anweisungen derselben KI konfigurieren. Dies führt zu gefährlichen Fehlkonfigurationen:

• Datenbanken, die vom Programm benötigt werden, werden mit zu weit gefassten Berechtigungen für den externen Zugriff erstellt. Dies führt zu Lecks wie Tea/Sapphos, bei denen der Angreifer nicht einmal das Programm verwenden muss, um die gesamte Datenbank herunterzuladen oder zu löschen.
• Interne Unternehmensanwendungen bleiben der Öffentlichkeit ohne Authentifizierung zugänglich.
• Anwendungen erhalten erhöhte Zugriffsberechtigungen für kritische Datenbanken. In Kombination mit den Schwachstellen von KI-generiertem Code vereinfacht dies SQL-Injektionen und ähnliche Angriffe.

Schwachstellen auf Plattformen

Die meisten Plattformen zur Vibe-Codierung führen Anwendungen, die aus Eingabeaufforderungen generiert werden, direkt auf ihren eigenen Servern aus. Dies bindet Entwickler an die Plattform – einschließlich der Anfälligkeit für ihre Schwachstellen und der Abhängigkeit von ihren Sicherheitspraktiken. Im Juli wurde beispielsweise in der Plattform Base44 eine Schwachstelle entdeckt, die es nicht authentifizierten Angreifern ermöglichte, auf beliebige private Programme zuzugreifen.

Bedrohungen in der Entwicklungsphase

Schon das Vorhandensein eines Assistenten mit umfassenden Zugriffsrechten auf dem Computer des Entwicklers birgt Risiken. Hier einige Beispiele:

Die Schwachstelle CurXecute (CVE-2025-54135) ermöglichte es Angreifern, dem beliebten KI-Entwicklungstool Cursor zu befehlen, beliebige Befehle auf dem Computer des Entwicklers auszuführen. Dazu war lediglich ein aktiver Model Context Protocol-Server (MCP) erforderlich, der mit Cursor verbunden ist und auf den eine externe Person zugreifen kann. Dies ist eine typische Situation – MCP-Server gewähren KI-Agenten Zugriff auf Slack-Nachrichten, Jira-Probleme und so weiter. Injektionen in Eingabeaufforderungen können über jeden dieser Kanäle erfolgen.

Die Schwachstelle EscapeRoute  CVE-2025-53109) ermöglichte es, beliebige Dateien auf der Festplatte des Entwicklers zu lesen und zu schreiben. Der Fehler existierte in dem beliebten MCP-Server von Anthropic, der es KI-Agenten ermöglicht, Dateien im System zu schreiben und zu lesen. Die Zugriffsbeschränkungen des Servers funktionierten einfach nicht.

Ein schädlicher MCP-Server, mit dem KI-Agenten gleichzeitig E-Mails über Postmark senden und empfangen können, leitete die gesamte Korrespondenz an eine versteckte Adresse weiter. Wir haben das Auftreten solcher schädlicher MCP-Server bereits im September vorhergesagt.

Eine Schwachstelle in der Gemini-Befehlszeilenschnittstelle ermöglichte die Ausführung eines beliebigen Befehls, wenn ein Entwickler den KI-Assistenten aufforderte, den Code eines neuen Projekts zu analysieren. Die schädliche Injektion wurde von einer readme.md-Datei ausgelöst.

Die Erweiterung Q Developer von Amazon für Visual Studio Code enthielt kurzzeitig eine Anleitung zum Löschen aller Daten auf dem Computer eines Entwicklers. Ein Angreifer nutzte einen Fehler der Amazon-Entwickler aus und schaffte es, diese schädliche Eingabeaufforderung ohne besondere Berechtigungen in den öffentlichen Code des Assistenten einzufügen. Glücklicherweise verhinderte ein kleiner Codierungsfehler die Ausführung.

Eine Schwachstelle im Claude Code-Agenten (CVE-2025-55284) ermöglichte es, Daten über DNS-Anfragen vom Computer eines Entwicklers zu abzurufen. Die Eingabeaufforderung, die auf gängigen Dienstprogrammen beruht, die automatisch und ohne Bestätigung ausgeführt werden, kann in jeden vom Agenten analysierten Code eingebettet werden.

Der autonome KI-Agent Replit löschte die primären Datenbanken eines von ihm entwickelten Projekts, da er zu dem Schluss kam, dass die Datenbank bereinigt werden musste. Dies verstieß gegen eine direkte Anweisung, die Änderungen verbietet (Code Freeze). Hinter diesem unerwarteten KI-Verhalten verbirgt sich ein wichtiger Architekturfehler – zu dieser Zeit gab es in Replit keine Trennung zwischen Test- und Produktionsdatenbanken.

Eine Eingabeaufforderung in einem Kommentar zum Quellcode veranlasste die Windsurf-Entwicklungsumgebung, schädliche Anweisungen automatisch im Langzeitspeicher abzulegen, so dass über Monate hinweg Daten aus dem System gestohlen werden konnten.

Beim Nx-Vorfall wurden Befehlszeilentools für Claude, Gemini und Q verwendet, um nach Passwörtern und Schlüsseln zu suchen, die von einem infizierten System gestohlen werden könnten.

Tipps zur sicheren Nutzung von KI-generiertem Code

Das Risikoniveau durch KI-generierten Code kann durch eine Kombination aus organisatorischen und technischen Maßnahmen erheblich, aber nicht vollständig reduziert werden:

• Implementiere mithilfe optimierter SAST-Tools eine automatische Überprüfung von KI-generiertem Code, während er geschrieben wird.
• Bette Sicherheitsanforderungen in die Systemeingabeaufforderungen aller KI-Umgebungen ein.
• Lasse erfahrene menschliche Spezialisten detaillierte Code-Überprüfungen durchführen, die von speziellen KI-basierten Sicherheitsanalyse-Tools unterstützt werden, um die Effektivität zu erhöhen.
• Schule Entwickler darin, sichere Eingabeaufforderungen zu schreiben, und biete ihnen grundsätzlich vertiefende Ausbildung im sicheren Umgang mit KI an.