CVE-2026-35570

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.

Affected Component

• File: src/tools/BashTool/bashPermissions.ts
• Function: bashToolHasPermission
• Location: ~line 1445 (sandbox auto-allow block)

Vulnerable Code Flow

bashToolHasPermission()
    │
    ├─ [~1445] Sandbox auto-allow block
    │       └─ No deny rule found → return ALLOW  ⚠️ Early exit
    │
    └─ [~1644] checkPathConstraints()             ❌ Never reached

The 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.

Steps to Reproduce

1. Enable sandbox mode: SandboxManager.isSandboxingEnabled() = true
2. Enable auto-allow: SandboxManager.isAutoAllowBashIfSandboxedEnabled() = true
3. Ensure no explicit deny rules are configured for the session
4. Submit a bash command with a path traversal payload:

   cat ../../../../../etc/passwd
   

5. Observe that the command receives behavior: allow without triggering checkPathConstraints

Option 1, Preferred: Continue pipeline on allow

Only return early for deny or ask behaviors. Let allow fall through to checkPathConstraints:

if (
  SandboxManager.isSandboxingEnabled() &&
  SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
  shouldUseSandbox(input)
) {
  const sandboxAutoAllowResult = checkSandboxAutoAllow(
    input,
    appState.toolPermissionContext,
  );
  if (sandboxAutoAllowResult.behavior !== 'allow') {
    // Only block or prompt, never skip path checks on allow
    return sandboxAutoAllowResult;
  }
  // If 'allow', continue to checkPathConstraints below
}

Option 2, Defense in depth: Run path check before returning

Run checkPathConstraints explicitly inside the sandbox block before returning:

if (sandboxAutoAllowResult.behavior !== 'passthrough') {
  const pathCheck = checkPathConstraints(input, appState.toolPermissionContext);
  if (pathCheck.behavior !== 'allow') {
    return pathCheck; // Block traversal attempts even in sandbox
  }
  return sandboxAutoAllowResult;
}

Option 3, Minimal change: Move sandbox block after path check

Reorder the function so checkPathConstraints always runs first, and the sandbox block only handles the prompt-suppression logic afterward.

Credit: Elvin Latifli (@Rickidevs )

Any process or user operating in a sandboxed session with no explicit deny rules can:

• Read arbitrary files outside the sandbox boundary (e.g., /etc/passwd, /etc/shadow, .env files, SSH private keys)
• Write to arbitrary paths (subject to OS-level permissions)
• Fully defeat the filesystem isolation that the sandbox is intended to enforce

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

CVE-2026-35570 has a CVSS score of 8.4 (High). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.5.1); upgrading removes the vulnerable code path.

Kodem intelligence

The sandbox auto-allow block should never short-circuit the full permission pipeline. It may suppress interactive prompts, but path constraint validation must always execute.

1. What is CVE-2026-35570? CVE-2026-35570 is a high-severity path traversal vulnerability in @gitlawb/openclaude (npm), affecting versions < 0.5.1. It is fixed in 0.5.1. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
2. How severe is CVE-2026-35570? CVE-2026-35570 has a CVSS score of 8.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @gitlawb/openclaude are affected by CVE-2026-35570? @gitlawb/openclaude (npm) versions < 0.5.1 is affected.
4. Is there a fix for CVE-2026-35570? Yes. CVE-2026-35570 is fixed in 0.5.1. Upgrade to this version or later.
5. Is CVE-2026-35570 exploitable, and should I be worried? Whether CVE-2026-35570 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-35570 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-35570? Upgrade @gitlawb/openclaude to 0.5.1 or later.