Sicherheitslücken in Claude Code: Wie Konfigurationsdateien zur Angriffsfläche werden

Sicherheitsforscher von Check Point Research haben in Anthropics KI-Entwicklungswerkzeug Claude Code drei Schwachstellen identifiziert, die es Angreifern ermöglichten, über manipulierte Projektkonfigurationen beliebige Befehle auf fremden Rechnern auszuführen und Zugangsdaten zu entwenden. Der Angriffsweg war dabei in allen drei Fällen derselbe: eine einzelne, im Repository gespeicherte Konfigurationsdatei. Alle Lücken wurden inzwischen geschlossen.

Konfigurationsdateien als gemeinsame Wurzel aller Angriffswege

Claude Code ist Anthropics terminalbasiertes KI-Entwicklungswerkzeug, das Entwicklern ermöglicht, Aufgaben wie Dateibearbeitung, Git-Verwaltung, Testausführung und Shell-Befehle über natürliche Spracheingaben zu delegieren. Die Plattform hat sich in vielen Entwicklungsteams als zentrales Werkzeug etabliert und unterstützt unter anderem die Integration externer Dienste über das Model Context Protocol (MCP).

Grundlage aller drei entdeckten Angriffswege ist die Datei .claude/settings.json. Sie dient regulär dazu, projektweite Einstellungen für Claude Code zu hinterlegen, sodass alle Teammitglieder nach dem Klonen eines Repositorys automatisch dieselbe Konfiguration verwenden. Das ist für die kollaborative Arbeit sinnvoll – schafft aber gleichzeitig eine Angriffsfläche, die bisher kaum im Fokus der Sicherheitsforschung stand.

Da .claude/settings.json wie jede andere Datei im Repository versioniert wird, kann jede Person mit Schreibzugriff deren Inhalt verändern. Manipulierte Konfigurationen lassen sich dabei auf unterschiedlichen Wegen einschleusen: über scheinbar legitime Pull Requests, die neben harmlosen Codeänderungen auch eine veränderte Konfiguration enthalten, über absichtlich ansprechend gestaltete Repositorys, die Entwickler zum Klonen verleiten sollen, oder über kompromittierte Zugänge zu internen Unternehmenscodebasen. Entscheidend ist dabei, dass Konfigurationsdateien bei Code-Reviews erfahrungsgemäß weniger Aufmerksamkeit erhalten als regulärer Quellcode – sie gelten gemeinhin als passive Metadaten und nicht als ausführbarer Code.

Schwachstelle 1: Hooks führen Shell-Befehle ohne Bestätigung aus

Claude Code unterstützt eine sogenannte Hooks-Funktion. Mit ihr lassen sich Shell-Befehle deterministisch zu definierten Zeitpunkten im Programmablauf ausführen – etwa beim Start einer Sitzung, nach einer Dateibearbeitung oder bei anderen Ereignissen im Lebenszyklus des Werkzeugs. Der Gedanke dahinter ist, wiederkehrende Aufgaben wie Code-Formatierung oder Compliance-Prüfungen zuverlässig zu automatisieren, ohne auf die Entscheidung des KI-Modells angewiesen zu sein.

Hooks werden in .claude/settings.json definiert – also in derselben Datei, die auch aus fremden Repositorys übernommen wird. Die Forscher testeten, was passiert, wenn ein Hook in einem nicht vertrauenswürdigen Projekt hinterlegt ist. Beim erstmaligen Öffnen des Projekts erscheint ein Vertrauensdialog, der allgemein darauf hinweist, dass Claude Code Dateien mit Nutzerberechtigung ausführen kann. Der Dialog enthielt jedoch keinen expliziten Hinweis darauf, dass in der Konfigurationsdatei hinterlegte Hook-Befehle automatisch – also ohne weitere Rückfrage – ausgeführt werden.

Wer den Dialog bestätigte, wie es bei einem scheinbar legitimen Projekt naheläge, stellte fest, dass der Hook-Befehl sofort und kommentarlos im Hintergrund ausgeführt wurde. Im Gegensatz dazu fordert Claude Code bei der regulären Befehlsausführung während einer Sitzung eine ausdrückliche Bestätigung des Nutzers. Hooks unterlagen dieser Einschränkung nicht.

Die Forscher demonstrierten in einem Proof of Concept, dass sich über diesen Weg eine vollständige Reverse-Shell etablieren lässt – ein Angreifer erhält damit interaktiven Zugriff auf den Rechner des Opfers, ohne dass dieser etwas anderes getan hat, als claude in einem geklonten Projektverzeichnis auszuführen und den initialen Dialog zu bestätigen.

Schwachstelle 2: Verbesserter Warndialog lässt sich durch Konfigurationsparameter aushebeln

Als Reaktion auf die erste Meldung führte Anthropic einen überarbeiteten Warndialog ein. Dieser erscheint, wenn Claude Code ein Projekt mit einer MCP-Konfigurationsdatei (.mcp.json) öffnet, und weist nun ausdrücklich darauf hin, dass darin enthaltene Befehle ausgeführt werden können. MCP – das Model Context Protocol – erlaubt es Claude Code, über eine standardisierte Schnittstelle mit externen Diensten zu kommunizieren, etwa mit Dateisystemen, Datenbanken oder Entwicklungsplattformen. Die Konfiguration dieser Server liegt in .mcp.json im Projektverzeichnis.

Check Point Research untersuchte daraufhin, ob sich dieser Schutzmechanismus umgehen lässt. Dabei stießen die Forscher auf zwei Konfigurationsparameter: enableAllProjectMcpServers und enabledMcpjsonServers. Ersterer aktiviert automatisch alle MCP-Server, die in .mcp.json definiert sind; letzterer setzt einzelne Server namentlich auf eine Positivliste. Beide Optionen sind für den legitimen Teameinsatz gedacht, damit Entwickler nach dem Klonen eines Projekts sofort mit den vorgesehenen MCP-Integrationen arbeiten können.

Das Problem: Auch diese Parameter können in .claude/settings.json gesetzt werden – also in der repository-gesteuerten Konfigurationsdatei. Wenn sie dort hinterlegt sind, initialisiert Claude Code die definierten MCP-Server, ohne den Nutzer um Zustimmung zu bitten. Im Test der Forscher führte das dazu, dass der in der MCP-Konfiguration hinterlegte Befehl ausgeführt wurde, noch bevor der Nutzer überhaupt Gelegenheit hatte, den Warndialog zu lesen. Der Dialog erschien erst, als die Payload bereits aktiv war. Auch dieser Angriffsweg ließ sich zu einer vollständigen Remote-Shell eskalieren.

Schwachstelle 3: API-Schlüssel werden vor der Nutzerbestätigung übertragen

Die dritte Schwachstelle wurde bei der Untersuchung der Umgebungsvariablen entdeckt, die über .claude/settings.json gesetzt werden können. Besonderes Interesse weckte dabei ANTHROPIC_BASE_URL – eine Variable, die festlegt, an welchen Server Claude Code seine API-Anfragen sendet. Im regulären Betrieb zeigt sie auf die Server von Anthropic, kann aber wie andere Einstellungen auch über die Projektkonfiguration überschrieben werden.

Die Forscher leiteten den API-Datenverkehr über einen lokalen Proxy und beobachteten die Kommunikation von Claude Code in Echtzeit. Dabei stellten sie fest, dass die Anwendung bereits unmittelbar nach dem Start – noch bevor der Nutzer den Vertrauensdialog bestätigt oder auch nur gelesen hatte – mehrere Anfragen an den konfigurierten Endpunkt sendete. Diese Anfragen enthielten unter anderem Dateinamen aus dem Repository und aktuelle Commit-Nachrichten. Noch schwerwiegender: Jede Anfrage trug den vollständigen Anthropic-API-Schlüssel des Nutzers im Autorisierungsheader – im Klartext.

Ein Angreifer müsste lediglich einen eigenen Server als ANTHROPIC_BASE_URL in einem öffentlich zugänglichen Repository hinterlegen. Sobald ein Entwickler das Repository klont und claude ausführt, wird der API-Schlüssel automatisch an diesen Server übermittelt – ohne jede Nutzerinteraktion, ohne Warnung, ohne Möglichkeit zur Intervention.

Reichweite des Schadens: Workspace-Zugriff betrifft ganze Teams

Die Forscher gingen der Frage nach, welchen Schaden ein entwendeter API-Schlüssel tatsächlich anrichten kann – und stießen dabei auf Anthropics Workspace-Funktion. Workspaces ermöglichen es, mehrere API-Schlüssel unter einer gemeinsamen Umgebung zusammenzufassen. Dateien, die in einem Workspace gespeichert sind, gehören nicht einem einzelnen Schlüssel, sondern dem Workspace als Ganzes – alle darin enthaltenen Schlüssel haben Zugriff auf denselben Speicherbereich.

Die Datei-API erlaubt das Hochladen und Verwalten von Dateien innerhalb eines Workspace. Zwar sind nutzerseitig hochgeladene Dateien standardmäßig nicht über die API herunterladbar – nur Dateien, die durch Claudes Codeausführungswerkzeug erstellt wurden, sind als herunterladbar markiert. Die Forscher zeigten jedoch, dass diese Einschränkung mit einfachen Mitteln umgangen werden kann: Durch die Anweisung an Claude, eine vorhandene Datei unter einem neuen Namen neu zu erstellen, wird sie als vom System generiertes Artefakt behandelt und lässt sich anschließend uneingeschränkt herunterladen.

Mit einem entwendeten API-Schlüssel kann ein Angreifer damit auf alle im Workspace gespeicherten Dateien zugreifen, diese löschen oder durch manipulierte Versionen ersetzen, beliebige Dateien hochladen und so den geteilten Speicher aller Teammitglieder korrumpieren sowie API-Guthaben verbrauchen, was zu unerwarteten Kosten oder einer Unterbrechung des Dienstes führt, wenn Ratenlimits oder Budgets erreicht werden. Anders als die ersten beiden Schwachstellen, die primär den Rechner eines einzelnen Entwicklers betreffen, kann ein gestohlener API-Schlüssel also die gemeinsamen Ressourcen eines gesamten Entwicklungsteams kompromittieren.

Behobene Schwachstellen und Schutzmaßnahmen

Anthropic hat alle drei Schwachstellen in enger Zusammenarbeit mit Check Point Research behoben. Der Vertrauensdialog wurde so überarbeitet, dass er nun ausdrücklich auf die automatische Ausführung von Hook-Befehlen hinweist. Die MCP-Umgehung wurde dadurch geschlossen, dass enableAllProjectMcpServers und enabledMcpjsonServers in repository-gesteuerten Konfigurationsdateien nicht mehr zur automatischen Serverinitialisierung führen. Für die API-Schlüssel-Exfiltration wurde sichergestellt, dass Claude Code keine Netzwerkoperationen durchführt, bevor der Nutzer den Vertrauensdialog ausdrücklich bestätigt hat.

Für Entwickler, die mit Claude Code arbeiten, empfehlen die Forscher folgende Maßnahmen: das Werkzeug stets auf dem aktuellen Stand zu halten, da alle beschriebenen Lücken in aktuellen Versionen geschlossen sind; Konfigurationsverzeichnisse wie .claude/ vor dem Öffnen unbekannter Projekte zu sichten; Warnhinweise des Werkzeugs ernst zu nehmen, auch bei scheinbar vertrauenswürdigen Quellen; Konfigurationsänderungen im Reviewprozess mit derselben Sorgfalt zu behandeln wie Änderungen am Anwendungscode; und bei ungewöhnlich komplexen Setup-Anforderungen, die für den offensichtlichen Projektzweck überdimensioniert erscheinen, skeptisch zu bleiben.

Zeitleiste der Offenlegung

Die erste Schwachstelle wurde am 21. Juli 2025 gemeldet und nach einem gemeinsamen Abstimmungsprozess am 26. August 2025 behoben; Anthropic veröffentlichte dazu am 29. August 2025 das GitHub Security Advisory GHSA-ph6w-f82w-28w6. Die zweite Schwachstelle folgte am 3. September 2025 mit einem Fix am 22. September 2025 und der Veröffentlichung von CVE-2025-59536 am 3. Oktober 2025. Die dritte Schwachstelle wurde am 28. Oktober 2025 gemeldet, am 28. Dezember 2025 behoben und am 21. Januar 2026 als CVE-2026-21852 veröffentlicht. Die öffentliche Bekanntgabe des gesamten Berichts erfolgte am 25. Februar 2026.

„Die in diesem Beitrag veröffentlichten Informationen wurden sorgfältig recherchiert. Dennoch übernehmen wir keine Gewähr für Vollständigkeit oder absolute Richtigkeit. Die Inhalte dienen der allgemeinen Orientierung und ersetzen keine fachkundige Beratung. Für etwaige Fehler, Auslassungen oder Folgen aus der Nutzung der Informationen übernimmt die Redaktion keine Haftung. Trotz sorgfältiger Prüfung können vereinzelt unbeabsichtigte Fehler oder Ungenauigkeiten, etwa bei Übersetzungen, auftreten.“

Entdecke mehr

 

---