Which versions of OpenHarness are affected by CVE-2026-6823?

HKUDS OpenHarness versions prior to v0.1.7 contain an insecure default configuration that allows any remote sender to access the host without credentials, enabling unauthorized file disclosure…. A patch is available.

How to fix or mitigate CVE-2026-6823?

Within 24 hours, audit your environment to identify all HKUDS OpenHarness deployments and confirm which are running versions prior to v0.1.7. Within 7 days, update all affected instances to v0.1.7 or later, beginning with production and internet-facing systems. Within 30 days, review host access logs for unauthorized file access attempts that occurred prior to patching and conduct a final inventory sweep to confirm no instances were missed during rollout.

OpenHarness CVE-2026-6823

Q: What is the CVSS score of CVE-2026-6823?

CVE-2026-6823 has a CVSS 4.0 base score of 8.3 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-24505 HIGH

Incorrect Default Permissions (CWE-276)

2026-04-21 VulnCheck

GHSA-564h-hx6x-wg47

Privilege Escalation Openharness Hkuds

8.3

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

8.3 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.5 MEDIUM

Network-reachable with no auth (PR:N) but the attacker must reach the specific channel, mapping AT:P to AC:H; impact is high confidentiality read access with only minor integrity and no availability effect.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 24, 2026 - 05:40 vuln.today

Analysis Generated

Jul 24, 2026 - 05:40 vuln.today

CVSS changed

Apr 21, 2026 - 21:22 NVD

8.2 (HIGH) 8.3 (HIGH)

EUVD ID Assigned

Apr 21, 2026 - 21:01 euvd

EUVD-2026-24505

Patch released

Apr 21, 2026 - 21:01 nvd

Patch available

CVE Published

Apr 21, 2026 - 20:36 nvd

HIGH 8.3

DescriptionCVE.org

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.

AnalysisAI

Unauthorized remote access in HKUDS OpenHarness (all versions prior to the PR #147 fix, released as v0.1.7) stems from an insecure default where every enabled remote channel is created with allow_from = ["*"], so any sender able to reach the channel passes the admission check without being an approved identity. Once past admission, an attacker reaches host-backed agent runtimes and can invoke the default-enabled read-only tools, enabling unauthorized file disclosure and read access on the host. Publicly available exploit code exists (SSVC 'poc') but it is not on CISA KEV, and EPSS is very low at 0.08%.

Technical ContextAI

OpenHarness is an agent/harness gateway (the 'ohmo' CLI plus the openharness library) that bridges remote messaging channels - Telegram, Slack, Discord, Feishu - to host-backed AI agent runtimes exposing tools such as file readers. Admission control for each channel is governed by an allow_from allowlist of user/chat IDs. The root cause is CWE-276 (Incorrect Default Permissions): in src/openharness/config/schema.py the ProviderConfigs.allow_from field defaulted to Field(default_factory=lambda: ["*"]), and the ohmo CLI likewise defaulted the prompt to '*', so simply enabling a channel implicitly trusted every remote sender. The channel manager even raised a SystemExit forcing operators away from an empty (deny-all) list toward ["*"], reinforcing the insecure posture. CPE cpe:2.3:a:hkuds:openharness identifies the single affected application.

RemediationAI

Vendor-released patch: upgrade to OpenHarness v0.1.7 or later (which merges PR #147 at commit fab40c6eabfb15f2bdf23cddd3cfe66a64ea203d), where allow_from now defaults to an empty deny-all list and enabling a channel no longer implicitly trusts all senders. If you cannot upgrade immediately, edit gateway.json and explicitly set each channel's allow_from to the specific approved user/chat IDs (for example "allow_from": ["123456"]) instead of ["*"]; an empty list denies all remote access, so use that to fully close a channel until identities are vetted - the trade-off is that legitimate users must be enumerated and any omitted ID is blocked. As a stronger compensating control, disable any remote channel that is not strictly required, and restrict network reachability to the gateway so only trusted senders can connect to the configured channel. Advisory and patch URLs: https://github.com/HKUDS/OpenHarness/pull/147 and https://www.vulncheck.com/advisories/hkuds-openharness-insecure-default-remote-channel-allowlist.