CVE-2025-55002 in JupyterLab
Summary
by MITRE • 11/06/2026
JupyterLab Desktop is the cross-platform desktop application for JupyterLab. Prior to 4.6.2-1, JupyterLab Desktop for macOS shipped with Electron's RunAsNode fuse enabled, allowing ELECTRON_RUN_AS_NODE to execute arbitrary Node.js code in the application process. An attacker who can already execute code as the current user can therefore run code in JupyterLab Desktop's context and inherit TCC permissions previously granted to the application, including access to protected Documents, Desktop, or Downloads folders without another macOS prompt. Exploitation requires existing local code execution and prior TCC grants; it does not provide initial or remote code execution. Windows and Linux are not affected. This vulnerability is fixed in 4.6.2-1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
JupyterLab Desktop, a cross-platform desktop application designed to facilitate the use of JupyterLab environments, contained a significant security misconfiguration in versions prior to 4.6.2-1 on macOS systems. The core issue stems from Electron's RunAsNode fuse being enabled by default during the build and distribution process for this specific platform. This configuration allows the environment variable ELECTRON_RUN_AS_NODE to be utilized effectively within the application context, fundamentally altering how code is executed inside the main process of the desktop application rather than in a separate renderer or sandboxed environment.
The technical flaw lies in the ability of an attacker who has already achieved local code execution as the current user to leverage this misconfiguration for privilege escalation and scope expansion. By setting the ELECTRON_RUN_AS_NODE variable, the attacker can force the Electron main process to execute arbitrary Node.js scripts directly within JupyterLab Desktop's runtime environment. This capability bypasses standard sandboxing mechanisms that would typically isolate web content from system-level resources, thereby allowing malicious code to interact with the application as if it were a native part of the desktop suite rather than an embedded web view.
The operational impact of this vulnerability is substantial due to macOS-specific security architecture known as TCC (Transparency, Consent, and Control). Because JupyterLab Desktop has been granted specific permissions by the user through standard system prompts, such as access to protected directories like Documents, Desktop, or Downloads folders, any code running within its context inherits these privileges. Consequently, an attacker exploiting this flaw can read, modify, or exfiltrate sensitive files from these locations without triggering additional macOS permission dialogs. This effectively bypasses a critical layer of user consent and data protection provided by the operating system's privacy framework.
It is crucial to note that exploitation requires pre-existing local code execution capabilities on the target machine; this vulnerability does not provide initial access or remote code execution vectors. An attacker must already have compromised the user account at some level, such as through a malicious script executed in a browser or another application, before they can leverage JupyterLab Desktop for further lateral movement or data theft. Furthermore, this issue is specific to macOS and does not affect Windows or Linux deployments of JupyterLab Desktop, highlighting the platform-specific nature of Electron's integration with OS-level security features like TCC.
To mitigate this risk, users must upgrade immediately to version 4.6.2-1 or later, where the RunAsNode fuse is disabled by default for macOS builds. This update ensures that Node.js code execution within the main process cannot be triggered via environment variable manipulation, thereby restoring the intended isolation boundaries between user-executed scripts and application-level privileges. Security teams should also audit existing local security policies to ensure that no other applications are similarly misconfigured with Electron's RunAsNode feature enabled unnecessarily, as this pattern poses a general risk across various desktop applications built on the same framework.
From an industry standards perspective, this vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, and CWE-78, improper neutralization of special elements used in an OS command, specifically regarding environment variable injection. In terms of adversary tactics, it maps to MITRE ATT&CK technique T1610, which involves dropping and executing a payload within the context of another process or service that has higher privileges than the initial access vector. Understanding these mappings helps security professionals categorize similar Electron-based vulnerabilities across different software ecosystems and prioritize remediation efforts based on potential data exposure risks rather than just initial compromise capabilities.