Description

JupyterLab Desktop is the cross-platform desktop application for JupyterLab. Prior to 4.6.2-1, JupyterLab Desktop exposed getServerInfo to the renderer without confirming that the current page still had the local Jupyter server origin. In a local managed session using JupyterLab before 4.4.8, an attacker can place a crafted MathJax link in an untrusted notebook. If a victim opens the notebook and clicks the link, the existing renderer navigates to an attacker-controlled site while retaining access to the preload bridge. The site can call getServerInfo to obtain the local server URL and authentication token, then use the Jupyter REST API to create and trust a notebook that executes arbitrary code as the victim. Users whose environment already uses JupyterLab 4.4.8 or later are unaffected because the corrected link handling breaks the first step of the chain. This vulnerability is fixed in 4.6.2-1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-11-06T21:17:12.297Z",
  "pubdate": "2026-11-06T21:17:12.297Z",
  "executiveSummary": "JupyterLab Desktop prior to 4.6.2-1 is vulnerable to an improper origin validation flaw, specifically concerning the exposure of the getServerInfo function to the renderer process.\nThe vulnerability permits an attacker to perform unauthorized remote code execution by leveraging a Cross-Site Scripting (XSS) or navigation-based exploit chain within a notebook environment.\nBy coercing the renderer to navigate to an attacker-controlled site while maintaining the integrity of the preload bridge, an adversary can extract sensitive authentication tokens and server configuration details.\nThis facilitates the use of the Jupyter REST API to inject and execute malicious code under the victim's privileges.\nThe attack is mitigated by updating to version 4.6.2-1 or by utilizing JupyterLab 4.4.8 or later, which effectively restricts the initial exploitation vector by hardening link handling mechanisms.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient origin validation of the renderer process within JupyterLab Desktop. Specifically, the application failed to verify if the current page maintained the local Jupyter server origin before granting access to sensitive IPC (Inter-Process Communication) functions such as getServerInfo.\nThe exploitation lifecycle begins when an attacker injects a crafted MathJax link into a malicious or untrusted notebook file. When a user interacts with this link, the renderer navigates to an external, attacker-controlled domain. Crucially, due to improper origin checking, the renderer process retains its preload bridge connection to the local Jupyter server environment despite the change in top-level navigation.\nOnce the attacker's malicious site is rendered, it invokes the exposed getServerInfo function through the compromised preload bridge. This call returns the local server URL and the essential authentication token required to interact with the Jupyter REST API. With these credentials, the attacker can perform authenticated requests against the local server.\nThe post-exploitation phase involves the attacker utilizing the intercepted credentials to programmatically create and 'trust' a new notebook via the Jupyter REST API. By injecting malicious code into this notebook, the attacker achieves Remote Code Execution (RCE) with the full privileges of the local user session. Because the notebook is programmatically set to a 'trusted' state, the injected arbitrary code executes immediately upon opening or execution, bypassing standard security warnings.\nThe exposure is restricted to environments where the desktop application provides a bridge to the local server without validating the origin of the requesting page. This vulnerability is present in versions of JupyterLab Desktop prior to 4.6.2-1. Environments already leveraging JupyterLab 4.4.8 or later are inherently protected, as the patch implemented in that version updates the link handling logic, effectively preventing the initial navigation to the attacker-controlled origin that triggers the privilege escalation chain."
}