CVE-2026-54144 in OpenHuman
Summary
by MITRE • 11/05/2026
OpenHuman is an open-source agent harness available as a desktop application and Rust library. Before 0.56.0 on macOS, the runtime injected into a supported remote account webview such as Google Meet allows page JavaScript to call getDisplayMedia without a live user gesture. Instead of rejecting the request, the shim falls through to native Chromium capture behavior, and the embedded CEF environment can auto-select the primary display because it lacks the normal desktop-media picker. If OpenHuman already has macOS Screen Recording permission and an attacker obtains JavaScript execution in an allowed embedded origin, the attacker can obtain a real desktop capture stream without a new user gesture. The stream can expose chats, documents, source code, email, meeting content, credentials, one-time codes, and other visible desktop information. The separate direct screen_share_begin_session IPC path failing origin validation does not prevent exploitation through getDisplayMedia. This issue is fixed in version 0.56.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified within OpenHuman versions prior to 0.56.0 on macOS represents a critical failure in the enforcement of user consent mechanisms for screen capture, specifically affecting the embedded Chromium Embedded Framework (CEF) environment used by the application. As an open-source agent harness available as both a desktop application and a Rust library, OpenHuman relies on webview technologies to render remote content. The core technical flaw lies in how the runtime handles requests from page JavaScript to invoke the getDisplayMedia API for screen sharing. Under normal security protocols, browser engines require a distinct, live user gesture such as a mouse click or key press to initiate media capture, ensuring that the action is intentional and authorized by the human operator. However, due to an implementation error in the shim layer before version 0.56.0, these JavaScript calls are not rejected when lacking such gestures. Instead, the runtime falls through to native Chromium capture behavior, which on macOS lacks a desktop-media picker interface that would normally force user interaction and selection of specific windows or displays.
This architectural oversight allows an embedded CEF environment to auto-select the primary display without any further input from the user. The severity of this flaw is significantly amplified by the existing permission model of the application. If OpenHuman has already been granted macOS Screen Recording permissions, which are typically requested during initial setup and persist across sessions, an attacker who manages to obtain JavaScript execution within an allowed embedded origin can exploit this gap. By triggering getDisplayMedia without a user gesture, the attacker bypasses the intended consent flow entirely. The separate direct screen_share_begin_session IPC path also fails to perform adequate origin validation, further facilitating exploitation through alternative code paths that were not properly secured against unauthorized access from web contexts.
The operational impact of this vulnerability is severe and multifaceted, as it enables an attacker to obtain a real-time desktop capture stream without the user's knowledge or consent. This continuous surveillance capability allows for the exfiltration of highly sensitive information visible on the screen at any given moment. Attackers can monitor active chat applications, read documents, view source code repositories, access email clients, and observe meeting content from platforms like Google Meet. Furthermore, the stream exposes dynamic security credentials such as one-time passwords (OTPs), session tokens, and other transient authentication data that are often displayed on screen during login or verification processes. This effectively neutralizes multi-factor authentication protections for any service accessed via a web browser within the compromised environment, leading to potential account takeovers and broader system compromise.
From a classification perspective, this vulnerability aligns with CWE-201: Information Exposure Through Sent Data, as it allows unauthorized parties to receive sensitive information that should remain private. It also relates closely to CWE-798: Use of Hard-coded Credentials if the screen recording captures stored credentials or tokens displayed in UI elements. In terms of adversary tactics, this exploit maps directly to MITRE ATT&CK technique T1056.002: Input Capture: GUI Input Capture and T1113: Screen Capture, as it involves intercepting user interface interactions and capturing the visual output of the operating system for malicious purposes. The failure to enforce a live user gesture is also indicative of CWE-841: Improper Enforcement of Behavioral Restrictions, where the application fails to restrict actions that require explicit user confirmation.
To mitigate this risk, organizations using OpenHuman must immediately upgrade to version 0.56.0 or later, which addresses these flaws by properly enforcing user gesture requirements and correcting origin validation in IPC paths. Until an update is applied, administrators should consider restricting the Screen Recording permission for OpenHuman if screen sharing functionality is not strictly required for their use case. Additionally, implementing strict Content Security Policies (CSP) within embedded webviews can help prevent unauthorized JavaScript execution from third-party origins, thereby reducing the attack surface available to potential exploiters. Regular audits of application permissions and monitoring for unusual screen capture activity via macOS system logs are also recommended defensive measures to detect any ongoing exploitation attempts in environments where older versions may still be deployed.