Jupyter Server is the backend for Jupyter web applications. Prior to 2.20, the nbconvert HTTP handlers in jupyterserver 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 displaydata output triggers stored XSS with cookie access, full /api/ authority, and kernel RCE. This vulnerability is fixed in 2.20.
Summary
Jupyter Server <=2.17.0 can access directories sibling to the root directory, if it starts with the root dir's name.
PoC
Minimal:
. ├── test/ <- root directory. │ └── test.txt └── testtest/ └── secret.txt <- file to exfiltrate that we should not be able to access via API
bash HOST="http://localhost:8888" TOKEN="" SIBLING="testtest" TARGET="secret.txt"
curl -s -X POST \ "$HOST/api/contents/%2e%2e/$SIBLING/$TARGET/checkpoints" \ -H "Authorization: token $TOKEN"
Full PoC by @stef41: https://gist.github.com/Yann-P/66d4982a965dee8fcb8dd89db29e7006
Impact
It is possible for an authenticated user to access content outside the server's rootdir in siblings directories sharing the same prefix as the rootdir. The attacker can escalate access, reading, writing, and deleting from sibling directories.
This can have a tangible impact for deployments using predictable naming scheme with multi-tenant server, for example user1, user2, user3, ..., user10 etc, as user1 could access and modify files of all user10 - user19 and higher.
In a hypothetical system where users can choose a name of their folder, an attacker could choose a single-letter username to gain access to a significant number of sibling directories.
Workarounds
Use folder names that do not overlap.
Acknowledgments
Thank you to @stef41 for providing a useful PoC.
Summary
A persistent cookie secret vulnerability allows authenticated users to maintain indefinite access even after password changes.
The cookie secret used to sign authentication cookies is stored in a permanent file (~/.local/share/jupyter/runtime/jupytercookiesecret) that is never automatically rotated or cleared, allowing stolen or compromised cookies to remain valid indefinitely regardless of password resets.
PoC
- Start a Jupyter server with password authentication: jupyter server password, jupyter server - Log in with the password and capture the authentication cookie (e.g., just login with a browser). - Change the password to revoke access: jupyter server password - Restart the server - Use the old stolen cookie => remains valid and provides full authenticated access.
Impact
- All jupyter-server deployments using password authentication where security incidents may occur - Multi-user systems where one user's compromised session should be revocable by administrators - Shared or public-facing Jupyter servers where credential rotation is a security requirement - Any deployment where password changes are expected to revoke existing sessions
Patches
Jupyter Server 2.18+
Workaround
bash rm ~/.local/share/jupyter/runtime/jupytercookiesecret Then restart the server
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 alloworiginpat 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.
A path traversal vulnerability exists in jupyter-server version 2.17.0 due to an incorrect root directory boundary check in the getospath() function within jupyterserver/services/contents/fileio.py. The check uses startswith(root) without appending a trailing path separator, allowing sibling directories with names starting with the same prefix as rootdir to bypass the check. Additionally, the toospath() function in utils.py does not strip ".." from path parts, enabling traversal sequences to bypass the vulnerable check. This vulnerability can lead to unauthorized read/write access to files in sibling directories, potentially exposing sensitive data in shared hosting environments.
A vulnerability in jupyter-server versions 1.12.0 through 2.17.0 allows an attacker to bypass CORS origin validation when the alloworiginpat configuration is used. The issue arises from the use of re.match() for validating the Origin header, which only anchors at the start of the string. This allows attacker-controlled domains such as trusted.example.com.evil.com to pass validation against patterns intended to match trusted.example.com. The vulnerability affects multiple locations in the codebase, including CORS headers, WebSocket connections, referer validation, and login redirects, potentially enabling phishing attacks, arbitrary code execution, and unauthorized access to sensitive API responses.
Jupyter Server is the backend for Jupyter web applications. Prior to 2.20, the nbconvert HTTP handlers in jupyterserver 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 displaydata output triggers stored XSS with cookie access, full /api/ authority, and kernel RCE. This vulnerability is fixed in 2.20.
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 rootdir and access sibling directories whose names begin with the same prefix as the rootdir. For example, with a rootdir 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.
Summary
The ?next=... URL query parameter has an open redirection vulnerability. In jupyterserver<=2.17.0, this URL query parameter allows redirection to arbitrary external domains, which can be exploited to facilitate phishing attacks on server users.
Details
The vulnerability is caused by insufficient validation in the LoginFormHandler.redirectsafe() method.
- Source code reference: https://github.com/jupyter-server/jupyterserver/blob/987ebdd5e188cdc49751b01a0d6782d686492a53/jupyterserver/auth/login.py#L33-L76
This vulnerability was originally reported by Noriaki Iwasaki. All discovery credit goes to them.
PoC
1. Navigate to http://localhost:8888/login?next=///google.com 2. Observe that the user is redirected to google.com despite it being an external domain.
The external domain passed in the ?next parameter may be replaced with a malicious lookalike to facilitate phishing attacks. Jupyter Server deployments served on a public domain are especially vulnerable, as prod.company.com may be redirected to a look-alike URL such as prod.company.dev.
Impact
This vulnerability affects all users, especially enterprise users who work with sensitive/confidential data.
Patches
Jupyter Server 2.18+
Workaround
None.