A path traversal vulnerability (CWE-22) exists in jupyter nbconvert's ExtractOutputPreprocessor from versions 5.4.0 up to but not including 7.17.2. This flaw allows an attacker to craft a malicious notebook that, when converted using certain exporters, can write output files to arbitrary locations accessible by the victim. The issue is fixed in version 7.17.2.
### Summary
Jupyter Server's gateway WebSocket handler checks that a user is authenticated, but it does not ask the configured Authorizer whether that user may execute kernels.
In Jupyter Server 2.0.0 through 2.5.0, enabling GatewayClient.url automatically replaced the normal kernel channel handler with this gateway-specific handler. An authenticated user who is denied the `execute` action on the `kernels` resource can therefore still open a kernel channel and send messages to the upstream kernel.
### Details
The normal handler performs the expected authorization check before creating the WebSocket connection:
https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/services/kernels/websocket.py#L39-L47
The gateway handler only checks `current_user` and then opens the upstream channel. It never calls `authorizer.is_authorized(...)`:
https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/gateway/handlers.py#L49-L75
https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/gateway/handlers.py#L87-L98
Gateway mode selected that handler automatically by replacing handlers with matching routes:
https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/serverapp.py#L437-L446
PR #1261 stopped replacing the normal handler and routed gateway traffic through `GatewayWebSocketConnection` instead. This appears to have fixed the default gateway configuration in 2.6.0, although the deprecated handler is still present in current releases and can still be registered directly.
https://github.com/jupyter-server/jupyter_server/pull/1261
### Code-level validation
1. Configure a custom Authorizer that returns false for `execute` on `kernels` for a regular authenticated user.
2. Configure `GatewayClient.url` on Jupyter Server 2.0.0-2.5.0.
3. The normal `KernelWebsocketHandler` would reject that user with 403 in `pre_get`.
4. Gateway mode replaces it with `WebSocketChannelsHandler`. Its `authenticate` method only rejects anonymous users, and `get` proceeds to the upstream gateway without an authorization decision.
### Impact
This is a missing authorization check, not an authentication bypass. It matters in deployments that use a restrictive custom Authorizer and Jupyter Gateway/Enterprise Gateway. A read-only or otherwise limited authenticated user can cross the intended authorization boundary and obtain kernel execution, with access to data and credentials available to that kernel.
### Affected versions
- Default gateway configuration: 2.0.0 through 2.5.0
- 2.6.0 and later: the default path uses the authorized standard handler, but manually registering the deprecated `jupyter_server.gateway.handlers` module still exposes the old behavior.
Jupyter Server versions prior to 2.21.0 contain a vulnerability where the Referer header is logged without scrubbing sensitive tokens during 5xx error responses. This can lead to sensitive tokens being stored in plaintext in server logs. An attacker with access to these logs could recover tokens and gain the affected user's permissions. The issue is fixed in version 2.21.0.
nbviewer through 1.0.1 contains a path traversal vulnerability in LocalFileHandler.can_show() that uses string-prefix comparison instead of proper path validation. Attackers can read files from sibling directories outside the configured root by requesting paths that share the root as a textual prefix, disclosing unintended notebooks and credentials.
Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters like Apache Spark, Kubernetes, and Docker Swarm. In versions prior to 3.3.0, the server interpolates untrusted environment variables (e.g., KERNEL_XXX) into Kubernetes manifests without YAML-aware escaping, enabling YAML injection attacks. Attackers can inject new fields, overwrite critical fields (e.g., duplicate securityContext keys, where the last one prevails), and inject document boundaries (--- for new documents, ... for end-of-document) to generate multiple resources, potentially creating arbitrary types, such as privileged pods. The Jinja2 template for the Kubernetes manifest contains several kernel_xxx variables, such as kernel_working_dir that are used when rendering the manifest and are all vectors for YAML injection. This issue has been fixed in version 3.3.0.
Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters like Apache Spark, Kubernetes, and Docker Swarm. In versions 2.0.0rc2 and above, prior to 3.3.0, the environment variables (KERNEL_XXX) used during the rendering of the Kubernetes manifest are vulnerable to Server Side Template Injection (SSTI). By including Jinja2 template expressions it is possible to execution Python code and OS Commands in the Enterprise Gateway service. The code can use or steal the Kubernetes service account token, which can steal Kubernetes secrets and be used to fully compromise the Kubernetes cluster by scheduling a privileged pod or a pod with a hostPath volume mount. This issue has been fixed in version 3.3.0.
Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters like Apache Spark, Kubernetes, and Docker Swarm. Versions 2.0.0rc1 and above prior to 3.3.0 have a prohibited UID and GID feature that by default prevents launching kernels with UID or GID 0 (root), and this restriction can be bypassed using a specially crafted KERNEL_UID or KERNEL_GID value. This input validation vulnerability allows running Jupyter kernels as root, which can be dangerous as it allows more attack surface, and may lead to container escapes, compromising the worker node and all workloads running on it. Repeated exploitation can compromise all worker nodes, and thus the entire Kubernetes cluster. It is possible to specify volume mounts, so one vector for a container escape is to use a hostPath R/W volume mount, use this UID/GID bypass to run as root, and then gain code execution in the underlying worker node by creating a crontab entry in the mounted host file system. This issue has been fixed in version 3.0.0.
JupyterLab Git is a Git extension for JupyterLab. Prior to 0.54.0, jupyterlab-git uses fnmatch.fnmatchcase() in GitHandler.prepare() in jupyterlab_git/handlers.py to enforce excluded_paths, allowing an authenticated user on a case-insensitive filesystem to vary URL path casing and read excluded directories. This issue is fixed in version 0.54.0.
Overview
Amazon Web Services (AWS) Security has identified a stored cross-site scripting (XSS) issue in the jupyterlab-git JupyterLab extension that can lead to remote code execution (RCE). The issue exists in the PlainTextDiff.ts component, where the createHeader() method passes Git filenames directly to innerHTML without sanitization when rendering diffs for renamed files in commit history. This allows an adversary to craft a filename containing arbitrary HTML/JavaScript that executes when another user views the rename diff in the Git History tab.
The issue can be leveraged through the rename history view in the JupyterLab Git panel. An adversary creates a file with a crafted filename containing a JavaScript payload (e.g., <img src=x onerror=eval(atob("base64_payload"))>.py), renames the file in a subsequent commit, and pushes to a shared repository. When a victim clones the repository, navigates to the Git History tab, clicks the rename commit, and then clicks the renamed file to view the diff, the unsanitized filename renders via innerHTML, executing arbitrary JavaScript in the victim's browser session. The injected JavaScript reads the xsrf cookie, opens a JupyterLab terminal via POST /api/terminals, connects via WebSocket, and executes arbitrary shell commands — achieving full RCE. An adversary can leverage this to exfiltrate secrets or credentials from the victim's environment.
Scope of impact
We discovered this issue during internal security testing. The issue is present in the default configuration of JupyterLab when the jupyterlab-git extension is installed.
The attack requires:
- The adversary to have commit access to a Git repository that the victim has cloned
- The victim to navigate to the Git History tab, click the rename commit, and click the renamed file to view the diff
The issue could allow an actor who has access to a shared Git repository to execute arbitrary JavaScript in another user's JupyterLab environment by committing a file with a crafted filename, potentially leading to remote code execution with access to user code, data, environment variables, and credentials.
Proof of concept
The issue exists in the createHeader() method where filenames from rename history are passed directly to innerHTML without sanitization:
[1] https://github.com/jupyterlab/jupyterlab-git/blob/main/src/components/diff/PlainTextDiff.ts#L214
Attack flow:
1. An adversary creates a file with a crafted filename containing a JavaScript payload, e.g., <img src=x onerror=eval(atob("base64_payload"))>.py
2. The adversary renames the file in a subsequent commit and pushes both commits to a shared Git repository
3. The victim clones or pulls the repository and navigates to the Git History tab in JupyterLab
4. The victim clicks the rename commit, then clicks the renamed file to view the diff
5. The createHeader() method constructs a diff header using string concatenation with the unsanitized filename and assigns the result to innerHTML
6. The injected JavaScript executes in the victim's browser session, reads the _xsrf cookie, sends a POST request to /api/terminals to open a JupyterLab terminal, connects via WebSocket, and executes arbitrary shell commands
Proof-of-concept mitigation
The issue can be mitigated by replacing innerHTML with textContent for filename rendering in the createHeader() method of PlainTextDiff.ts. Alternatively, proper HTML sanitization (escaping <, >, &, ", ') can be applied before inserting user-controlled filenames into the DOM.
A vulnerability in jupyter/nbconvert versions <= 7.17.0 allows for Cross-site Scripting (XSS) via unsanitized `text/vnd.mermaid` output in HTML exports. The `data_mermaid` block in `share/templates/lab/base.html.j2` renders `text/vnd.mermaid` cell output directly into HTML without escaping, enabling attackers to inject arbitrary HTML/JavaScript by breaking out of the `<pre>` tag. This vulnerability impacts any server using nbconvert to render notebooks as HTML, allowing attackers to execute arbitrary JavaScript in the context of users viewing the HTML export.
Jupyter Server is the backend for Jupyter web applications. Prior to 2.20, the nbconvert HTTP handlers in jupyter_server render user-authored notebook HTML under the Jupyter origin without a sandbox directive in their Content-Security-Policy. Combined with nbconvert.HTMLExporter's default non-sanitizing behavior, a notebook carrying an HTML payload in a display_data output triggers stored XSS with cookie access, full /api/* authority, and kernel RCE. This vulnerability is fixed in 2.20.
CVE-2026-6657 is a medium severity vulnerability in jupyter-server versions 1.12.0 through 2.17.0 that allows bypassing of CORS origin validation when the allow_origin_pat configuration is used. The issue stems from improper use of re.match() for Origin header validation, which only anchors at the start of the string, enabling attacker-controlled domains that mimic trusted domains to bypass checks. This affects multiple code locations including CORS headers, WebSocket connections, referer validation, and login redirects, potentially leading to phishing, unauthorized access, and arbitrary code execution.
CVE-2026-5422 is a path traversal vulnerability in jupyter-server version 2.17.0 caused by improper root directory boundary checks in path handling functions. This flaw allows attackers to bypass directory restrictions and access files in sibling directories, potentially exposing sensitive data in shared hosting environments. The vulnerability arises from a startswith check without a trailing path separator and failure to remove '..' path segments. No patch or official remediation is currently confirmed.
### 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:
```
jupyter labextension disable @jupyter-notebook/help-extension
jupyter labextension disable @jupyterlab/help-extension
```
### Hardening
The patched versions include a toggle to disable the command linker functionality altogether, for example via `overrides.json`:
```json
{
"@jupyterlab/apputils-extension:sanitizer": {
"allowCommandLinker": false
}
}
```
### 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
Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, the secret used to sign authentication cookies is persisted to a static file at ~/.local/share/jupyter/runtime/jupyter_cookie_secret and is never rotated when a user changes their password. After a password reset and server restart, any previously issued authentication cookie remains cryptographically valid because the signing key has not changed. An attacker who has captured a session cookie through any means retains full authenticated access to the server regardless of subsequent password changes. This affects deployments using password-based authentication, particularly shared or public-facing servers where credential rotation is expected to revoke existing sessions. This issue has been fixed in version 2.18.0.
Jupyter Server versions 2.17.0 and earlier contain a vulnerability in the Origin header validation logic. The server uses Python's re.match() function with a pattern that is not fully anchored, allowing origins that start with a trusted domain but have additional characters appended to bypass CORS restrictions. This enables an attacker controlling such a domain to make unauthorized cross-origin requests to the Jupyter Server API. The issue is fixed in version 2.18.0.
Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, a path traversal vulnerability in the REST API allows an authenticated user to escape the configured root_dir and access sibling directories whose names begin with the same prefix as the root_dir. For example, with a root_dir named "test", the API permits access to a sibling directory named "testtest" through a crafted request to the /api/contents endpoint using encoded path components. An attacker can read, write, and delete files in affected sibling directories. Multi-tenant deployments using predictable naming schemes are particularly at risk, as a user with a directory named "user1" could access directories for user10 through user19 and beyond. A user who can choose a single-character folder name could gain access to a significant number of sibling directories.
Version 2.18.0 contains a fix. As a workaround, ensure folder names do not share a common prefix with any sibling directory.
The backend for Jupyter web applications
Security Fix(es):
Jupyter Server is the backend for Jupyter web applications. In jupyter_server versions through 2.17.0, the next query parameter in the login flow is insufficiently validated in `LoginFormHandler._redirect_safe()`, which allows redirects to arbitrary external domains via values such as `///example.com`. An attacker can use a crafted login URL to redirect users to a malicious site and facilitate phishing attacks. This issue is fixed in version 2.18.0.(CVE-2025-61669)
Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, a path traversal vulnerability in the REST API allows an authenticated user to escape the configured root_dir and access sibling directories whose names begin with the same prefix as the root_dir. For example, with a root_dir named "test", the API permits access to a sibling directory named "testtest" through a crafted request to the /api/contents endpoint using encoded path components. An attacker can read, write, and delete files in affected sibling directories. Multi-tenant deployments using predictable naming schemes are particularly at risk, as a user with a directory named "user1" could access directories for user10 through user19 and beyond. A user who can choose a single-character folder name could gain access to a significant number of sibling directories.
Version 2.18.0 contains a fix. As a workaround, ensure folder names do not share a common prefix with any sibling directory.(CVE-2026-35397)
Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, the Origin header validation uses Python's re.match() to check incoming origins against the allow_origin_pat configuration value. Because re.match() only anchors at the start of the string and does not require a full match, a pattern intended to match only a trusted domain (e.g., trusted.example.com) will also match any origin that begins with that domain followed by additional characters (e.g., trusted.example.com.evil.com). An attacker who controls such a domain can bypass the CORS origin restriction and make cross-origin requests to the Jupyter Server API from an untrusted site. This issue has been fixed in version 2.18.0.(CVE-2026-40110)
Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, the secret used to sign authentication cookies is persisted to a static file at ~/.local/share/jupyter/runtime/jupyter_cookie_secret and is never rotated when a user changes their password. After a password reset and server restart, any previously issued authentication cookie remains cryptographically valid because the signing key has not changed. An attacker who has captured a session cookie through any means retains full authenticated access to the server regardless of subsequent password changes. This affects deployments using password-based authentication, particularly shared or public-facing servers where credential rotation is expected to revoke existing sessions. This issue has been fixed in version 2.18.0.(CVE-2026-40934)
A path traversal vulnerability exists in jupyter nbconvert versions 6.5 through 7.17.0 when the HTMLExporter.embed_images option is enabled. This flaw allows a malicious notebook to read arbitrary files from the host system by embedding them as base64 data URIs in the output HTML. The vulnerability is fixed in version 7.17.1. By default, HTMLExporter.
A path traversal vulnerability exists in jupyter nbconvert versions 6.5 through 7.17.0. The vulnerability arises from the ExtractAttachmentsPreprocessor component, which does not sanitize attachment filenames, allowing crafted filenames to write files outside the intended output directory. This enables an attacker to control the destination path and file extension of arbitrary files written to the filesystem. Version 7.17.1 includes a patch addressing this issue. The vulnerability has a medium severity with a CVSS score of 6.