Das Repo sollte nicht über sein eigenes Vertrauen abstimmen dürfen

Am 24. April 2026 veröffentlichte Anthropic GHSA-q5hj-mxqh-vv77, einen Claude Code Trust-Dialog-Bypass mit einem CVSS-Wert von 7,7. Siebenunddreißig Tage zuvor, am 18. März, hatte dasselbe Projekt GHSA-mmgp-wc2j-qcv7 mit identischem CVSS-Wert veröffentlicht. Zwei Trust-Dialog-Bypässe in derselben Agent-Laufzeitumgebung innerhalb desselben Sechs-Wochen-Fensters sind kein Zufall.¹²

Die gemeinsame Form ist die Lehre. Beim März-Bug wurde die projektgesteuerte Datei .claude/settings.json vor der Workspace-Trust-Prüfung gelesen, und ein bypassPermissions-Berechtigungsmodus in dieser Datei erfüllte das Gate trivial.² Beim April-Bug liefert ein bösartiges Repository eine präparierte commondir-Datei innerhalb von .git/, der Trust-Evaluator folgt dem Verweis zu einem Verzeichnis, dem der Benutzer bereits vertraut, und der Workspace erbt dieses Vertrauen, ohne dass jemals der Dialog angezeigt wird.¹

Zwei Textzeilen innerhalb eines Repos, das niemand geöffnet hatte, konnten einen Workspace als vertrauenswürdig deklarieren. Die Oberflächen auf Projektebene, die das Repo mitliefert (Hooks, MCP-Server-Konfigurationen, Skills, Subagents), können dann gegen diese Abstimmung aufgelöst werden, sei es eifrig beim Sitzungsstart oder lazy bei Aufruf. Die nachgelagerten Verteidigungsmaßnahmen in jeder Agent-Laufzeitumgebung sind durch eine Entscheidung gesperrt, die die Laufzeit trifft, bevor sie überhaupt existieren.

TL;DR

• Zwei Claude Code Trust-Dialog-Bypass-CVEs in 37 Tagen zeigen, was bricht, wenn repo-gesteuerte Bytes das Workspace-Vertrauen beeinflussen.
• Die unmittelbare benutzerseitige Lösung besteht darin, auf eine Version nach 2.1.84 zu aktualisieren, vertrauenswürdige Pfade in ~/.claude.json einzuschränken und breite Eltern-Pfad-Vertrauensstellungen wie ~/Projects zu vermeiden.
• Die strukturelle Lösung ist eine Ladereihenfolgen-Invariante: Interpretieren Sie kein Workspace-Byte, bevor der Workspace-Pfad explizit als vertrauenswürdig eingestuft ist.

Was die beiden Advisories tatsächlich gepatcht haben

Liest man die Patches im Abgleich mit der Dokumentation, wird das Ladereihenfolgen-Versagen sichtbar. Die korrigierten Versionen ordnen neu, welche Bytes der Trust-Evaluator konsultieren darf.

Das März-Advisory beschreibt, dass Claude Code Projekteinstellungen auflöst, bevor das Workspace-Vertrauen aufgelöst wird. Die Korrektur in 2.1.53 kehrt diese Reihenfolge um, sodass die Trust-Prüfung nicht mehr .claude/settings.json aus dem Workspace liest, bevor der Benutzer entschieden hat.² Das April-Advisory beschreibt, dass der Trust-Evaluator der commondir-Datei im .git/-Verzeichnis eines Repositorys folgt, während er den Workspace-Pfad selbst auflöst. Die Korrektur in 2.1.84 hindert den Evaluator daran, repository-gesteuerten commondir-Inhalt während der Trust-Bewertung zu honorieren.¹ Beide Patches stellen dieselbe Invariante wieder her: Die Trust-Entscheidung darf keine Bytes konsultieren, die innerhalb des Kandidaten-Workspaces liegen.

Die CVE-Klassifizierungen weisen auf dieselbe Diagnose hin. Der März-Bug ist als CWE-807 gemeldet, Reliance on Untrusted Inputs in a Security Decision.³ Der April-Bug ist als CWE-20 plus CWE-77 gemeldet, Improper Input Validation und Improper Neutralization of Special Elements, weil die commondir-Auflösung repository-gesteuerte Bytes als autoritativ behandelte.¹ Verschiedene CWEs, dieselbe gebrochene Annahme: ein Sicherheits-Gate, das aus dem Artefakt liest, das es eigentlich absichern soll.

Die Pre-Trust-Oberfläche ist breiter, als die Settings-Referenz vermuten lässt

Claude Code dokumentiert eine Reihe projektgesteuerter Sitzungsstart-Oberflächen, die hinter dem Trust-Gate verbleiben müssen. Die beiden CVEs in dieser Klasse beweisen, dass die Invariante bricht, sobald eine von ihnen in die Trust-Entscheidung selbst einfließt. Die Oberflächen teilen sich in zwei Geltungsbereiche, die die Trust-Analyse getrennt halten muss: Bytes, die mit einem geklonten Repository ausgeliefert werden, und Bytes, die ein Benutzer einem Workspace lokal hinzufügt, ohne sie zu committen.⁴⁵⁶⁷

Repo-committete Oberflächen (werden mit git clone ausgeliefert). Dies ist die Lieferketten-Oberfläche. Alles in dieser Gruppe ist das, was ein Angreifer kontrolliert, wenn er ein bösartiges Repository erstellt.

Workspace-lokale Oberflächen (standardmäßig nicht committet). Diese gelangen nicht über die Lieferkette in den Workspace; sie erscheinen, wenn ein lokaler Benutzer sie erstellt. Sie liegen dennoch innerhalb des Workspace-Pfads, sodass das Trust-Gate sie weiterhin als nicht vertrauenswürdig behandeln muss, bis der Pfad genehmigt ist.

Hooks leben innerhalb von .claude/settings.json statt in einer separaten Datei; das April-Advisory beschreibt, wie der Angreifer diesen Schlüssel direkt befüllt.¹⁶ Der April-Bug enthüllte zudem eine Oberfläche, die überhaupt nicht Teil der Claude Code-Konfigurationsreferenz ist: eine git-interne Datei namens commondir, die einen Worktree zurück zum übergeordneten Repository auflöst.⁸ Ein bösartiges Repository, das ein präpariertes commondir-Layout ausliefert, erbt das Vertrauen des Zielpfads, wenn Claude Code dem Verweis während der Trust-Bewertung folgt. Die git-interne Oberfläche durchbrach die Zählung der Projekt-Konfigurations-Oberflächen, und genau das ist die eigentliche Lehre. Die Taxonomie ist nicht abgeschlossen. Die Angriffsfläche wird definiert durch welche Bytes gelesen werden, bevor der Dialog ausgelöst wird, und alles, was die Pfadauflösung oder Konfiguration beeinflussen kann, ist Freiwild.

Das Muster ist dasselbe, das MCP Servers Are the New Attack Surface auf einer anderen Höhe benannt hat.⁹ MCP-Server haben die Tool-Anbieter-Oberfläche zur Explosion gebracht, bevor das Ökosystem die Implikationen einholte. Trust-Dialog-Bypass ist dieselbe Form eine Schicht tiefer. Jede Komfortfunktion, die einem Repository erlaubt, den Agent vorzukonfigurieren, fügt der obigen Taxonomie eine Zeile hinzu. Jede Zeile ist ein Kandidat für die nächste CVE in dieser Klasse.

Die Rückseite des Schranks: eine Ladereihenfolgen-Invariante, kein klügerer Dialog

Paul Jobs lehrte Steve, dass die Unterseite eines Schranks dieselbe Sorgfalt verdient wie das sichtbare Finish.¹⁰ Die Schrank-Metapher ist hier nicht dekorativ. Sie ist das Rückgrat der Lösung.

Ein Trust-Dialog ist die Rückseite des Schranks. Benutzer sehen die Ladereihenfolge nicht. Sie sehen einen Dialog, klicken auf „Vertrauen” und gehen davon aus, dass jedes Byte innerhalb des Workspaces inert ist, bis dieser Klick erfolgt. Die Implementierung muss diese Annahme verdienen. Wenn sie es nicht tut, ist die Annahme die Angriffsfläche.

Die Ladereihenfolge ist die Invariante, die entscheidet, ob die Annahme verdient ist. Das minimale Modell, das durch die beiden Advisories und die öffentliche Claude Code-Settings-Dokumentation impliziert wird, ist grob:²¹⁶

1. Benutzereinstellungen aus ~/.claude/settings.json lesen.
2. Benutzereinstellungen aus ~/.claude/settings.local.json lesen.
3. Bewerten, ob dem aktuellen Workspace-Pfad vertraut wird.
4. Falls nicht, den Dialog anzeigen. Klickt der Benutzer auf „Vertrauen”, den Pfad persistieren.
5. Projekt-bezogene .claude/settings.json innerhalb des Repos lesen.
6. Projekt-bezogene .claude/settings.local.json lesen.
7. Hooks, MCP-Server, Skills und Subagents aus den zusammengeführten Einstellungen auflösen.
8. SessionStart-Hooks ausführen.

Die Advisories dokumentieren nicht jeden Schritt exakt, und die Platzierung von Skills, Subagents und MCP relativ zum Settings-Merging ist Implementierungsdetail, das der Benutzer nicht sieht. Was die Advisories sehr wohl festlegen, ist die Grenze bei Schritt 3. Alles, was vor Schritt 3 aufgelöst wird, befindet sich in der Zone vertrauenswürdiger Eingaben. Alles, was bei Schritt 3 oder später aufgelöst wird, darf keine Workspace-Bytes konsultieren. Der März-Bug vertauschte die Schritte 3 und 5: Projekteinstellungen wurden zuerst aufgelöst, und der Berechtigungsmodus, den diese Einstellungen festlegten (bypassPermissions), erfüllte die Trust-Prüfung in Schritt 3 trivial.² Der April-Bug verlagerte den Angriff in Schritt 3 selbst: Die Workspace-Pfad-Auflösung konsultierte eine repository-gesteuerte commondir-Datei, und eine Fälschung sorgte dafür, dass die Trust-Prüfung gegen den vom Angreifer gewählten vertrauenswürdigen Pfad auflöste.¹ So oder so ist der Workspace bis zum Erreichen von Schritt 7 oder 8 bereits als vertrauenswürdig eingestuft, und jede Oberfläche auf Projektebene wird gegen diese Abstimmung geladen.

Die Regel, die die Rückseite des Schranks verlangt, lautet in einem Satz: Interpretieren Sie kein Byte innerhalb des Workspaces, bevor der Benutzer dem Workspace-Pfad explizit vertraut hat. Nicht .claude/settings.json. Nicht commondir. Nicht CLAUDE.md. Nicht eine Dateinamensliste. Nicht eine Hook-Datei. Nicht eine MCP-Server-Konfiguration. Wenn es innerhalb des Workspaces lebt, schaut der Code, der Vertrauen entscheidet, nicht hin.

Visual Studio Code lieferte diese Korrektur im Mai 2021 als Workspace Trust (Release 1.57). Die Kern-Klasse für Ordner-Vertrauen hat seit dem Erscheinen der Funktion keinen veröffentlichten Bypass mehr produziert, auch wenn angrenzende Probleme rund um vertrauenswürdige Domains und Erweiterungsverhalten weiterhin auftauchen.¹¹¹² Version 2.1.53, die vom März-Advisory referenzierte Korrektur, lieferte die Claude Code-Version der Invariante durch das Vertauschen der Schritte 3 und 5.² Version 2.1.84, die vom April-Advisory referenzierte Korrektur, lieferte sie, indem sie sich weigerte, repository-gesteuerten commondir-Dateien während der Trust-Bewertung zu folgen.¹ Beide sind Patches, die die Invariante wiederherstellen, statt eine neue Verteidigung zu erfinden.

The Steve Test zieht den nächsten Faden: Würde Blake seinen Namen darunter setzen?¹³ Die Antwort für Claude Code in diesem Sechs-Wochen-Fenster lautet nein, weil der Hersteller zweimal Bypässe dieser Klasse signiert, ausgeliefert und gepatcht hat. Das ist die Latte, die der Hersteller zu reißen hat. Minimum Worthy Product ist der Standard, auf den sich die Freigabe bezieht.¹⁴ Minimum ist eine Scope-Beschränkung, kein Qualitätsrabatt. Ein „minimum viable” Trust-Dialog ist ein Dialog, der den billigen Fall blockiert. Ein „minimum worthy” Trust-Dialog ist der erste Schritt einer Ladereihenfolge, die sich weigert, irgendein Repository-Byte zu interpretieren, bevor der Benutzer entschieden hat. Das Produkt, das Sie ausliefern, sind die Bytes, die Sie sich weigern zu interpretieren, bis es Ihnen erlaubt wird.

Drei Korrekturen, die die Invariante verlangt

Die Regel ist die Invariante. Drei Muster folgen direkt aus ihr.

Einbahn-Gates. Der Code, der Vertrauen herstellt, liest nur den Pfad, den Klick des Benutzers und den persistierten Trust-Zustand außerhalb des Workspaces in ~/.claude.json.¹⁵ Sonst nichts. Jedes Refactoring, bei dem eine Workspace-Datei zur Trust-Entscheidung beiträgt, ist eine Regression.

Kein transitives Vertrauen durch Pfadauflösung. Die bevorzugte Invariante besagt, dass Worktrees, Submodule, Include-Dateien und Symlink-Ziele jeweils ihre eigene Abfrage erhalten. Visual Studio Codes Workspace Trust hingegen erlaubt, dass das Vertrauen eines übergeordneten Ordners auf Unterordner angewendet wird, und genau diese Wahl ist es, die breite Eltern-Pfad-Vertrauensstellungen wie ~/Projects ausnutzen können, sobald die Pfadauflösung gefälscht wird. Die strengere Regel zahlt mit ein paar zusätzlichen Dialogen und entfernt die gesamte Oberfläche transitiven Vertrauens; die laxere Regel hält die Reibung niedrig und akzeptiert, dass Pfadauflösungs-Bugs zu Trust-Auflösungs-Bugs werden.¹¹

Adversariale Fixtures im Trust-Read-Order-Regressionstest. Ein bewusst präpariertes adversariales Repo, das Canary-Workspace-Dateien committet. Der Test überprüft, dass kein Codepfad diese Canaries liest, bevor der Dialog bestätigt wurde. Liest eine künftige Änderung an der Laufzeit irgendeine Canary-Datei während der Trust-Bewertung, schlägt der Build fehl. CWE-501, Trust Boundary Violation, ist die breitere Familie, die in der Test-Taxonomie neben den spezifischeren CWE-807- und CWE-20/CWE-77-Klassifizierungen, die die veröffentlichten Advisories bereits verwenden, mitverfolgt werden sollte.¹⁶

Keine der drei Maßnahmen ist teuer. Die erste ist die Abwesenheit von Code. Die zweite kostet sichtbare Reibung beim Benutzer. Die dritte ist ein einmaliger Engineering-Durchgang plus Disziplin im Anschluss. Trust-Bootstrap-Kompromittierung ist eine Kategorie, in der die übliche Haltung defense in depth nicht greift, weil jede Schicht stromabwärts des Vertrauens gegen die Trust-Entscheidung läuft, an deren Zustandekommen der Workspace gerade mitgewirkt hat. Verteidigung außerhalb des Vertrauens lässt sich auf der Scaffolding-Schicht nicht aufbauen, weil das Scaffolding genau das ist, was der Workspace lesen darf, sobald das Vertrauen aufgelöst ist.

Der Hersteller muss die Invariante ausliefern. Trust-Dialog-Bypass-CVEs sind das Maß, mit dem Beobachter messen, ob der Hersteller die Latte erreicht. Zwei in sechs Wochen sind kein Rauschen. Sie sind ein Signal, dass die Invariante nicht als Assertion in der Test-Suite kodiert ist, die der Build erzwingt. Bis sie es ist, ist die nächste CVE in dieser Klasse eine Frage des Findens der zehnten Eingabe.

Das Repo sollte nicht über sein eigenes Vertrauen abstimmen dürfen. Vertrauen ist die eine Entscheidung, an deren Zustandekommen das zu bewertende Artefakt nicht mitwirken darf. Jede andere Schicht der Verteidigung des Agents (Hooks, Skills, Validatoren, Detektoren, Guards) lebt stromabwärts dieser einen Abstimmung. Ist die Abstimmung manipuliert, sind die nachgelagerten Arbeiten Möbel. Das Finish des Schranks rettet die Rückseite nicht.

FAQ

Was ist der Claude Code Trust-Dialog-Bypass?

Ein Claude Code Trust-Dialog-Bypass tritt auf, wenn ein nicht vertrauenswürdiger Workspace als vertrauenswürdig behandelt wird, bevor der Benutzer ihn explizit genehmigt hat. Beim CVE vom März 2026 beeinflussten repo-gesteuerte Einstellungen den Berechtigungsmodus, bevor das Vertrauen ausgewertet wurde. Beim CVE vom April 2026 führte ein präpariertes Git-Worktree/Commondir-Layout dazu, dass das Vertrauen über einen bereits vertrauenswürdigen Pfad aufgelöst wurde.

Wie sollte ich vertrauenswürdige Pfade in ~/.claude.json einschränken?

Öffnen Sie ~/.claude.json und prüfen Sie die projects-Map. Suchen Sie nach Einträgen, bei denen hasTrustDialogAccepted auf Verzeichnissen true ist, die keinen aktiven Code mehr enthalten, auf breiten Eltern-Pfaden wie ~/Projects und auf jedem Pfad, der mit worktree-nahen Layouts überlappt. Pro-Repository-Vertrauen fügt zwar Dialoge hinzu, verhindert aber, dass ein einmal akzeptierter Eltern-Pfad stillschweigend jedes Kind abdeckt.

Warum ist Eltern-Pfad-Vertrauen für Claude Code gefährlich?

Eltern-Pfad-Vertrauen ist gefährlich, weil ein einziges akzeptiertes Verzeichnis viele Kind-Workspaces abdecken kann. Wird die Pfadauflösung gefälscht oder zeigt ein bösartiger Worktree zurück in diesen Eltern-Pfad, kann das Kind-Repo Vertrauen erben, das ihm nie gewährt wurde. Pro-Repo-Vertrauen erzeugt Reibung, verhindert jedoch transitives Vertrauen über voneinander unabhängige Repos hinweg.

Welche Invariante verhindert Trust-Dialog-Bypässe?

Die Invariante lautet: Interpretieren Sie kein Byte innerhalb des Workspaces, bevor der Benutzer dem Workspace-Pfad explizit vertraut. Trust-Code darf den Pfad, den Klick des Benutzers und den persistierten Trust-Zustand außerhalb des Repos lesen. Er sollte vor dem Dialog weder .claude/settings.json, CLAUDE.md, .mcp.json, Hooks, Skills, commondir noch irgendeine repo-gesteuerte Datei lesen.

Quellen