Openharness EUVD-2026-19746

Attacker must have low-privilege local access to execute OpenHarness agent tools (read_file, write_file, edit_file, notebook_edit). Affects OpenHarness versions prior to commit 166fcfe. Path parameter bypass in PermissionChecker allows arbitrary file access outside intended repository scope.

Real-world risk is moderate to high for organizations deploying OpenHarness in multi-user or automated agent environments. The CVSS 4.0 score of 8.4 reflects local attack vector with low complexity and low privileges required, resulting in high confidentiality and integrity impact with no availability impact. However, the practical risk depends heavily on deployment context: the attacker must already possess the ability to 'influence agent tool execution,' which suggests either authenticated access to the agent framework or exploitation of a separate input validation weakness. No public exploit identified at time of analysis, and EPSS probability data is unavailable for forward-dated CVEs, limiting automated exploitation risk assessment. The authentication requirement (PR:L) and local attack vector (AV:L) reduce exposure compared to unauthenticated remote vulnerabilities, but the potential for credential theft and SSH key exfiltration makes this a serious concern for environments where OpenHarness agents process untrusted inputs or operate in shared hosting scenarios. SSVC technical impact would be rated 'total' due to arbitrary file system access, though exploitation requires existing local access positioning.

An attacker with low-privilege authenticated access to an OpenHarness deployment influences agent tool execution through crafted inputs or workflow manipulation. By invoking read_file with a path parameter pointing to /home/user/.ssh/id_rsa while the PermissionChecker receives no path context, the attacker bypasses repository scope restrictions that would normally deny access to SSH private keys. The agent reads and returns the SSH key material, which the attacker exfiltrates. In full_auto mode, the attacker subsequently uses write_file to create a backdoor account by overwriting /etc/passwd or plants malicious code in system startup scripts, establishing persistent access beyond the OpenHarness framework itself.