<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T21:30:13.679021+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-324074</id>
    <title>EUVD-2026-324074</title>
    <updated>2026-10-07T21:30:13.734013+00:00</updated>
    <content>EUVD-2026-324074</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-324074"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-42074</id>
    <title>fkie_cve-2026-42074</title>
    <updated>2026-10-07T21:30:13.734058+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>OpenClaude is an open-source coding-agent command line interface for cloud and local model providers. Prior to version 0.5.1, the dangerouslyDisableSandbox parameter is exposed as part of the BashTool input schema, meaning the LLM (an untrusted principal per the project's own threat model) can set it to true in any tool_use response. Combined with the default allowUnsandboxedCommands: true setting, a prompt-injected model can escape the sandbox for any arbitrary command, achieving full host-level code execution. This issue has been patched in version 0.5.1.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-42074"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-m77w-p5jj-xmhg</id>
    <title>GHSA-m77w-p5jj-xmhg — OpenClaude Sandbox Bypass via Model-Controlled `dangerouslyDisableSandbox` Input</title>
    <updated>2026-10-07T21:30:13.734111+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: openclaude</p>
<p>### Summary
The `dangerouslyDisableSandbox` parameter is exposed as part of the BashTool input schema, meaning the LLM (an untrusted principal per the project's own threat model) can set it to `true` in any `tool_use` response. Combined with the default `allowUnsandboxedCommands: true` setting, a prompt-injected model can escape the sandbox for any arbitrary command, achieving full host-level code execution.</p>
<p>### Details
The vulnerability exists in the `shouldUseSandbox()` function in `src/tools/BashTool/shouldUseSandbox.ts` (lines 130–153):</p>
<p>```typescript
export function shouldUseSandbox(input: Partial&lt;SandboxInput&gt;): boolean {
  if (!SandboxManager.isSandboxingEnabled()) {
    return false
  }
  // THE VULNERABILITY: model-controlled flag bypasses sandbox
  if (
    input.dangerouslyDisableSandbox &amp;&amp;
    SandboxManager.areUnsandboxedCommandsAllowed()
  ) {
    return false
  }
  // ...
  return true
}
```</p>
<p>The second guard, `areUnsandboxedCommandsAllowed()`, is defined in `src/utils/sandbox/sandbox-adapter.ts` (lines 474–477) and **defaults to `true`**:</p>
<p>```typescript
function areUnsandboxedCommandsAllowed(): boolean {
  const settings = getSettings_DEPRECATED()
  return settings?.sandbox?.allowUnsandboxedCommands ?? true
}
```</p>
<p>This means that out of the box, with default configuration, the LLM can bypass the sandbox for any command simply by including `"dangerouslyDisableSandbox": true` in its tool call input. The project's own trust model states: "The model/agent is **n…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-m77w-p5jj-xmhg"/>
  </entry>
</feed>
