Jupyter Server (<= 2.17.0) — CraftedSignal Threat Feed

Jupyter Server Path Traversal Vulnerability

hello@craftedsignal.io — Tue, 05 May 2026 16:49:10 +0000

Jupyter Server, a widely used platform for interactive computing, has a path traversal vulnerability affecting versions 2.17.0 and earlier. This flaw stems from an inadequate startswith() check on the root directory, which fails to properly restrict access to sibling directories. An authenticated user can exploit this by crafting specific API requests to access content outside of the designated root_dir. This vulnerability is especially dangerous in multi-tenant server deployments using predictable naming schemes, such as user1, user2, etc., where one user could potentially access and modify files belonging to other users. The vulnerability was reported on May 5, 2026, and is identified as CVE-2026-35397. Defenders should prioritize patching and consider workarounds to prevent unauthorized access to sensitive data.

Attack Chain

An authenticated user logs into a vulnerable Jupyter Server instance.
The attacker identifies the root_dir of their Jupyter environment.
The attacker identifies a sibling directory that shares a prefix with the root_dir (e.g., if root_dir is test, a sibling directory might be testtest).
The attacker crafts a POST request to the /api/contents/ endpoint, using a path traversal sequence (%2e%2e/) followed by the sibling directory and the target file. For example: /api/contents/%2e%2e/testtest/secret.txt/checkpoints.
The Jupyter Server’s insufficient startswith() check allows the request to proceed without proper validation.
The attacker gains unauthorized access to the target file within the sibling directory.
The attacker can then read, write, or delete the accessed file, potentially escalating privileges or compromising sensitive data.
The attacker leverages this access to compromise other user accounts or the Jupyter Server instance.

Impact

Successful exploitation of this vulnerability allows an attacker to read, write, and delete files in directories sibling to the Jupyter Server’s root_dir. This can lead to privilege escalation, especially in multi-tenant environments. For instance, in systems with predictable naming schemes like user1, user2, …, user10, an attacker with access to user1 could modify files belonging to user10 - user19. The severity of this issue is heightened in scenarios where users can choose their folder names, as an attacker selecting a single-letter username could potentially compromise a significant number of sibling directories.

Recommendation

Upgrade to Jupyter Server version 2.17.1 or later to patch CVE-2026-35397.
Implement stricter validation and sanitization of user inputs, specifically for file paths, to prevent path traversal attacks.
Deploy the Sigma rule “Detect Jupyter Server Path Traversal Attempt” to monitor for suspicious API requests containing path traversal sequences.
Review and revise folder naming schemes to avoid overlapping names in multi-tenant environments, as suggested in the advisory workaround.

Jupyter Server CORS Origin Validation Bypass via Regex

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Jupyter Server, a web-based interactive development environment, is susceptible to a CORS (Cross-Origin Resource Sharing) bypass vulnerability. This flaw arises from the server’s reliance on the re.match() function in Python’s regular expression library for validating the Origin header against the configured allow_origin_pat. The re.match() function, unlike re.fullmatch(), only anchors the regex at the beginning of the string, not the end. Consequently, an attacker can craft a malicious domain, such as http://trusted.example.com.evil.com/, which will pass the regex validation if the allow_origin_pat is intended to match trusted.example.com. This vulnerability impacts Jupyter Server versions 2.17.0 and prior. The fix was implemented in pull request #603 and patched in commits 057869a327c46730afede3eab0ca2d2e3e74acea and 49b34392feaa97735b3b777e3baf8f22f2a14ed8. Successful exploitation allows an attacker to bypass CORS restrictions, potentially leading to unauthorized data access or actions on behalf of legitimate users.

Attack Chain

An attacker identifies a Jupyter Server instance running version 2.17.0 or earlier.
The attacker crafts a malicious website with a domain name designed to bypass the allow_origin_pat regex. For instance, if the intended origin is trusted.example.com, the attacker uses trusted.example.com.evil.com.
A victim user visits the attacker’s malicious website in their browser.
The malicious website sends a cross-origin HTTP request to the vulnerable Jupyter Server. The Origin header in the request is set to the attacker-controlled domain (trusted.example.com.evil.com).
The Jupyter Server receives the request and validates the Origin header against the allow_origin_pat configuration using re.match().
Due to the behavior of re.match(), the attacker’s origin passes the validation, as the regex only checks for a match at the beginning of the string.
The Jupyter Server processes the cross-origin request, effectively bypassing the intended CORS restrictions.
The attacker can then potentially perform unauthorized actions or access sensitive data within the Jupyter Server, as if the request originated from a trusted source.

Impact

Successful exploitation of this vulnerability allows attackers to bypass CORS restrictions on vulnerable Jupyter Server instances. This could lead to unauthorized access to sensitive data, modification of user settings, or execution of arbitrary code within the Jupyter environment, all performed under the guise of a legitimate user. The number of affected instances depends on the prevalence of vulnerable Jupyter Server versions and the use of misconfigured allow_origin_pat settings.

Recommendation

Upgrade Jupyter Server to a version greater than 2.17.0, which includes the fix for CVE-2026-40110.
As a workaround, wrap your allow_origin_pat configuration value with ^ and $ to ensure the regex matches the entire string, as suggested in the advisory.
Monitor web server logs for requests with Origin headers matching the pattern trusted.example.com.* (adjusting the trusted.example.com to your actual configured pattern) to detect potential exploitation attempts. Implement this detection using the provided Sigma rule targeting webserver logs.