CVE-2026-52877 in Streambert
Summary
by MITRE • 08/19/2026
Streambert is a cross-platform Electron Desktop App to stream and download video content. Prior to version 2.6.0, the open-external IPC handler in src/ipc/downloads.js passes a renderer-supplied url directly to Electron's shell.openExternal without validating its protocol. A compromised renderer can submit file: URIs or operating-system-specific custom schemes, causing the host to open local files, access remote resources through registered handlers, or launch scripts and applications supported by those handlers. This issue is fixed in version 2.6.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Streambert prior to version 2.6.0 represents a critical security flaw within the application's inter-process communication (IPC) architecture. As an Electron-based desktop application designed for streaming and downloading video content, Streambert relies on a separation of concerns between the main process, which handles system-level operations, and renderer processes, which manage user interface rendering. The specific weakness resides in the open-external IPC handler located within the src/ipc/downloads.js module. This handler is responsible for delegating URL opening requests to Electron's shell.openExternal API, a function that interacts with the host operating system to launch default applications or browsers associated with specific protocols. However, prior to the patch, this handler failed to implement any validation logic regarding the protocol scheme of the URLs supplied by renderer processes. This lack of input sanitization allows malicious actors who have achieved code execution within a renderer process to manipulate the behavior of the main process in unintended and potentially dangerous ways.
From a technical perspective, the core issue is an improper restriction on resource access, specifically categorized under CWE-20 as Improper Input Validation. By passing a renderer-supplied URL directly to shell.openExternal without verifying that it adheres to safe protocols such as HTTP or HTTPS, the application exposes itself to protocol injection attacks. An attacker who compromises a renderer process can submit file: URIs, which instruct the operating system to open local files from the user's filesystem. This capability bypasses standard sandboxing mechanisms because shell.openExternal operates with the privileges of the main Electron process, effectively granting the compromised renderer elevated access to sensitive data stored locally on the machine. Furthermore, the vulnerability extends beyond just file access; it allows for the use of operating-system-specific custom schemes. If the host system has registered handlers for non-standard protocols, such as mailto:, tel:, or proprietary application links, an attacker can exploit these registrations to trigger arbitrary actions. This could include launching scripts, executing applications, or initiating network connections through third-party services that have associated protocol handlers installed on the victim's machine.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and data exfiltration within the context of the desktop application. Since Electron applications often run with higher privileges than web browsers, exploiting this flaw allows an attacker to bridge the gap between a potentially compromised web view and the underlying operating system. The ability to open local files means that sensitive documents, configuration files containing credentials, or cached media data could be accessed by external programs if those programs are triggered via custom schemes. Additionally, the exploitation of registered handlers can lead to unintended code execution on the host machine. For instance, if a malicious actor crafts a URL using a scheme associated with an executable application, that application will launch automatically upon user interaction or even silently depending on system configuration and security policies. This vector is particularly dangerous in enterprise environments where Streambert might be deployed across multiple endpoints, as it provides a reliable method for lateral movement or initial access if the application processes untrusted content from external sources such as downloaded videos or embedded links within streams.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, reflecting its nature and exploitation methodology. It is primarily associated with T1059 Command and Scripting Interpreter, specifically when custom schemes are used to launch scripts or applications. The ability to access local files corresponds to T1083 File and Directory Discovery, as it allows an attacker to enumerate and read sensitive information from the victim's file system without direct filesystem API calls in JavaScript. Furthermore, the exploitation of registered handlers relates to T1215 Command Injection, where external programs are invoked through indirect means via protocol associations. These mappings highlight that while the vulnerability originates within a specific application module, its effects ripple out into broader categories of post-exploitation activities common in desktop environment attacks.
To mitigate this risk and prevent similar vulnerabilities in future versions or other Electron applications, developers must enforce strict allowlisting on URL protocols handled by IPC mechanisms. The shell.openExternal function should never be called with user-supplied input without rigorous validation to ensure the protocol is one of a predefined safe set, typically limited to http: and https:. Any deviation from these expected schemes should result in an error being returned to the renderer rather than execution. Additionally, implementing Content Security Policy (CSP) directives that restrict navigation or external resource loading can provide an additional layer of defense against renderer compromise leading to main process manipulation. For users currently running versions prior to 2.6.0, immediate upgrading is strongly recommended as this issue has been resolved in version 2.6.0 through the implementation of proper protocol validation within the downloads IPC handler. Security auditors and penetration testers should also review other IPC handlers in Electron applications for similar patterns of unchecked input delegation to system APIs to ensure comprehensive defense against inter-process communication exploits.