CVE-2026-92299 in Electron SDKinfo

Summary

by MITRE • 09/16/2026

@jitsi/electron-sdk before 10.0.5 exposes getDesktopSources() via contextBridge without requiring an active getDisplayMedia() picker, allowing any script in the meeting page to enumerate screens and windows. Attackers can call the jitsi-screen-sharing-get-sources IPC route to retrieve desktop thumbnails at arbitrary resolution without user consent or operating system permission prompts.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 09/16/2026

The vulnerability identified in @jitsi/electron-sdk prior to version 10.0.5 represents a critical security flaw rooted in improper access control within the Electron framework's context bridge mechanism. The core issue lies in the exposure of the getDesktopSources() function through the contextBridge without enforcing necessary user consent or operating system permission prompts. In standard secure implementations, accessing sensitive system resources such as screen content typically requires explicit user interaction via a native picker dialog to grant permissions. However, this flaw allows any script executing within the meeting page environment to invoke the jitsi-screen-sharing-get-sources IPC route directly. This bypasses the expected security boundaries that are designed to prevent unauthorized surveillance or data exfiltration by malicious scripts embedded in web pages interacting with Electron-based applications.

From a technical perspective, the exploitation of this vulnerability enables an attacker to enumerate available screens and windows on the victim's machine without triggering any visual indicators or permission requests from the operating system. The ability to retrieve desktop thumbnails at arbitrary resolution significantly amplifies the risk, as it allows for high-fidelity capture of sensitive information displayed on the user's screen. This capability effectively transforms a video conferencing application into an unauthorized surveillance tool. Since the function is exposed via contextBridge, which is intended to safely expose specific Node.js APIs to web content, the lack of proper validation or consent checks means that any third-party script injected into the meeting page can exploit this interface. This scenario highlights a failure in implementing least privilege principles and secure IPC communication patterns within the Electron application architecture.

The operational impact of this vulnerability is severe, particularly for enterprise users who rely on Jitsi Meet for confidential business discussions or handle sensitive data during remote work sessions. An attacker with access to the meeting page, potentially through cross-site scripting vulnerabilities in integrated third-party tools or malicious plugins, can silently capture screen contents. This leads to direct confidentiality breaches where proprietary information, personal identifiers, or private communications are exposed without the user's knowledge. The absence of OS-level permission prompts means victims remain unaware that their desktop is being monitored and recorded. This lack of transparency undermines trust in the application and poses significant risks for organizations subject to strict data protection regulations such as GDPR or HIPAA, where unauthorized access to screen content could constitute a reportable security incident.

To mitigate this vulnerability, it is imperative to upgrade @jitsi/electron-sdk to version 10.0.5 or later, which addresses the improper exposure of desktop enumeration APIs. Developers should ensure that any IPC routes related to sensitive system resources enforce strict access controls and require explicit user consent before execution. Implementing a native picker dialog for screen sharing operations aligns with industry best practices and ensures transparency regarding data access. Furthermore, security audits should focus on reviewing contextBridge configurations to prevent the accidental exposure of powerful Node.js APIs that could be abused by web content. Adhering to these remediation steps helps restore the integrity of the application's security model and prevents unauthorized surveillance capabilities from being exploited in production environments.

This vulnerability aligns with CWE-284, which describes Improper Access Control, as it involves a failure to restrict access to sensitive functions based on user authorization or consent. Additionally, it relates to CWE-798, Use of Hard-coded Credentials, if the IPC route is accessible without proper authentication mechanisms in certain configurations, though primarily it reflects an architectural flaw in permission handling. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1056, Input Capture, specifically screen capture sub-techniques like T1113 Screen Capturing. The ability to enumerate and capture desktop content without user interaction exemplifies a stealthy data collection method that bypasses standard defensive monitoring mechanisms designed around explicit permission grants.

Responsible

VulnCheck

Reservation

09/16/2026

Disclosure

09/16/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!