GHSA-M6RX-7PVW-2F73

Vulnerability from github – Published: 2026-04-21 15:16 – Updated: 2026-04-21 15:16
VLAI
Summary
OpenClaude: Sandbox Bypass via Early-Exit Logic Flaw Allows Path Traversal
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.

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.

Impact

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

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

Recommended Fix

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.

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 )

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@gitlawb/openclaude"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T15:16:16Z",
    "nvd_published_at": "2026-04-21T00:16:28Z",
    "severity": "HIGH"
  },
  "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 \u2014 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    \u2502\n    \u251c\u2500 [~1445] Sandbox auto-allow block\n    \u2502       \u2514\u2500 No deny rule found \u2192 return ALLOW  \u26a0\ufe0f Early exit\n    \u2502\n    \u2514\u2500 [~1644] checkPathConstraints()             \u274c 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 \u2014 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() \u0026\u0026\n  SandboxManager.isAutoAllowBashIfSandboxedEnabled() \u0026\u0026\n  shouldUseSandbox(input)\n) {\n  const sandboxAutoAllowResult = checkSandboxAutoAllow(\n    input,\n    appState.toolPermissionContext,\n  );\n  if (sandboxAutoAllowResult.behavior !== \u0027allow\u0027) {\n    // Only block or prompt \u2014 never skip path checks on allow\n    return sandboxAutoAllowResult;\n  }\n  // If \u0027allow\u0027, continue to checkPathConstraints below\n}\n```\n\n### Option 2 \u2014 Defense in depth: Run path check before returning\n\nRun `checkPathConstraints` explicitly inside the sandbox block before returning:\n\n```typescript\nif (sandboxAutoAllowResult.behavior !== \u0027passthrough\u0027) {\n  const pathCheck = checkPathConstraints(input, appState.toolPermissionContext);\n  if (pathCheck.behavior !== \u0027allow\u0027) {\n    return pathCheck; // Block traversal attempts even in sandbox\n  }\n  return sandboxAutoAllowResult;\n}\n```\n\n### Option 3 \u2014 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 )",
  "id": "GHSA-m6rx-7pvw-2f73",
  "modified": "2026-04-21T15:16:16Z",
  "published": "2026-04-21T15:16:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Gitlawb/openclaude/security/advisories/GHSA-m6rx-7pvw-2f73"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35570"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Gitlawb/openclaude/commit/7002cb302b78ea2a19da3f26226de24e2903fa1d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Gitlawb/openclaude"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaude: Sandbox Bypass via Early-Exit Logic Flaw Allows Path Traversal "
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…