CVE-2026-22682: OpenHarness file tool permission

CISO Take

OpenHarness, an AI coding agent framework, ships built-in file tools (read_file, write_file, edit_file, notebook_edit) that fail to pass the path parameter to the PermissionChecker, letting anyone who can influence the agent's tool calls bypass configured deny rules and read files outside the intended repository — including SSH keys, cloud credentials, and configuration secrets — or, in full_auto mode, create and overwrite files in restricted host paths. There is no CISA KEV listing and no public exploit or Nuclei template yet, and the EPSS score is low in absolute terms (0.13%) even though it ranks in the 97th percentile relative to other CVEs, so treat this as a real but not yet weaponized risk. The bigger concern for CISOs running agentic coding tools is blast radius: any workflow where an LLM's tool calls can be steered by untrusted input — a malicious repo, a poisoned prompt, a compromised MCP integration — turns this permission gap into credential theft or host file tampering. Patch to commit 166fcfe or later on any host running OpenHarness, especially with full_auto or elevated tool permissions, and until patched, sandbox agent execution with restricted filesystem mounts rather than relying on the built-in deny-list. Monitor for file tool invocations targeting paths outside the working repository as a detection signal.

Sources: NVD GitHub Advisory EPSS ATLAS vulncheck.com

What is the risk?

Exploitability is high once an attacker can influence agent tool execution: the attack vector is local, attack complexity is low, only low privileges are required, and no user interaction is needed (AV:L/AC:L/PR:L/UI:N). Impact is significant on confidentiality and integrity (C:H/I:H) with no availability impact — the flaw allows arbitrary local file read and, in full_auto mode, arbitrary file creation/overwrite in restricted host paths, but does not directly crash or degrade the service. No active exploitation (not in CISA KEV), no public PoC, and no Nuclei template exist, and EPSS is low in absolute terms, so this is a high-severity but currently latent risk rather than an urgent, actively-exploited one. Exposure is concentrated in any environment where OpenHarness runs with broad filesystem access — developer machines, CI/CD runners, or cloud dev environments — since those hosts commonly hold SSH keys, cloud credentials, and other high-value secrets that the flawed PermissionChecker was supposed to protect.

How does the attack unfold?

Positioning

Attacker gains the ability to influence the agent's tool execution — via a poisoned prompt, malicious repository content, or a compromised upstream tool integration.

AML.T0053

Exploitation

Attacker crafts a path parameter for read_file/write_file/edit_file/notebook_edit that is never forwarded to the PermissionChecker, bypassing configured deny rules.

AML.T0037

Data exposure

Attacker reads sensitive files outside the repository scope, such as SSH keys, cloud credentials, and configuration secrets.

AML.T0055

Integrity impact

In full_auto mode, the attacker creates or overwrites files in restricted host paths, enabling persistence or further compromise.

AML.T0101

Positioning

Attacker gains the ability to influence the agent's tool execution — via a poisoned prompt, malicious repository content, or a compromised upstream tool integration.

AML.T0053

Exploitation

Attacker crafts a path parameter for read_file/write_file/edit_file/notebook_edit that is never forwarded to the PermissionChecker, bypassing configured deny rules.

AML.T0037

Data exposure

Attacker reads sensitive files outside the repository scope, such as SSH keys, cloud credentials, and configuration secrets.

AML.T0055

Integrity impact

In full_auto mode, the attacker creates or overwrites files in restricted host paths, enabling persistence or further compromise.

AML.T0101

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenHarness	—	—	No patch

Do you use OpenHarness? You're affected.

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 3% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I High

A None

What should I do?

1 step

1) Upgrade OpenHarness to commit 166fcfe or later immediately, prioritizing any hosts running full_auto mode or with agent access to credential-bearing paths. 2) Until patched, run OpenHarness in a sandboxed/containerized environment with least-privilege, read-only-where-possible filesystem mounts, and no access to SSH keys or cloud credential files. 3) Disable full_auto mode (or any auto-write capability) for untrusted inputs/repos until the patch is applied. 4) Do not treat the PermissionChecker deny-list as the sole control — enforce OS-level file permissions and mount restrictions independently. 5) Rotate SSH keys, API tokens, and other credentials that were reachable from hosts running a vulnerable version, since past exploitation cannot be ruled out retroactively. 6) Detection: log and alert on read_file/write_file/edit_file/notebook_edit invocations whose resolved path resolves outside the intended repository root, and review agent tool-call logs/transcripts for path traversal patterns (e.g., ../, absolute paths to /etc, ~/.ssh).

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

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

How is it classified?

Auth Bypass Data Leakage Agent Plugin AML.T0037 - Data from Local System AML.T0053 - AI Agent Tool Invocation AML.T0055 - Unsecured Credentials AML.T0101 - Data Destruction via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system operation and monitoring

NIST AI RMF

MEASURE 2.7 - AI system security and resilience is evaluated and documented

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-22682?

OpenHarness, an AI coding agent framework, ships built-in file tools (read_file, write_file, edit_file, notebook_edit) that fail to pass the path parameter to the PermissionChecker, letting anyone who can influence the agent's tool calls bypass configured deny rules and read files outside the intended repository — including SSH keys, cloud credentials, and configuration secrets — or, in full_auto mode, create and overwrite files in restricted host paths. There is no CISA KEV listing and no public exploit or Nuclei template yet, and the EPSS score is low in absolute terms (0.13%) even though it ranks in the 97th percentile relative to other CVEs, so treat this as a real but not yet weaponized risk. The bigger concern for CISOs running agentic coding tools is blast radius: any workflow where an LLM's tool calls can be steered by untrusted input — a malicious repo, a poisoned prompt, a compromised MCP integration — turns this permission gap into credential theft or host file tampering. Patch to commit 166fcfe or later on any host running OpenHarness, especially with full_auto or elevated tool permissions, and until patched, sandbox agent execution with restricted filesystem mounts rather than relying on the built-in deny-list. Monitor for file tool invocations targeting paths outside the working repository as a detection signal.

Is CVE-2026-22682 actively exploited?

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

How to fix CVE-2026-22682?

1) Upgrade OpenHarness to commit 166fcfe or later immediately, prioritizing any hosts running full_auto mode or with agent access to credential-bearing paths. 2) Until patched, run OpenHarness in a sandboxed/containerized environment with least-privilege, read-only-where-possible filesystem mounts, and no access to SSH keys or cloud credential files. 3) Disable full_auto mode (or any auto-write capability) for untrusted inputs/repos until the patch is applied. 4) Do not treat the PermissionChecker deny-list as the sole control — enforce OS-level file permissions and mount restrictions independently. 5) Rotate SSH keys, API tokens, and other credentials that were reachable from hosts running a vulnerable version, since past exploitation cannot be ruled out retroactively. 6) Detection: log and alert on read_file/write_file/edit_file/notebook_edit invocations whose resolved path resolves outside the intended repository root, and review agent tool-call logs/transcripts for path traversal patterns (e.g., `../`, absolute paths to `/etc`, `~/.ssh`).

What systems are affected by CVE-2026-22682?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, coding/dev agent harnesses, CI/CD AI automation pipelines.

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

CVE-2026-22682 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.13%.

What is the AI security impact?

Affected AI Architectures

agent frameworkscoding/dev agent harnessesCI/CD AI automation pipelines

MITRE ATLAS Techniques

AML.T0037 Data from Local System

AML.T0053 AI Agent Tool Invocation

AML.T0055 Unsecured Credentials

AML.T0101 Data Destruction via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

OpenHarness prior to commit 166fcfe contains an improper access control vulnerability in built-in file tools due to inconsistent parameter handling in permission enforcement, allowing attackers who can influence agent tool execution to read arbitrary local files outside the intended repository scope. Attackers can exploit the path parameter not being passed to the PermissionChecker in read_file, write_file, edit_file, and notebook_edit tools to bypass deny rules and access sensitive files such as configuration files, credentials, and SSH material, or create and overwrite files in restricted host paths in full_auto mode.

Exploitation Scenario

An attacker who can influence what the coding agent does — via a poisoned prompt, a malicious file or README in a repository the agent is asked to work on, or a compromised upstream MCP/tool integration — instructs the agent to call read_file with a path such as `../../.ssh/id_rsa` or an absolute path to a credentials file outside the repo. Because that path is never forwarded to the PermissionChecker, the configured deny-list never evaluates the real target and the read succeeds, exposing the file's contents in the tool's output where the attacker can harvest it from agent logs or chat transcripts. In full_auto mode, the same flaw lets the attacker use write_file or edit_file to drop or overwrite a file in a restricted host location — for example planting a malicious script in a shared CI runner path or a startup directory — establishing persistence or enabling further lateral movement.

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.