JupyterLab Desktop stores a renderer that can access server information through an exposed getServerInfo interface. Before version 4.6.2‑1, the interface was sent to the renderer without confirming that the original page’s origin matched the local Jupyter server origin. An attacker can embed a malicious MathJax link into an untrusted notebook. When a user opens that notebook and follows the link, the renderer navigates to the attacker’s site while the preload bridge remains active. From there the attacker can retrieve the local server URL and authentication token via getServerInfo and then use the Jupyter REST API to create or trust a notebook that runs arbitrary code as the user. The flaw thus enables remote code execution and full compromise of the victim’s environment.

Affected systems are installations of JupyterLab Desktop older than 4.6.2‑1 that employ a local managed session with JupyterLab 4.4.8 or earlier. A notebook that is not pre‑trusted and contains a crafted MathJax link can trigger the exploit. The vulnerability does not apply to users running JupyterLab Desktop 4.6.2‑1 or later, and the fix in 4.4.8 onwards already sanitizes link handling, making earlier sessions safe once upgraded.

The CVSS score of 9.6 places this vulnerability in the critical range, and the absence of an EPSS score means there is no publicly documented exploitation probability yet. The issue is not listed in CISA’s KEV catalog. Exploitation requires a user to open a manipulated notebook and click a malicious link, a scenario that can be witnessed in collaborative or shared notebook environments. Once the attacker obtains the token, they can execute arbitrary code with the victim’s privileges, potentially leading to full system compromise. Although passive exploitation is unlikely, the high impact and local-to-remote escalation path make this a priority risk for any environment that allows untrusted notebooks.