CVE-2026-64650 in harness-codex
Summary
by MITRE • 07/21/2026
The `@ai-sdk/harness-opencode` tool is an HarnessV1 adapter backed by @openai/codex-sdk, which drives the codex command line interface. Prior to version 1.0.29, the tool relay authorizes requests from any process whose command line contains an allowed helper script path (the Codex CLI shim). 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.29 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 Codex harness on untrusted repositories or with untrusted dependencies, and/or limit host-exposed tools to non-sensitive operations when working with untrusted code.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in ai-sdk/harness-opencode stems from a flawed authorization mechanism that operates on an overly permissive trust model for command line processes. This security flaw exists within the HarnessV1 adapter that interfaces with the openai/codex-sdk, creating a dangerous pathway where any process containing an allowed helper script path can relay requests to host-exposed tools. The vulnerability represents a classic case of insufficient authorization controls, where the system assumes legitimate access based solely on process path matching rather than verifying the actual tool invocation context and intent.
The technical implementation of this flaw manifests through the use of process.platform === 'linux' checks that trigger fallback authorization mechanisms reading from /proc filesystem entries. This approach creates a path traversal vulnerability that allows untrusted code within sandboxed environments to bypass normal security boundaries. The system's reliance on command line string matching rather than cryptographic verification or time-bound authorization tokens creates an attack surface where malicious code can exploit the trust relationship between legitimate helper scripts and host operations.
The operational impact of this vulnerability extends far beyond simple privilege escalation, as it enables arbitrary execution of sensitive host operations including secret lookups, deployment workflows, and cloud API interactions. This represents a critical breach in the security model where sandboxed environments lose their protective value, allowing attackers to perform operations that should be strictly controlled through model-authorized tool calls. The vulnerability affects any environment with active harness sessions containing host-provided tools, making it particularly dangerous in continuous integration/continuous deployment pipelines.
The exploit requires specific environmental conditions including Linux platforms, active harness sessions with exposed tools, and execution of untrusted code within sandboxed contexts such as malicious dependencies or build scripts. This combination of requirements makes the vulnerability more targeted but also more severe when present, as it can be leveraged in legitimate development workflows where trust boundaries are already established.
The remediation implemented in version 1.0.29 addresses this issue by eliminating the process-path authorization fallback entirely and implementing a strict one-time authorization model. This new approach requires exact matching of tool names and inputs against bridge-observed model events, creating a much tighter security boundary that aligns with principle of least privilege principles. The fix effectively removes the dangerous fallback mechanism that allowed path-based trust relationships while introducing time-bound, context-aware authorization that better aligns with modern security practices.
This vulnerability demonstrates characteristics consistent with CWE-285 (Improper Authorization) and CWE-749 (Exposed Dangerous Method or Function) while potentially mapping to ATT&CK techniques such as T1059 (Command and Scripting Interpreter) and T1566 (Phishing) when combined with supply chain compromises. Organizations should implement the suggested workarounds including avoiding execution on untrusted repositories, limiting host-exposed tools to non-sensitive operations, and maintaining strict dependency vetting processes to prevent exploitation of similar authorization flaws in other development toolchains.
The broader implications highlight the importance of zero-trust architectures in development environments where code execution boundaries are increasingly blurred by modern CI/CD practices and cloud integration patterns. This vulnerability serves as a reminder that even seemingly benign development tools can become attack vectors when authorization controls are improperly implemented, particularly in systems designed to bridge trust boundaries between different security domains.