Filtered by vendor Jupyter
Subscribe
Total
38 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2021-32797 | 1 Jupyter | 1 Jupyterlab | 2024-11-21 | 6.8 MEDIUM | 7.4 HIGH |
JupyterLab is a user interface for Project Jupyter which will eventually replace the classic Jupyter Notebook. In affected versions untrusted notebook can execute code on load. In particular JupyterLab doesn’t sanitize the action attribute of html `<form>`. Using this it is possible to trigger the form validation outside of the form itself. This is a remote code execution, but requires user action to open a notebook. | |||||
CVE-2020-36191 | 1 Jupyter | 1 Jupyterhub | 2024-11-21 | 3.5 LOW | 4.5 MEDIUM |
JupyterHub 1.1.0 allows CSRF in the admin panel via a request that lacks an _xsrf field, as demonstrated by a /hub/api/user request (to add or remove a user account). | |||||
CVE-2020-26275 | 1 Jupyter | 1 Jupyter Server | 2024-11-21 | 5.8 MEDIUM | 6.1 MEDIUM |
The Jupyter Server provides the backend (i.e. the core services, APIs, and REST endpoints) for Jupyter web applications like Jupyter notebook, JupyterLab, and Voila. In Jupyter Server before version 1.1.1, an open redirect vulnerability could cause the jupyter server to redirect the browser to a different malicious website. All jupyter servers running without a base_url prefix are technically affected, however, these maliciously crafted links can only be reasonably made for known jupyter server hosts. A link to your jupyter server may *appear* safe, but ultimately redirect to a spoofed server on the public internet. This same vulnerability was patched in upstream notebook v5.7.8. This is fixed in jupyter_server 1.1.1. If upgrade is not available, a workaround can be to run your server on a url prefix: "jupyter server --ServerApp.base_url=/jupyter/". | |||||
CVE-2020-26250 | 1 Jupyter | 1 Oauthenticator | 2024-11-21 | 3.5 LOW | 6.3 MEDIUM |
OAuthenticator is an OAuth login mechanism for JupyterHub. In oauthenticator from version 0.12.0 and before 0.12.2, the deprecated (in jupyterhub 1.2) configuration `Authenticator.whitelist`, which should be transparently mapped to `Authenticator.allowed_users` with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as `GitHubOAuthenticator.org_whitelist` are **not** affected. All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the `admin.whitelist.users` configuration in the jupyterhub helm chart or the `c.Authenticator.whitelist` configuration directly. Users of other deprecated configuration, e.g. `c.GitHubOAuthenticator.team_whitelist` are **not** affected. If you see a log line like this and expect a specific list of allowed usernames: "[I 2020-11-27 16:51:54.528 JupyterHub app:1717] Not using allowed_users. Any authenticated user will be allowed." you are likely affected. Updating oauthenticator to 0.12.2 is recommended. A workaround is to replace the deprecated `c.Authenticator.whitelist = ...` with `c.Authenticator.allowed_users = ...`. If any users have been authorized during this time who should not have been, they must be deleted via the API or admin interface, per the referenced documentation. | |||||
CVE-2020-26232 | 1 Jupyter | 1 Jupyter Server | 2024-11-21 | 5.5 MEDIUM | 4.1 MEDIUM |
Jupyter Server before version 1.0.6 has an Open redirect vulnerability. A maliciously crafted link to a jupyter server could redirect the browser to a different website. All jupyter servers are technically affected, however, these maliciously crafted links can only be reasonably made for known jupyter server hosts. A link to your jupyter server may appear safe, but ultimately redirect to a spoofed server on the public internet. | |||||
CVE-2020-26215 | 2 Debian, Jupyter | 2 Debian Linux, Notebook | 2024-11-21 | 5.8 MEDIUM | 4.4 MEDIUM |
Jupyter Notebook before version 6.1.5 has an 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. The issue is patched in version 6.1.5. | |||||
CVE-2019-9644 | 1 Jupyter | 1 Notebook | 2024-11-21 | 4.3 MEDIUM | 5.4 MEDIUM |
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. | |||||
CVE-2019-10856 | 1 Jupyter | 1 Notebook | 2024-11-21 | 5.8 MEDIUM | 6.1 MEDIUM |
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. | |||||
CVE-2019-10255 | 1 Jupyter | 2 Jupyterhub, Notebook | 2024-11-21 | 5.8 MEDIUM | 6.1 MEDIUM |
An Open Redirect vulnerability for all browsers in Jupyter Notebook before 5.7.7 and some browsers (Chrome, Firefox) in JupyterHub before 0.9.5 allows crafted links to the login page, which will redirect to a malicious site after successful login. Servers running on a base_url prefix are not affected. | |||||
CVE-2018-8768 | 1 Jupyter | 1 Notebook | 2024-11-21 | 6.8 MEDIUM | 7.8 HIGH |
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. | |||||
CVE-2018-7206 | 1 Jupyter | 1 Oauthenticator | 2024-11-21 | 6.5 MEDIUM | 8.8 HIGH |
An issue was discovered in Project Jupyter JupyterHub OAuthenticator 0.6.x before 0.6.2 and 0.7.x before 0.7.3. When using JupyterHub with GitLab group whitelisting for access control, group membership was not checked correctly, allowing members not in the whitelisted groups to create accounts on the Hub. (Users were not allowed to access other users' accounts, but could create their own accounts on the Hub linked to their GitLab account. GitLab authentication not using gitlab_group_whitelist is unaffected. No other Authenticators are affected.) | |||||
CVE-2018-21030 | 1 Jupyter | 1 Notebook | 2024-11-21 | 5.0 MEDIUM | 5.3 MEDIUM |
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. | |||||
CVE-2018-19352 | 1 Jupyter | 1 Notebook | 2024-11-21 | 4.3 MEDIUM | 6.1 MEDIUM |
Jupyter Notebook before 5.7.2 allows XSS via a crafted directory name because notebook/static/tree/js/notebooklist.js handles certain URLs unsafely. | |||||
CVE-2018-19351 | 1 Jupyter | 1 Notebook | 2024-11-21 | 4.3 MEDIUM | 6.1 MEDIUM |
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. | |||||
CVE-2015-7337 | 2 Ipython, Jupyter | 2 Notebook, Notebook | 2024-11-21 | 6.8 MEDIUM | N/A |
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. | |||||
CVE-2015-6938 | 4 Fedoraproject, Ipython, Jupyter and 1 more | 4 Fedora, Notebook, Notebook and 1 more | 2024-11-21 | 4.3 MEDIUM | N/A |
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. | |||||
CVE-2024-43805 | 1 Jupyter | 2 Jupyterlab, Notebook | 2024-08-30 | N/A | 6.1 MEDIUM |
jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. This 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. JupyterLab v3.6.8, v4.2.5 and Jupyter Notebook v7.2.2 have been patched to resolve this issue. Users are advised to upgrade. 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: 1. `@jupyterlab/mathjax-extension:plugin` - users will loose ability to preview mathematical equations. 2. `@jupyterlab/markdownviewer-extension:plugin` - users will loose ability to open Markdown previews. 3. `@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: ```jupyter labextension disable @jupyterlab/markdownviewer-extension:plugin && jupyter labextension disable @jupyterlab/mathjax-extension:plugin && jupyter labextension disable @jupyterlab/mathjax2-extension:plugin ``` in bash. | |||||
CVE-2024-41942 | 1 Jupyter | 1 Jupyterhub | 2024-08-12 | N/A | 7.2 HIGH |
JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to versions 4.1.6 and 5.1.0, if a user is granted the `admin:users` scope, they may escalate their own privileges by making themselves a full admin user. The impact is relatively small in that `admin:users` is already an extremely privileged scope only granted to trusted users. In effect, `admin:users` is equivalent to `admin=True`, which is not intended. Note that the change here only prevents escalation to the built-in JupyterHub admin role that has unrestricted permissions. It does not prevent users with e.g. `groups` permissions from granting themselves or other users permissions via group membership, which is intentional. Versions 4.1.6 and 5.1.0 fix this issue. |