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
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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/jupyterserver/blob/v2.5.0/jupyterserver/services/kernels/websocket.py#L39-L47 The gateway handler only checks currentuser and then opens the upstream channel. It never calls authorizer.isauthorized(...): https://github.com/jupyter-server/jupyterserver/blob/v2.5.0/jupyterserver/gateway/handlers.py#L49-L75…
Recommended action: Upgrade to 2.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a request returns a 500, jupyterserver/log.py logs a small JSON block of request headers. The Referer header was copied into it as-is, so a token in the Referer URL ended up in the logs in plain text. Impact Anyone who can read the server logs can pick tokens out of these 500 entries. Tokens end up in the Referer during normal token-based login and launch flows. Affected: all versions before 2.21.0. PoC Any malformed request that returns a 500 works: The log shows the token twice, once raw and once redacted: Patches Fixed in 2.21.0 by 5251352. Header values are now scrubbed before the block is logged. Upgrade to 2.21.0 or later. Workarounds Limit who can read the server logs. If you can, avoid flows that put the token in the URL.
Recommended action: Upgrade to 2.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability exists in jupyter-server version 2.17.0 due to an incorrect root directory boundary check in the _get_os_path() function within jupyter_server/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 root_dir to bypass the check. Additionally, the to_os_path() 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.
Recommended action: Upgrade to 2.18.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact An authenticated victim who navigates to /nbconvert/html/<path containing attacker-authored output can have their token exfiltrated to another domain because it is executed in the Jupyter origin. Patches Fixed in v2.20.0, commit 6cbee8d Workarounds For deployments where editing the installed jupyterserver is impractical (containerized builds, read-only images), adding this to jupyterserverconfig.py has the same effect as the patch above without touching source files:
Recommended action: Upgrade to 2.20.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jupyter Server uses re.match() to validate the Origin header against the alloworiginpat configuration. Since re.match() only anchors at the start of the string, an attacker who controls a domain like http://trusted.example.com.evil.com/ passes validation against a pattern intended to match only trusted.example.com. Impact <=2.17.0 Patches 057869a327c46730afede3eab0ca2d2e3e74acea, 49b34392feaa97735b3b777e3baf8f22f2a14ed8 Workarounds Wrap your alloworiginpat value with ^ and $ References https://github.com/jupyter-server/jupyterserver/pull/603 https://docs.python.org/3/library/re.html#re.fullmatch https://docs.python.org/3/library/re.html#re.match
Recommended action: Upgrade to 2.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jupyter Server <=2.17.0 can access directories sibling to the root directory, if it starts with the root dir's name. PoC Minimal: 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…
Recommended action: Upgrade to 2.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jupyter Server on Windows has a vulnerability that lets unauthenticated attackers leak the NTLMv2 password hash of the Windows user running the Jupyter server. An attacker can crack this password to gain access to the Windows machine hosting the Jupyter server, or access other network-accessible machines or 3rd party services using that credential. Or an attacker perform an NTLM relay attack without cracking the credential to gain access to other network-accessible machines.
Recommended action: Upgrade to 2.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Unhandled errors in API requests include traceback information, which can include path information. There is no known mechanism by which to trigger these errors without authentication, so the paths revealed are not considered particularly sensitive, given that the requesting user has arbitrary execution permissions already in the same environment. Patches jupyter-server PATCHEDVERSION no longer includes traceback information in JSON error responses. For compatibility, the traceback field is present, but always empty. Workarounds None
Recommended action: Upgrade to 2.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Open Redirect Vulnerability. Maliciously crafted login links to known Jupyter Servers can cause successful login or an already logged-in session to be redirected to arbitrary sites, which should be restricted to Jupyter Server-served URLs. Patches Upgrade to Jupyter Server 2.7.2 Workarounds None. References Vulnerability reported by user davwwwx via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform. - https://blog.xss.am/2023/08/cve-2023-39968-jupyter-token-leak/
Recommended action: Upgrade to 2.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Improper cross-site credential checks on /files/ URLs could allow exposure of certain file contents, or accessing files when opening untrusted files via "Open image in new tab". Patches Jupyter Server 2.7.2 Workarounds Use lower performance --ContentsManager.fileshandlerclass=jupyterserver.files.handlers.FilesHandler, which implements the correct checks. References Upstream patch for CVE-2019-9644 was not applied completely, leaving part of the vulnerability open. Vulnerability reported by Tim Coen via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.
Recommended action: Upgrade to 2.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affects: Notebook and Lab between 6.4.0?(potentially earlier) and 6.4.11 (currently latest). Jupyter Server <=1.16.0. If I am correct about the responsible code it will affect Jupyter-Server 1.17.0 and 2.0.0a0 as well. Description: If notebook server is started with a value of rootdir that contains the starting user's home directory, then the underlying REST API can be used to leak the access token assigned at start time by guessing/brute forcing the PID of the jupyter server. While this requires an authenticated user session, this url can be used from an xss payload (as in CVE-2021-32798) or from a hooked or otherwise compromised browser to leak this access token to a malicious third party. This token can be used along with the REST API to interact with Jupyter services/notebooks such as modifying or overwriting critical files, such as .bashrc or .ssh/authorizedkeys, allowing a malicious user to read potentially sensitive data and possibly gain control of the impacted system.
Recommended action: Upgrade to 2.0.0a1 (pre-release) or 1.17.1 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? 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. Patches Has the problem been patched? What versions should users upgrade to? Upgrade to Jupyter Server version 1.15.4 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 1.15.4 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? Open redirect vulnerability - a maliciously crafted link to a jupyter server could redirect the browser to a different website. All jupyter servers running without a baseurl 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. Patches Has the problem been patched? What versions should users upgrade to? Patched in jupyterserver 1.1.1. If upgrade is not available, a workaround can be to run your server on a url prefix: 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: Yaniv Nizry from CxSCA group at Checkmarx
Recommended action: Upgrade to 1.1.1 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? 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. This originated in jupyter/notebook: https://github.com/jupyter/notebook/security/advisories/GHSA-c7vm-f5p4-8fqh Patches Has the problem been patched? What versions should users upgrade to? jupyterserver 1.0.6 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 1.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.