16. November 2025

Sicherheitslücke bei Claude: Wie Code Interpreter zum trojanischen Pferd für Datenklau werden kann

Die rasante Entwicklung von Künstlicher Intelligenz eröffnet in der Praxis ungeahnte Möglichkeiten für Automatisierung, Kooperationsmodelle, kreatives Arbeiten und den Zugriff auf Online-Ressourcen. Doch mit wachsender Funktionalität steigt auch die Angriffsoberfläche für Missbrauch und Kompromittierung. Ein aktueller Fall rückt die Plattform Claude ins Zentrum der Aufmerksamkeit: Die in Claude eingebaute Code-Interpreter-Funktion, die eigentlich eine innovative Brücke zwischen KI und Softwareentwicklung schlägt, kann zur unerwarteten Datenquelle für Angreifer werden – legal, dokumentiert und kaum durch Standardkonfigurationen abgesichert.

Der Kern der Problematik liegt in der Ausweitung der Berechtigungen im Netzwerk-Modus. Code Interpreter kann im Standardmodus auf eine Whitelist explizit erlaubter Domains zugreifen, darunter npm, PyPI und api.anthropic.com. Letzterer Zugang öffnet das Tor zum Files API, einem Schnittstellenservice der Anthropic-Plattform, mit der Dateien an einen Account geknüpft, abgerufen und verarbeitet werden können.

Die Angriffsmethode nutzt eine harmlose Umgebung als Startpunkt. Eine sogenannte „Prompt Injection” weist die KI an, einen lesbaren Inhalt – etwa aus dem Chatverlauf oder einem generierten Report – in ein File zu schreiben, z. B. /mnt/user-data/outputs/hello.md. Direkt darauf folgt die eigentliche Übertragung: Die KI erhält per Programmcode den Auftrag, das File via Files API an einen Account zu senden, dessen Authentifizierung über einen vom Angreifer kontrollierten Schlüssel erfolgt. Ist der Schlüssel unbekannt, ist der Transfer nicht möglich – enthält er aber die Daten eines Angreifers, wird die Datei problemlos dem fremden Konto zugeordnet und dort abrufbar.

Besonders kritisch ist, dass dieser Mechanismus auf dem offiziellen, dokumentierten und funktionalen Workflow von Anthropic basiert. Es handelt sich nicht um einen klassischen Hack, sondern um das Ausnutzen der festgelegten Strukturen. Im Ergebnis können Chatinhalte, Protokolle, Bilddaten, Programmcodes oder beliebige Outputs aus Sandboxes extrahiert und auf fremde Server transferiert werden – bis zu einer Dateigröße von 30 MB pro Upload, und das in unbegrenzter Zahl durch aufeinanderfolgende Requests.

Der initiale Angriff war einfach. Eine verdächtige Anfrage wurde erfolgreich ausgeführt, bevor die KI begann, offensichtliche Schlüssel und bösartige Instruktionen abzulehnen. Doch die Filtermechanik ist selbst mit der Zeit keinesfalls verlässlich. Sicherheitsforscher fanden Wege, kritischen Code und Schlüssel durch Verschleierung, Encoding und Einbettung zwischen harmlosen Kommandos an der Prüfstelle vorbeizuschleusen. Erfolgreicher sind Angriffe, die sich in einen Strom aus Alltagsbefehlen mischen und nicht als Einzeloperation auffallen.

Die Response des Anbieters zeigt die Herausforderungen eines modernen Responsible Disclosure. Initial meldeten Forscher das Problem via HackerOne am 25. Oktober 2025, doch die Reaktion war verhalten. Das Thema wurde als Frage der Modell- und KI-Sicherheit eingeordnet und nicht als klassische Produktschwachstelle akzeptiert – also der berühmte „Not our Problem“-Approach. Erst nach mehreren Tagen wurde die Gefahr anerkannt und die Lücke offiziell quantifiziert. Es bestätigt sich, dass KI-Schnittstellen und API-Mechanismen einer strengen, kontinuierlichen Revision bedürfen, weil sich Missbrauch oft jenseits etablierter Bug-Klassen abspielt.

Ein unterschätzter Aspekt ist die „indirekte” Prompt Injection. Nicht nur direkte CLI-Befehle, sondern auch eingebettete Instruktionen in Dokumenten oder Fremdquellen können von der KI als Befehl interpretiert werden. Die KI liest zum Beispiel eine PDF oder einen CSV-Report, erkennt einen eingebetteten funktionsähnlichen Prompt und verarbeitet diesen als Kommando – erst Recht, wenn die Datei in einem eingespielten, authorisierten Arbeitsprozess landet. Damit werden klassische Trennungslinien zwischen Benutzerinput und Administrator-Steuerung potenziell ausgehebelt.

Ein weiteres Abuse-Szenario ist nicht der reine Datenabfluss, sondern die Ausführung von Kommandos als Teil einer C2-Logik: Die KI empfängt Steuerbefehle, führt sie aus und verbindet sich zu exfiltrierten Schnittstellen. Damit eröffnet Claude in der jetzigen Konfiguration faktisch einen Kanal für Remote Control, Automatisierung unerwünschter Vorgänge und Recovery nach Kompromittierung. Die Lücke transformiert also das Code-Interpreter-Feature in ein umfassendes Risiko für „Command and Control“-Szenarien in KI-Umgebungen.

Zur Eindämmung entwickeln Sicherheitsforscher und Anbieter mehrere Vorschläge. Der zentrale Punkt ist die zwingende Identifikation der Nutzer-Session: Sämtliche Dateien, die von der Sandbox per Files API übertragen werden, müssen mit der authentifizierten, loginbasierten User-ID verknüpft sein. Damit wird die Praxis des Herausgebens der ANTHROPIC_API_KEY-Daten auf fremde Accounts blockiert. Alternativ empfiehlt sich die vollständige Deaktivierung der Files-API für normalen Nutzer-Code, um Datenlecks grundsätzlich zu verhindern.

Eine weitere Maßnahme ist die Echtzeit-Analyse und das Monitoring von Netzwerk- und Files-Requests in der Sandbox, inklusive des Einbaus automatisierter Filter, die auffällige Muster sofort erkennen und Sessions gezielt stoppen können. Da heute in KI-Betriebssystemen oft ein offener, generischer Zugriff auf verschiedene Domains und Apis erlaubt ist, empfiehlt es sich, die Whitelist radikal zu beschränken und Ressourcen wirklich nur für unbedingt erforderliche Workflows freizugeben.

Für Anwender – Unternehmen wie Einzelpersonen – bleibt aktuell vor allem die Option, network access komplett abzuschalten, wenn keine zwingende Notwendigkeit besteht. Nur offensichtliches Allow-Listing einzelner Ressourcen, strikte Account-Isolation und manuelle Kontrolle der Datenströme bieten ausreichenden Schutz gegen die hier beschriebenen Angriffsvektoren.

Das Beispiel Claude steht für einen grundsätzlichen Kulturwandel im Umgang mit KI-Tools. Immer mehr Schnittstellen, Programme und Modelle verfügen über automatisierte Zugriffsmöglichkeiten auf Online-Ressourcen und lokale Datenspeicher. Die Code-Ausführung in der KI-Sandbox ist per se keine Schwachstelle, solange die Rechte, API-Keys und Output-Funktionen sorgfältig konfiguriert sind. Doch die Praxis zeigt, dass Dokumentation und Produktdesign oft weit hinter den potenziellen Gefahren zurückbleiben – und dass Sicherheitsmanagement bei modernen KI-Diensten eine ganz neue Aufmerksamkeit verlangt.

Die aktuelle Debatte um die Files-API und Prompt-Injektionen illustriert den „Shift Left”-Gedanken in der KI-Industrie: Sicherheitsmaßnahmen dürfen nicht erst nachträglich eingepflegt werden, sondern müssen bereits bei der Modellierung der Feature-Landschaft, beim API-Design und in der Erstkonfiguration von User- und Netzwerkrechten fest verankert sein. Prompt Filtering, Real-Time Auditing, Session Isolation und verlässliches Account-Binding sind heute unerlässlich für Plattformen mit Code-Interpreter-Mechaniken.

Abschließend lässt sich feststellen, dass die Erweiterung von KI-Umgebungen mit mächtigen Schnittstellen und Cloud-Workflows den Handlungsspielraum für Angreifer sowie Red Teams dramatisch vergrößert hat. Technische und organisatorische Maßnahmen müssen Hand in Hand greifen:

  • Verantwortliche KI-Anbieter und Plattformbetreiber sind in der Pflicht, sämtliche Einzelaktionen auf potenzielle Missbrauchsmöglichkeiten zu prüfen.
  • Anwender und Firmen sind angehalten, wie in klassischen IT-Umgebungen auch, granular zu kontrollieren, welche Zugriffsrechte, Tokens und Sessions physisch wie technisch legitimiert sind.
  • Die Debatte zeigt, wie dynamisch und anpassungsfähig Angreifer auf neue Technologieinnovationen reagieren.

Der Claude-Fall ist ein Weckruf für die gesamte Branche. Je größer die automatisierten, cloud- und API-basierten Funktionsumfänge in KI-Systemen werden, desto wichtiger ist ein Security-by-Design Ansatz, kontinuierliche Revision und Nachjustierung, Transparenz gegenüber dem Nutzer und effiziente Incident Response Prozesse. Nur so können die Chancen der Digitalisierung effizient genutzt werden, während die Risiken kontrollierbar und das Vertrauen der Nutzer gewahrt bleibt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.

Review Your Cart
0
Add Coupon Code
Subtotal