+ "details": "A logic flaw exists in `bashToolHasPermission()` inside `src/tools/BashTool/bashPermissions.ts`. When the sandbox auto-allow feature is active and no explicit deny rule is configured, the function returns an `allow` result immediately — before the path constraint filter (`checkPathConstraints`) is ever evaluated. This allows commands containing path traversal sequences (e.g., `../../../../../etc/passwd`) to bypass directory restrictions entirely.\n\n## Affected Component\n\n- **File:** `src/tools/BashTool/bashPermissions.ts`\n- **Function:** `bashToolHasPermission`\n- **Location:** ~line 1445 (sandbox auto-allow block)\n\n## Vulnerable Code Flow\n\n```\nbashToolHasPermission()\n │\n ├─ [~1445] Sandbox auto-allow block\n │ └─ No deny rule found → return ALLOW ⚠️ Early exit\n │\n └─ [~1644] checkPathConstraints() ❌ Never reached\n```\n\nThe sandbox block was designed to skip interactive permission prompts in sandboxed environments. However, it unintentionally also skips the path traversal filter, which is a separate and critical security control.\n\n## Impact\n\nAny process or user operating in a sandboxed session with no explicit deny rules can:\n\n- Read arbitrary files outside the sandbox boundary (e.g., `/etc/passwd`, `/etc/shadow`, `.env` files, SSH private keys)\n- Write to arbitrary paths (subject to OS-level permissions)\n- Fully defeat the filesystem isolation that the sandbox is intended to enforce\n\n## Steps to Reproduce\n\n1. Enable sandbox mode: `SandboxManager.isSandboxingEnabled() = true`\n2. Enable auto-allow: `SandboxManager.isAutoAllowBashIfSandboxedEnabled() = true`\n3. Ensure no explicit deny rules are configured for the session\n4. Submit a bash command with a path traversal payload:\n ```\n cat ../../../../../etc/passwd\n ```\n5. Observe that the command receives `behavior: allow` without triggering `checkPathConstraints`\n\n## Recommended Fix\n\nThe sandbox auto-allow block should **never short-circuit the full permission pipeline**. It may suppress interactive prompts, but path constraint validation must always execute.\n\n### Option 1 — Preferred: Continue pipeline on `allow`\n\nOnly return early for `deny` or `ask` behaviors. Let `allow` fall through to `checkPathConstraints`:\n\n```typescript\nif (\n SandboxManager.isSandboxingEnabled() &&\n SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&\n shouldUseSandbox(input)\n) {\n const sandboxAutoAllowResult = checkSandboxAutoAllow(\n input,\n appState.toolPermissionContext,\n );\n if (sandboxAutoAllowResult.behavior !== 'allow') {\n // Only block or prompt — never skip path checks on allow\n return sandboxAutoAllowResult;\n }\n // If 'allow', continue to checkPathConstraints below\n}\n```\n\n### Option 2 — Defense in depth: Run path check before returning\n\nRun `checkPathConstraints` explicitly inside the sandbox block before returning:\n\n```typescript\nif (sandboxAutoAllowResult.behavior !== 'passthrough') {\n const pathCheck = checkPathConstraints(input, appState.toolPermissionContext);\n if (pathCheck.behavior !== 'allow') {\n return pathCheck; // Block traversal attempts even in sandbox\n }\n return sandboxAutoAllowResult;\n}\n```\n\n### Option 3 — Minimal change: Move sandbox block after path check\n\nReorder the function so `checkPathConstraints` always runs first, and the sandbox block only handles the prompt-suppression logic afterward.\n\n---\n\nCredit: Elvin Latifli (@Rickidevs )",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments