CVE-2026-52873 in Streambert
Summary
by MITRE • 08/19/2026
Streambert is a cross-platform Electron Desktop App to stream and download video content. From version 2.5.0 until version 2.6.0, the wyzie-open-redeem IPC handler in index.js creates the partition:wyzie-redeem Electron session and registers an onHeadersReceived hook that removes the Content-Security-Policy header from every response in that session. The redeem window also lacks a setWindowOpenHandler restriction, so script injection in sub.wyzie.io, a loaded third-party resource, or a site reached through navigation executes without CSP constraints and can affect additional windows and persistent session storage. A user must open the Wyzie API key redemption window, and exploitation requires attacker-controlled script content in a loaded page. The resulting renderer script can invoke renderer-exposed application functionality and can be chained with other vulnerabilities to access internal services or sensitive data. This issue is fixed in version 2.6.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Streambert versions 2.5.0 through 2.6.0 represents a critical failure in the application's security architecture, specifically concerning how Electron sessions are configured and managed during specific user interactions. Streambert is an Electron-based desktop application designed for streaming and downloading video content from various platforms. The core of this vulnerability lies within the index.js file, where the wyzie-open-redeem IPC handler initializes a new Electron session with the partition name wyzie-redeem. This initialization process includes registering an onHeadersReceived hook that actively strips the Content-Security-Policy header from every HTTP response received by that specific session. By removing this essential security directive, the application effectively disables one of the primary defenses against Cross-Site Scripting and other code injection attacks for any content loaded within that session context.
The removal of the Content-Security-Policy header creates a permissive execution environment where arbitrary JavaScript can run without restriction. This is compounded by another significant architectural flaw: the redeem window lacks a setWindowOpenHandler restriction. In modern Electron applications, this handler is crucial for controlling how new windows are opened and what permissions they inherit. Without it, any script executed within the compromised session gains the ability to open new browser windows or tabs that also lack security constraints. This allows an attacker who has managed to inject malicious scripts into a loaded page to not only execute code in the current context but also propagate their influence across multiple windows and potentially access persistent session storage mechanisms that are typically isolated from standard web content.
Exploitation of this vulnerability requires specific conditions, primarily involving social engineering or supply chain compromise scenarios where an attacker can control script content within a third-party resource loaded by Streambert. Specifically, the attack vector targets sub.wyzie.io, which is identified as a loaded third-party domain. If an attacker can inject malicious JavaScript into pages hosted on this domain, that code will execute with elevated privileges due to the missing CSP and window handling restrictions. The renderer process script gains access to application functionality exposed via IPC channels, allowing it to interact directly with the host system or internal services of the Streambert application. This capability transforms a standard web-based injection vulnerability into a potential remote code execution vector within the desktop environment.
The operational impact is severe because the compromised renderer can chain this flaw with other vulnerabilities to access sensitive data stored in persistent session storage or invoke internal APIs that should be restricted from untrusted content. Since Electron applications often bridge the gap between web technologies and native system capabilities, bypassing CSP allows attackers to potentially read local files, exfiltrate user credentials, or manipulate application state in ways intended to be prevented by browser security models. The lack of window open handlers further exacerbates this risk by allowing the creation of new contexts that inherit these weak configurations, expanding the attack surface beyond a single tab or view.
Mitigation for this issue involves ensuring that all Electron sessions enforce strict Content-Security-Policy headers and do not strip them during response processing. Developers must implement setWindowOpenHandler to restrict how new windows are created and ensure they inherit appropriate security policies rather than inheriting permissive settings from their parent contexts. Additionally, IPC handlers should validate the origin of requests and avoid exposing sensitive application functionality directly to renderer processes without rigorous checks. Users running versions 2.5.0 through 2.6.0 must upgrade immediately to version 2.6.0 or later where these architectural flaws have been corrected. This incident highlights the importance of adhering to industry standards such as CWE-79 for Cross-Site Scripting and aligning with MITRE ATT&CK techniques related to client-side code injection, particularly those involving Electron-specific privilege escalation paths like T1564.002 or similar mechanisms where web content gains unintended access to native features.