Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
21 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A Markdown file or a notebook output can carry a button that runs a JupyterLab command. Since 4.5.7 the first click on such a button opens a prompt naming the command, with Cancel, Run Once and Trust. Choosing Trust runs the command and marks the document trusted, so its later buttons run without a prompt. Which document gets marked is decided when the user answers, not when they click. Both trust commands read whichever document is current at that moment: markdownviewer:trust uses tracker.currentWidget, and notebook:trust uses the equivalent lookup. If another document becomes current while the prompt is open, that document is the one marked trusted, and the one the user was looking at stays untrusted. Users are affected if all of the following are true: - they run JupyterLab 4.5.7 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - they open a Markdown file or notebook from someone else and click a button in it; - they answer Trust rather than…
Recommended action: Upgrade to 7.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing metadata.trusted, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the <script elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with "trusted": false is sanitized. Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, useSystemClipboardForCells is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - pasteCodeCellsWithoutOutput is off, the default, so the pasted cell keeps…
Recommended action: Upgrade to 7.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab's HTML sanitizer allowlists data-commandlinker-command and data-commandlinker-args on button elements, while CommandLinker listens for all click events on document.body and executes the named command without checking whether the element came from trusted JupyterLab UI. A notebook with a pre-saved HTML cell output containing a deceptive button can trigger arbitrary JupyterLab commands - including arbitrary code execution - on a single user click, without any code being submitted for execution by the user. Impact An attacker who shares a notebook or a Markdown file - via email, GitHub, or a Binder link - can invoke an arbitrary command upon a single click by the victim. The button can be rendered inside the output area and be visually indistinguishable from a legitimate widget. No kernel needs to start; the HTML output is stored in the notebook file and displayed immediately on open. Single-click impact An attacker convincing the victim to click on a single button or link…
Recommended action: Upgrade to 7.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A stored Cross-Site Scripting (XSS) vulnerability in Jupyter Notebook allows attackers to steal authentication tokens from users who open malicious notebook files and interact with elements that the attacker can make look indistinguishable from legitimate controls (single click interaction). The vulnerability enables complete account takeover through the Jupyter REST API, allowing the attacker to: 1. Read all files 2. Modify/create files 3. Access running kernels and execute arbitrary code 4. Create terminals for shell access Patches Jupyter Notebook 7.5.6 and JupyterLab 4.5.7 include patches for this vulnerability. Workarounds The help extension can be disabled via CLI: Hardening The patched versions include a toggle to disable the command linker functionality altogether, for example via overrides.json: Resources - https://jupyterlab.readthedocs.io/en/latest/user/commands.html#commands-in-markdown-output-and-files Acknowledgments Reported by Daniel Teixeira - NVIDIA AI Red Team
Recommended action: Upgrade to 7.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature. A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user. Patches JupyterLab v3.6.8, v4.2.5 and Jupyter Notebook v7.2.2 were patched. Workarounds There is no workaround for the underlying DOM Clobbering susceptibility. However, select plugins can be disabled on deployments which cannot update in a timely fashion to minimise the risk. These are: - @jupyterlab/mathjax-extension:plugin - users will loose ability to preview mathematical equations - @jupyterlab/markdownviewer-extension:plugin - users will loose ability to open Markdown previews - @jupyterlab/mathjax2-extension:plugin (if installed with optional jupyterlab-mathjax2 package) - an older version of the mathjax plugin for JupyterLab 4.x To disable these extensions run: To confirm that the…
Recommended action: Upgrade to 7.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users of JupyterLab who click on a malicious link may get their Authorization and XSRFToken tokens exposed to a third party when running an older jupyter-server version. Patches JupyterLab 4.1.0b2, 4.0.11, and 3.6.7 were patched. Workarounds No workaround has been identified, however users should ensure to upgrade jupyter-server to version 2.7.2 or newer which includes a redirect vulnerability fix. References Vulnerability reported by user @davwwwx via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.
Recommended action: Upgrade to 7.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature. A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user. Patches JupyterLab v4.0.11 was patched. Workarounds Users can either disable the table of contents extension by running: References Vulnerability reported via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.
Recommended action: Upgrade to 7.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? Authenticated requests to the notebook server with ContentsManager.allowhidden = False only prevented listing the contents of hidden directories, not accessing individual hidden files or files in hidden directories (i.e. hidden files were 'hidden' but not 'inaccessible'). This could lead to notebook configurations allowing authenticated access to files that may reasonably be expected to be disallowed. Because fully authenticated requests are required, this is of relatively low impact. But if a server's root directory contains sensitive files whose only protection from the server is being hidden (e.g. ~/.ssh while serving $HOME), then any authenticated requests could access files if their names are guessable. Such contexts also necessarily have full access to the server and therefore execution permissions, which also generally grants access to all the same files. So this does not generally result in any privilege escalation or…
Recommended action: Upgrade to 6.4.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The editor in IPython Notebook before 3.2.2 and Jupyter Notebook 4.0.x before 4.0.5 allows remote attackers to execute arbitrary JavaScript code via a crafted file, which triggers a redirect to files/, related to MIME types.
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site scripting (XSS) vulnerability in the file browser in notebook/notebookapp.py in IPython Notebook before 3.2.2 and Jupyter Notebook 4.0.x before 4.0.5 allows remote attackers to inject arbitrary web script or HTML via a folder name. NOTE: this was originally reported as a cross-site request forgery (CSRF) vulnerability, but this may be inaccurate.
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An XSSI (cross-site inclusion) vulnerability in Jupyter Notebook before 5.7.6 allows inclusion of resources on malicious pages when visited by users who are authenticated with a Jupyter server. Access to the content of resources has been demonstrated with Internet Explorer through capturing of error messages, though not reproduced with other browsers. This occurs because Internet Explorer's error messages can include the content of any invalid JavaScript that was encountered.
Recommended action: Upgrade to 5.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Anytime a 5xx error is triggered, the auth cookie and other header values are recorded in Jupyter server logs by default. Considering these logs do not require root access, an attacker can monitor these logs, steal sensitive auth/cookie information, and gain access to the Jupyter server. Upgrade to notebook version 6.4.10 For more information If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org. Credit: @3coins for reporting. Thank you!
Recommended action: Upgrade to 6.4.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Untrusted notebook can execute code on load. This is a remote code execution, but requires user action to open a notebook. Patches 5.7.11, 6.4.1 References OWASP Page on Injection Prevention For more information If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org. Credit: Guillaume Jeanne from Google Example: A notebook with the following content in a cell and it would display an alert when opened for the first time in Notebook (in an untrusted state):
Recommended action: Upgrade to 6.4.1 or 5.7.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Untrusted notebook can execute code on load. This is a remote code execution, but requires user action to open a notebook. Patches Patched in the following versions: 3.1.4, 3.0.17, 2.3.2, 2.2.10, 1.2.21. References OWASP Page on Restricting Form Submissions For more information If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org. Credit: Guillaume Jeanne from Google
Recommended action: Upgrade to 6.4.1 or 5.7.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? Open redirect vulnerability - a maliciously crafted link to a notebook server could redirect the browser to a different website. All notebook servers are technically affected, however, these maliciously crafted links can only be reasonably made for known notebook server hosts. A link to your notebook server may appear safe, but ultimately redirect to a spoofed server on the public internet. Patches Has the problem been patched? What versions should users upgrade to? Patched in notebook 6.1.5 References OWASP page on open redirects For more information If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org. Credit: zhuonan li of Alibaba Application Security Team
Recommended action: Upgrade to 6.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jupyter Notebook before 5.5.0 does not use a CSP header to treat served files as belonging to a separate origin. Thus, for example, an XSS payload can be placed in an SVG document.
Recommended action: Upgrade to 5.5.0rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Jupyter Notebook before 5.7.8, an open redirect can occur via an empty netloc. This issue exists because of an incomplete fix for CVE-2019-10255.
Recommended action: Upgrade to 5.7.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An Open Redirect vulnerability for all browsers in Jupyter Notebook before 5.7.8 and some browsers (Chrome, Firefox) in JupyterHub before 0.9.6 allows crafted links to the login page, which will redirect to a malicious site after successful login. Servers running on a baseurl prefix are not affected.
Recommended action: Upgrade to 5.7.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jupyter Notebook before 5.7.2 allows XSS via a crafted directory name because notebook/static/tree/js/notebooklist.js handles certain URLs unsafely.
Recommended action: Upgrade to 5.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jupyter Notebook before 5.7.1 allows XSS via an untrusted notebook because nbconvert responses are considered to have the same origin as the notebook server. In other words, nbconvert endpoints can execute JavaScript with access to the server API. In notebook/nbconvert/handlers.py, NbconvertFileHandler and NbconvertPostHandler do not set a Content Security Policy to prevent this.
Recommended action: Upgrade to 5.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Jupyter Notebook before 5.4.1, a maliciously forged notebook file can bypass sanitization to execute JavaScript in the notebook context. Specifically, invalid HTML is 'fixed' by jQuery after sanitization, making it dangerous.
Recommended action: Upgrade to 5.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.