Loading vulnerability…
Authorization bypass in @ai-sdk/harness-opencode relay
CVE-2026-64651 is an authorization flaw in @ai-sdk/harness-opencode affecting versions through 1.0.27. The package connects HarnessAgent to OpenCode through a sandboxed bridge, but the vulnerable relay accepted requests from any process whose command line contained the path of an approved helper script. In the Linux-specific fallback path, the relay inspected process information via /proc and treated the presence of the helper script path in the command line as sufficient authorization. As a result, untrusted code already executing inside the sandbox could satisfy the check and invoke arbitrary host-exposed tools without a corresponding model-authorized tool-call event. This is an execution-layer authorization bypass that breaks the intended trust boundary between sandboxed code and host tool execution.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows sandboxed untrusted code to bypass the intended model-mediated authorization flow and directly invoke host-exposed tools. Depending on which tools are available in the active harness session, this can enable unauthorized secret retrieval, deployment actions, cloud API operations, and other privileged host-side actions. The issue therefore creates a path from sandboxed code execution to unauthorized access to sensitive capabilities on the host side.
If you can’t patch tonight, do this now.
Until the fixed version is deployed, avoid running the OpenCode harness on untrusted repositories or with untrusted dependencies. Where use with untrusted code cannot be avoided, reduce the exposed host tool set to non-sensitive operations only. Limiting available host-side capabilities reduces the impact of unauthorized relay invocation from sandboxed code.
Patch, then assume compromise.
Upgrade @ai-sdk/harness-opencode to version 1.0.28 or later. The fix removes the process-path authorization fallback entirely and restricts relay acceptance to exact, short-lived, one-time authorization that matches the tool name and input observed from a legitimate bridge-mediated model event.
No validated public exploits yet. Hidden: 1 rejected by Mallory's analysis as not a working exploit.
3 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.