CVE-2026-22682
Received Received - Intake
Improper Access Control in OpenHarness File Tools Enables Arbitrary File Access

Publication date: 2026-04-07

Last updated on: 2026-04-07

Assigner: VulnCheck

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-07
Last Modified
2026-04-07
Generated
2026-05-07
AI Q&A
2026-04-07
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
hkuds openharness to commit_166fcfe (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-863 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.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-22682 is an improper access control vulnerability in OpenHarness prior to commit 166fcfe. It arises because the built-in file tools (read_file, write_file, edit_file, and notebook_edit) do not consistently handle the path parameter when enforcing permissions. Specifically, the path parameter is not passed correctly to the PermissionChecker, allowing attackers who can influence agent tool execution to bypass deny rules.

This flaw allows unauthorized reading of arbitrary local files outside the intended repository scope, including sensitive files such as configuration files, credentials, and SSH materials. In full_auto mode, attackers can also create or overwrite files in restricted host paths.

The root cause was a mismatch in argument names: the permission checking layer only received the 'file_path' parameter, while some tools used 'path', causing permission rules based on path to be bypassed. The fix involved normalizing and resolving file paths before permission evaluation to ensure consistent enforcement.


How can this vulnerability impact me? :

This vulnerability can have significant security impacts including unauthorized access and modification of local files.

  • Confidentiality impact: Attackers can read arbitrary local files outside the intended repository scope, including sensitive configuration files, credentials, SSH keys, and other secret materials.
  • Integrity impact: In full_auto mode, attackers can create or overwrite files in restricted host paths, potentially tampering with local project state or other important files.
  • Availability impact: Although not the primary concern, unauthorized file overwrites could disrupt availability by corrupting or deleting important files.

How can this vulnerability be detected on my network or system? Can you suggest some commands?

Detection of this vulnerability involves verifying whether unauthorized file access or modification attempts are possible through the built-in file tools (read_file, write_file, edit_file, notebook_edit) in OpenHarness prior to commit 166fcfe.

Specifically, you can test if the permission enforcement properly blocks access to sensitive files or restricted paths by attempting to read or write files outside the intended repository scope.

Suggested commands to detect exploitation attempts include invoking the vulnerable tools with file paths that should be denied by permission rules, for example:

  • Attempt to read a sensitive file (e.g., /etc/passwd) using the read_file tool.
  • Attempt to write or overwrite a file in a restricted directory (e.g., /tmp/blocked_file) using the write_file tool in full_auto mode.

Monitoring error messages or outputs indicating permission deny rule matches can help confirm if the vulnerability is present or has been mitigated.


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation step is to update OpenHarness to include the fix introduced in commit 166fcfe, which properly normalizes and enforces path-based permission checks.

This fix ensures that the path parameter is correctly passed to the PermissionChecker, preventing unauthorized file reads and writes.

Until the update can be applied, restrict or monitor usage of the affected built-in file tools (read_file, write_file, edit_file, notebook_edit) to prevent attackers from influencing agent tool execution.

Additionally, review and tighten permission rules to explicitly deny access to sensitive directories and files, and consider running OpenHarness with the least privileges necessary.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability allows unauthorized reading of arbitrary local files outside the intended repository scope, including sensitive configuration files, credentials, and SSH materials. This unauthorized access to sensitive data can lead to violations of data protection regulations such as GDPR and HIPAA, which require strict controls on access to personal and sensitive information.

Additionally, in full_auto mode, attackers can create or overwrite files in restricted host paths, potentially compromising data integrity and security controls mandated by these standards.

Therefore, the improper access control flaw in OpenHarness prior to the fix could result in non-compliance with common standards and regulations that mandate proper authorization and protection of sensitive data.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart