CVE-2026-6823: HKUDS OpenHarness Auth Bypass Vulnerability

CVE-2026-6823 Overview

HKUDS OpenHarness prior to PR #147 remediation contains an insecure default configuration vulnerability where remote channels inherit allow_from = ["*"] permitting arbitrary remote senders to pass admission checks. Attackers who can reach the configured channel can bypass access controls and reach host-backed agent runtimes, potentially leading to unauthorized file disclosure and read access through default-enabled read-only tools.

Critical Impact

Remote attackers can bypass access control mechanisms on OpenHarness remote channels, potentially gaining unauthorized read access to sensitive files through default-enabled tools without requiring authentication.

Affected Products

• HKUDS OpenHarness versions prior to v0.1.7
• Installations using remote channels (Telegram, etc.) with default configurations
• Systems running OpenHarness with unpatched ohmo/cli.py and channels/impl/manager.py

Discovery Timeline

• 2026-04-21 - CVE CVE-2026-6823 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-6823

Vulnerability Analysis

This vulnerability stems from an insecure default configuration in OpenHarness's remote channel implementation. The core issue lies in how the allow_from parameter is initialized and handled during channel setup. When users configure remote channels such as Telegram, the system defaults to accepting messages from all senders (["*"]), effectively disabling access control entirely.

The vulnerability is classified under CWE-276 (Incorrect Default Permissions), as the software establishes overly permissive defaults that violate the principle of least privilege. In the context of OpenHarness—which provides agent runtimes with host-backed tools—this misconfiguration allows unauthorized parties to interact with agents that may have read access to local files.

Root Cause

The root cause is twofold:

1. Default wildcard allowlist: The CLI prompts in ohmo/cli.py defaulted to ["*"] when no explicit allow_from values were provided, automatically granting access to all remote senders
2. Error on empty list: The channel manager in manager.py raised a SystemExit error when allow_from was empty, effectively forcing users toward the permissive wildcard configuration rather than encouraging explicit allowlisting

This design choice prioritized ease of initial setup over security, creating an attack surface for any installation using remote channel functionality.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker with network access to the configured channel endpoint can:

1. Send messages to the OpenHarness remote channel (e.g., Telegram bot)
2. Pass admission checks due to the wildcard allow_from configuration
3. Interact with agent runtimes that have default read-only tool access enabled
4. Potentially read sensitive files accessible to the host-backed agent runtime

# Vulnerable code in ohmo/cli.py - defaulting to wildcard allowlist
         else:
             enabled.append(channel)
         allow_from_raw = _text_prompt(
-            f"{channel} allow_from (comma separated, '*' for everyone)",
-            default=",".join(prior.get("allow_from", ["*"])) or "*",
+            f"{channel} allow_from (comma separated user/chat IDs; leave blank to deny all; '*' for everyone)",
+            default=",".join(prior.get("allow_from", [])),
         )
-        allow_from = [item.strip() for item in allow_from_raw.split(",") if item.strip()] or ["*"]
+        allow_from = [item.strip() for item in allow_from_raw.split(",") if item.strip()]
         config: dict[str, object] = {"allow_from": allow_from}
         if channel == "telegram":
             config["token"] = _text_prompt(

Source: GitHub Commit Update

# Vulnerable code in manager.py - forcing users away from secure empty allowlist
     def _validate_allow_from(self) -> None:
         for name, ch in self.channels.items():
             if getattr(ch.config, "allow_from", None) == []:
-                raise SystemExit(
-                    f'Error: "{name}" has empty allowFrom (denies all). '
-                    f'Set ["*"] to allow everyone, or add specific user IDs.'
+                logger.warning(
+                    '%s channel has empty allow_from; remote access is denied until an operator explicitly adds allowed identities or chooses ["*"].',
+                    name,
                 )

     async def _start_channel(self, name: str, channel: BaseChannel) -> None:

Source: GitHub Commit Update

Detection Methods for CVE-2026-6823

Indicators of Compromise

• Configuration files containing "allow_from": ["*"] for remote channel entries
• Unexpected remote channel message activity from unrecognized user or chat IDs
• Agent runtime logs showing file read operations initiated by unknown senders
• Unusual outbound data from systems running OpenHarness remote channels

Detection Strategies

• Audit OpenHarness configuration files for wildcard (*) entries in the allow_from field
• Monitor channel message logs for requests from user IDs not on an approved allowlist
• Implement logging at the agent runtime layer to track file access operations and their originating senders
• Review network traffic to OpenHarness endpoints for unexpected connection patterns

Monitoring Recommendations

• Enable verbose logging on all remote channel handlers to capture sender identification
• Set up alerts for any agent runtime file operations triggered via remote channels
• Establish baseline behavior for legitimate remote channel usage and alert on anomalies
• Periodically audit allow_from configurations across all deployed OpenHarness instances

How to Mitigate CVE-2026-6823

Immediate Actions Required

• Upgrade OpenHarness to version v0.1.7 or later which includes the security fix
• Review and update all remote channel configurations to use explicit user/chat ID allowlists
• Remove wildcard (*) entries from allow_from configurations immediately
• Disable remote channels temporarily if explicit allowlists cannot be configured promptly

Patch Information

The vulnerability has been addressed in PR #147 and is included in OpenHarness v0.1.7. The fix changes the default behavior:

1. The CLI no longer defaults to ["*"]—users must explicitly provide allowed identities
2. An empty allow_from list now logs a warning instead of forcing an error, allowing deny-by-default configurations
3. Prompt text has been clarified to explain the security implications of using wildcards

For detailed technical changes, see the security commit.

Workarounds

• Manually edit configuration files to replace ["*"] with specific user/chat IDs for each remote channel
• Implement network-level access controls to restrict which systems can reach the remote channel endpoints
• Disable default read-only tools in agent runtimes if they are not operationally required
• Deploy a reverse proxy with authentication in front of remote channel endpoints

# Configuration example - updating allow_from in OpenHarness config
# Before (vulnerable):
# "telegram": {
#   "allow_from": ["*"],
#   "token": "your-bot-token"
# }

# After (secure - explicit allowlist):
# "telegram": {
#   "allow_from": ["123456789", "987654321"],
#   "token": "your-bot-token"
# }

# Verify current configuration
grep -r "allow_from" ~/.config/openharness/

# Check for wildcard entries
grep -r '"allow_from".*"\*"' ~/.config/openharness/