CVE-2026-64650: @ai-sdk/harness-codex tool relay

CISO Take

The Codex CLI adapter used by the @ai-sdk agent harness authorized privileged tool calls (secret lookups, deployments, cloud API calls) by matching a process's command-line string instead of verifying a genuine model-issued tool-call event, so any code running in the sandbox could forge that match and invoke host-exposed tools directly. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template for this CVE, and exploitation is gated behind specific preconditions — a Linux host, an active harness session with host-provided tools, and untrusted code already running inside the sandbox (e.g., via a malicious dependency or build/lifecycle script) — so this is not remotely or trivially exploitable. The real risk is supply-chain: teams running AI coding agents against third-party repos or unvetted npm dependencies are one poisoned lifecycle hook away from silent credential and cloud-access theft, with no model-side audit trail showing the tool call was ever requested. Upgrade to @ai-sdk/harness-opencode 1.0.29+, which removes the process-path fallback in favor of short-lived, exact one-time authorization tied to a bridge-observed model event; until patched, do not run the Codex harness on untrusted repositories or dependencies, and restrict host-exposed tools to non-sensitive operations.

Sources: NVD GitHub Advisory CISA KEV ATLAS

What is the risk?

Rated medium severity with no assigned CVSS vector, reflecting that the flaw requires local, chained preconditions rather than being remotely triggerable: a Linux host, an active harness session exposing host tools, and pre-existing code execution inside the sandbox. There is no evidence of active exploitation (not in CISA KEV, no EPSS data, no public PoC or scanner template), which lowers near-term urgency. However, the impact ceiling is high — successful exploitation grants access to secret lookups, deployment operations, and cloud API calls that were meant to require model authorization — and the vulnerable component sits in an emerging, fast-adopting category (agentic AI coding tools wired directly into developer credentials and CI/CD). Organizations piloting Codex-based agent harnesses against external or lightly-vetted codebases should treat this as a supply-chain-adjacent risk worth prioritizing over its numeric severity.

How does the attack unfold?

Initial Access

Untrusted code (a malicious npm dependency, build script, or lifecycle hook) executes inside the harness sandbox alongside a legitimate agent session.

AML.T0011.001

Authorization Bypass

The malicious process's command line is crafted to match the allowed Codex CLI shim path, satisfying the vulnerable process-path fallback check on Linux.

AML.T0053

Unauthorized Tool Invocation

The tool relay grants access to host-exposed tools without any corresponding model-authorized tool-call event, bypassing the intended human/model-in-the-loop control.

AML.T0098

Impact

The attacker abuses granted tool access to exfiltrate secrets, trigger unauthorized deployments, or call cloud APIs, with no legitimate audit trail of the action having been model-requested.

AML.T0086

Initial Access

Untrusted code (a malicious npm dependency, build script, or lifecycle hook) executes inside the harness sandbox alongside a legitimate agent session.

AML.T0011.001

Authorization Bypass

The malicious process's command line is crafted to match the allowed Codex CLI shim path, satisfying the vulnerable process-path fallback check on Linux.

AML.T0053

Unauthorized Tool Invocation

The tool relay grants access to host-exposed tools without any corresponding model-authorized tool-call event, bypassing the intended human/model-in-the-loop control.

AML.T0098

Impact

The attacker abuses granted tool access to exfiltrate secrets, trigger unauthorized deployments, or call cloud APIs, with no legitimate audit trail of the action having been model-requested.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
@ai-sdk/harness-codex	—	—	No patch

Do you use @ai-sdk/harness-codex? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.2%

chance of exploitation in 30 days

Higher than 6% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade @ai-sdk/harness-opencode to version 1.0.29 or later, which removes the process-path authorization fallback and requires exact, short-lived, one-time authorization matching tool name and input from a bridge-observed model event. Until patched: do not run the Codex harness against untrusted repositories, dependencies, or build/lifecycle scripts; limit host-exposed tools available to the harness to non-sensitive operations only (avoid wiring in secret stores, deployment, or cloud-admin APIs where possible); and add detection/monitoring for tool-relay invocations that lack a corresponding model tool-call event in session logs, as well as anomalous processes reading /proc or spoofing the Codex CLI shim's command-line signature.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Code Execution Supply Chain Agent Plugin AML.T0011.001 - Malicious Package AML.T0053 - AI Agent Tool Invocation AML.T0098 - AI Agent Tool Credential Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

GOVERN 6.1 - Third-party risks and supply chain

OWASP LLM Top 10

LLM03:2025 - Supply Chain LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-64650?

The Codex CLI adapter used by the @ai-sdk agent harness authorized privileged tool calls (secret lookups, deployments, cloud API calls) by matching a process's command-line string instead of verifying a genuine model-issued tool-call event, so any code running in the sandbox could forge that match and invoke host-exposed tools directly. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template for this CVE, and exploitation is gated behind specific preconditions — a Linux host, an active harness session with host-provided tools, and untrusted code already running inside the sandbox (e.g., via a malicious dependency or build/lifecycle script) — so this is not remotely or trivially exploitable. The real risk is supply-chain: teams running AI coding agents against third-party repos or unvetted npm dependencies are one poisoned lifecycle hook away from silent credential and cloud-access theft, with no model-side audit trail showing the tool call was ever requested. Upgrade to @ai-sdk/harness-opencode 1.0.29+, which removes the process-path fallback in favor of short-lived, exact one-time authorization tied to a bridge-observed model event; until patched, do not run the Codex harness on untrusted repositories or dependencies, and restrict host-exposed tools to non-sensitive operations.

Is CVE-2026-64650 actively exploited?

No confirmed active exploitation of CVE-2026-64650 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-64650?

Upgrade @ai-sdk/harness-opencode to version 1.0.29 or later, which removes the process-path authorization fallback and requires exact, short-lived, one-time authorization matching tool name and input from a bridge-observed model event. Until patched: do not run the Codex harness against untrusted repositories, dependencies, or build/lifecycle scripts; limit host-exposed tools available to the harness to non-sensitive operations only (avoid wiring in secret stores, deployment, or cloud-admin APIs where possible); and add detection/monitoring for tool-relay invocations that lack a corresponding model tool-call event in session logs, as well as anomalous processes reading `/proc` or spoofing the Codex CLI shim's command-line signature.

What systems are affected by CVE-2026-64650?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI coding assistants, CI/CD-integrated agents, tool-calling / plugin systems.

What is the CVSS score for CVE-2026-64650?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI coding assistantsCI/CD-integrated agentstool-calling / plugin systems

MITRE ATLAS Techniques

AML.T0011.001 Malicious Package

AML.T0053 AI Agent Tool Invocation

AML.T0098 AI Agent Tool Credential Harvesting

Compliance Controls Affected

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM03:2025, LLM06:2025

What are the technical details?

Original Advisory

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.

Exploitation Scenario

A developer points an AI coding agent (using the vulnerable harness) at a third-party repository, or the agent pulls in a malicious npm dependency during a normal build. That dependency's postinstall or lifecycle script executes inside the sandbox and spawns a process whose command line is crafted to match the allowed Codex CLI shim path pattern. The vulnerable relay's fallback authorization check sees the matching command-line string on Linux and grants the process access to host-exposed tools — the malicious script then calls a secret-lookup tool to exfiltrate API keys or invokes a deployment tool to push unauthorized changes, all without any model-authorized tool-call event ever being generated, leaving no legitimate audit trail of the model requesting that action.

Weaknesses (CWE)

CWE-863 Incorrect Authorization

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.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.