CVE-2026-22682: OpenHarness Auth Bypass Vulnerability

CVE-2026-22682 Overview

OpenHarness prior to commit 166fcfe contains an improper access control vulnerability in built-in file tools due to inconsistent parameter handling in permission enforcement. This vulnerability allows attackers who can influence agent tool execution to read arbitrary local files outside the intended repository scope.

The vulnerability stems from the path parameter not being passed to the PermissionChecker in read_file, write_file, edit_file, and notebook_edit tools. This enables attackers to bypass deny rules and access sensitive files such as configuration files, credentials, and SSH material. In full_auto mode, attackers can also create and overwrite files in restricted host paths.

Critical Impact

Attackers can bypass permission enforcement to access sensitive configuration files, credentials, SSH keys, and potentially create or overwrite files in restricted host paths when full_auto mode is enabled.

Affected Products

• OpenHarness versions prior to commit 166fcfefb7614dbac51bd061f56542725b0298e9
• Systems using OpenHarness built-in file tools (read_file, write_file, edit_file, notebook_edit)
• OpenHarness deployments operating in full_auto mode

Discovery Timeline

• 2026-04-07 - CVE-2026-22682 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-22682

Vulnerability Analysis

This improper access control vulnerability (CWE-863) exists due to inconsistent parameter handling within the permission enforcement mechanism of OpenHarness's built-in file tools. The core issue lies in how the PermissionChecker.evaluate() function receives tool input parameters when determining whether a file operation should be allowed or denied.

When file tools such as read_file, write_file, edit_file, and notebook_edit are invoked, the permission checking logic extracts the file path using a specific parameter name (file_path). However, certain tools pass the path using a different parameter name (path), which is not recognized by the extraction logic. This discrepancy results in a None value being passed to the permission checker, effectively bypassing any path-based deny rules configured by administrators.

The vulnerability is particularly dangerous in environments where OpenHarness operates in full_auto mode, as it enables not only unauthorized file reads but also file creation and modification in restricted paths. This could allow attackers to exfiltrate sensitive data including credentials, SSH keys, and configuration files, or to establish persistence by writing malicious files to the host system.

Root Cause

The root cause is inconsistent parameter name handling in the permission enforcement logic within src/openharness/engine/query.py. The original code extracted file paths using only the file_path parameter key, while some built-in tools pass paths using the path parameter. This parameter name mismatch causes the permission checker to receive a null file path value, bypassing all path-based access control rules.

Attack Vector

Attackers with the ability to influence agent tool execution can exploit this vulnerability by invoking file tools with paths targeting sensitive files outside the intended repository scope. The attack requires local access and low privileges, but requires no user interaction. By targeting files like /etc/passwd, .ssh/id_rsa, or application configuration files containing secrets, attackers can extract sensitive information or, in write scenarios, modify critical system files.

             is_error=True,
         )
 
-    # Extract file_path and command for path-level permission checks
-    _file_path = str(tool_input.get("file_path", "")) or None
-    _command = str(tool_input.get("command", "")) or None
+    # Normalize common tool inputs before permission checks so path rules apply
+    # consistently across built-in tools that use either `file_path` or `path`.
+    _file_path = _resolve_permission_file_path(context.cwd, tool_input, parsed_input)
+    _command = _extract_permission_command(tool_input, parsed_input)
     decision = context.permission_checker.evaluate(
         tool_name,
         is_read_only=tool.is_read_only(parsed_input),

Source: GitHub Commit Update

Detection Methods for CVE-2026-22682

Indicators of Compromise

• File access attempts targeting sensitive system files (e.g., /etc/passwd, .ssh/id_rsa, application configuration files) from OpenHarness agent processes
• Unexpected file operations in restricted directories outside the designated repository scope
• Agent tool execution logs showing read_file, write_file, edit_file, or notebook_edit operations with paths outside expected boundaries
• New or modified files appearing in restricted host paths when full_auto mode is enabled

Detection Strategies

• Implement file integrity monitoring (FIM) on sensitive directories to detect unauthorized access or modifications
• Monitor OpenHarness agent logs for file tool invocations with absolute paths or path traversal sequences (e.g., ../)
• Configure audit logging for file system operations performed by the OpenHarness process user
• Deploy application-layer logging to capture all PermissionChecker.evaluate() calls and their results

Monitoring Recommendations

• Enable verbose logging for OpenHarness file tool operations and regularly review for anomalous path access patterns
• Set up alerting for file operations targeting well-known sensitive file paths such as SSH keys, credentials, and system configuration files
• Monitor for process activity indicating bulk file reads or writes that may indicate data exfiltration attempts
• Implement network monitoring for unusual data transfers originating from systems running OpenHarness

How to Mitigate CVE-2026-22682

Immediate Actions Required

• Update OpenHarness to commit 166fcfefb7614dbac51bd061f56542725b0298e9 or later immediately
• Review system logs for evidence of unauthorized file access attempts prior to patching
• Audit any systems that have been running OpenHarness in full_auto mode for unauthorized file modifications
• Rotate any credentials or SSH keys that may have been exposed on affected systems

Patch Information

The vulnerability is fixed in commit 166fcfefb7614dbac51bd061f56542725b0298e9. The patch introduces two new helper functions (_resolve_permission_file_path and _extract_permission_command) that normalize tool input parameters before permission checks. This ensures path-based rules apply consistently across all built-in tools regardless of whether they use file_path or path as the parameter name.

For detailed patch information, see the GitHub Pull Request and the VulnCheck Advisory.

Workarounds

• Disable full_auto mode until the patch can be applied to prevent unauthorized file writes
• Restrict the OpenHarness process to run under a dedicated user account with minimal file system permissions
• Implement additional access controls at the operating system or container level to limit file access scope
• Deploy network segmentation to isolate OpenHarness instances from sensitive systems containing credentials or configuration data

# Configuration example
# Run OpenHarness with restricted file system access using a dedicated user
# Create a restricted user for OpenHarness
sudo useradd -r -s /bin/false openharness-runner

# Set restrictive permissions on sensitive directories
sudo chmod 700 /root/.ssh
sudo chmod 600 /root/.ssh/*

# Run OpenHarness with the restricted user
sudo -u openharness-runner openharness --mode=supervised