al-ice.ai

Seven Advisories, One Harness: OpenHuman’s November CVE Batch Turns Channels and Tool Text Into Code Execution

Agent & Supply Chain Security by al-ice.ai Editorial

On 5 November 2026, seven CVE records for the open-source agent harness OpenHuman (desktop app plus Rust library) arrived in NVD at once — CVE-2026-54140 through CVE-2026-54146 — formalizing GitHub advisories the project published on 9 October. Taken together they read like a guided tour of every trust boundary an agent harness owns: two criticals (a 9.8 unauthenticated remote path to host command execution, a 9.0 approval bypass on a messaging channel), two high-severity indirect-injection flaws (8.7 via background sync, 8.3 via MCP tool descriptions), two high-severity bearer-token leaks (8.8 each), and a medium-severity silent screen-capture primitive (6.1). The fixes shipped across releases 0.56.0, 0.57.5, and 0.57.13 — but the CVE publication is what makes the exposure checkable, and any deployment that has not tracked those releases is now documented-vulnerable.

The worst of the batch: messages that become cron jobs

CVE-2026-54143 (CVSS 9.8, AV:N/AC:L/PR:N/UI:N) is the one to patch first. Before 0.57.13, an attacker who could merely send messages to a configured external channel could get the agent to create persistent shell cron jobs without human approval — jobs the scheduler later executes with the OpenHuman runtime user's privileges, with command validation weak enough to admit smuggled prefixes. No authentication, no user interaction, network-reachable, full host compromise: the vector string is the nightmare. Sitting beside it, CVE-2026-54141 (9.0) shows the approval layer failing from the inside: a remote direct message arriving through a configured Yuanbao channel was converted into a generic turn request under the default tool policy without establishing an interactive approval context, so under the default Supervised autonomy policy with Node enabled, node_exec ran unbypassed — approval existed in the UI but not on the code path the message actually traveled. And CVE-2026-54142 (8.7) closes the triangle: background synchronization for email, Slack, and Notion stored raw external content and later placed it in the model context of autonomous background agents without neutralizing embedded instructions, while ApprovalGate treated tool calls lacking an interactive chat context as approvable — so a poisoned email or Slack message could drive Composio actions with nobody at the keyboard. Three different doors, one lesson: every inbound channel is a prompt channel, and approval that is not bound to the actual execution path is decoration.

Tool descriptions are attacker-controlled text

CVE-2026-54140 (8.3, scope-changed) is the batch's most instructive finding for the wider ecosystem. Before 0.57.13, OpenHuman placed names, descriptions, titles, and parameter definitions returned by configured external MCP servers into the agent model context without neutralizing instructions or bounding the descriptive fields, and the McpRemoteTool records produced by list_tools preserved that remote content verbatim. A malicious or compromised MCP server therefore did not need a vulnerability in OpenHuman at all — its tool metadata was the payload, executed in the agent's reasoning context with confidentiality, integrity, and availability all rated high on the other side. The fix (upstream PR #3215, released in 0.57.13) sanitizes remote tool descriptions and caps their length. This is the same attack class our November coverage of the 9,720-cell MCPVenom measurement showed no framework stopping — and here it is again, not as a benchmark result but as a named CVE in a shipping harness. If you operate any MCP client, the question is not whether your servers are benign today but whether your context pipeline would survive one that is not.

Tokens in the furniture, glass in the meeting room

The remaining three round out the batch with credential-handling failures. CVE-2026-54145 (8.8): the approval gate used the JSON-RPC bearer token itself as the approval session identifier, scattering the credential through persisted approval records, events, debug logs, and RPC responses during normal desktop operation — fixed in 0.57.5. CVE-2026-54146 (8.8): on macOS, the Tauri desktop process published the per-launch OPENHUMAN_CORE_TOKEN bearer credential in its process environment even though the core had moved in-process, so any same-user process could read it through the KERN_PROCARGS2 inspection interface — a local RCE primitive hiding in an environment variable, fixed in 0.57.5. And CVE-2026-54144 (6.1): before 0.56.0 on macOS, the shim injected into supported remote-account webviews such as Google Meet let page JavaScript call getDisplayMedia without a live user gesture, falling through to native Chromium capture that can auto-select the primary display — silent desktop capture from inside a meeting webview. None of these is as dramatic as the cron-job RCE, but token-shaped flaws are the ones that convert every other bug into account takeover, and they are the ones operators most often leave unrotated.

What to actually do

  1. Upgrade to 0.57.13 or later (at minimum 0.57.5 for the token leaks, 0.56.0 for the webview capture — but take the latest). Then rotate everything: JSON-RPC bearer tokens, approval-gate stores, and any credential that ever transited debug logs, SQLite approval records, or macOS process environments. The 54145/54146 leaks mean tokens must be treated as already exposed on any long-running pre-fix install.
  2. Audit your inbound channels as prompt-injection surfaces. If OpenHuman (or any harness) ingests Yuanbao DMs, email, Slack, or Notion into autonomous agents, verify that every such path establishes an interactive approval context before tool execution — and that background/scheduled agents cannot approve their own tool calls. The 54141/54142 pattern (right policy, wrong code path) is worth grepping for in your own integrations.
  3. Bound and sanitize all third-party tool metadata before it reaches model context — MCP servers included. Treat tool names, descriptions, and parameter schemas as untrusted input with length caps and instruction neutralization, per the 54140 fix, and prefer pinned, reviewed servers. Our October OpenHuman loopback-control-plane coverage shows this is the project's second disclosure round this quarter — track its advisories, not just its releases.
  4. For builders: never use a bearer credential as a record identifier that gets persisted, logged, or echoed — and never leave a moved-in-process secret in the process environment. Both 8.8s were entirely avoidable with a random session ID and an env-var scrub at startup.

Our verification was read-only. We read the NVD 2.0 API records first-hand for all seven CVEs (each published 5 November 2026 ~17:18 UTC: full descriptions, CVSS 3.1 vectors and scores, and reference lists naming the fix commits, the v0.57.13 release tag, and the GHSA advisories), the complete GitHub security-advisory records via API (summaries, severities, affected/patched ranges, 9 October 2026 publication), and the v0.57.13 release notes (3 June 2026, including the MCP description-sanitization and length-cap change). One NVD request in the batch hit API rate limiting and its score was carried from the matching GHSA record instead, stated openly here. We cloned no repo, ran no harness, connected no channel, sent no message, and contacted no vendor. Brave Search was used for discovery only.

Sources: