Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 0.17% for the current model date.
BlackTreeCVE Intelligencevercel · @ai-sdk/harness-opencode
Official source article: GitHub GHSA-G48P-5RR5-8RGQ ↗. Check the applicable product and release in the original source.
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Fix not verifiedThe `@ai-sdk/harness-opencode` tool connects HarnessAgent to OpenCode through a sandboxed bridge. Prior to version 1.0.28, the tool relay authorizes requests from any process whose command line contains an allowed helper script path (`host-tool-mcp.mjs`). This allows untrusted code executing in the sandbox to invoke arbitrary host-exposed tools including secret lookups, deployment operations, and cloud API calls without a corresponding model-authorized tool-call event. Exploitation requires a Linux environment (the vulnerable fallback checks `process.platform === 'linux'` and reads `/proc`); an active harness session with one or more host-provided tools; and untrusted code executing in the sandbox (e.g. a malicious dependency, build script, or lifecycle hook) The fix in version 1.0.28 removes the process-path authorization fallback entirely. Relay requests are now only accepted after exact, short-lived, one-time authorization matching the tool name and input from a bridge-observed model event. Some workarounds are available. Do not run the OpenCode harness on untrusted repositories or with untrusted dependencies, and/or limit host-exposed tools to non-sensitive operations when working with untrusted code.
The `@ai-sdk/harness-opencode` tool connects HarnessAgent to OpenCode through a sandboxed bridge. Prior to version 1.0.28, the tool relay authorizes requests from any process whose command line contains an allowed helper script path (`host-tool-mcp.mjs`). This allows untrusted code executing in the sandbox to invoke arbitrary host-exposed tools including secret lookups, deployment operations, and cloud API calls without a corresponding model-authorized tool-call event. Exploitation requires a Linux environment (the vulnerable fallback checks `process.platform === 'linux'` and reads `/proc`); an active harness session with one or more host-provided tools; and untrusted code executing in the sandbox (e.g. a malicious dependency, build script, or lifecycle hook) The fix in version 1.0.28 removes the process-path authorization fallback entirely. Relay requests are now only accepted after exact, short-lived, one-time authorization matching the tool name and input from a bridge-observed model event. Some workarounds are available. Do not run the OpenCode harness on untrusted repositories or with untrusted dependencies, and/or limit host-exposed tools to non-sensitive operations when working with untrusted code.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through local access may attempt exploitation without authentication or user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
The `@ai-sdk/harness-opencode` tool connects HarnessAgent to OpenCode through a sandboxed bridge. Prior to version 1.0.28, the tool relay authorizes requests from any process whose command line contains an allowed helper script path (`host-tool-mcp.mjs`). This allows untrusted code executing in the sandbox to invoke arbitrary host-exposed tools including secret lookups, deployment operations, and cloud API calls without a corresponding model-authorized tool-call event. Exploitation requires a Linux environment (the vulnerable fallback checks `process.platform === 'linux'` and reads `/proc`); an active harness session with one or more host-provided tools; and untrusted code executing in the sandbox (e.g. a malicious dependency, build script, or lifecycle hook) The fix in version 1.0.28 removes the process-path authorization fallback entirely. Relay requests are now only accepted after exact, short-lived, one-time authorization matching the tool name and input from a bridge-observed model event. Some workarounds are available. Do not run the OpenCode harness on untrusted repositories or with untrusted dependencies, and/or limit host-exposed tools to non-sensitive operations when working with untrusted code.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through local access may attempt exploitation without authentication or user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-863: Incorrect Authorization. The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:NCommon Vulnerability Scoring System 4.0: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 20 Jul 2026 · Last source change 21 Jul 2026, 12:49 UTC · CWE-863 · Incorrect Authorization
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.