CVE-2026-35397: Verified Repro With Script Download

Summary

CVE-2026-35397 is a path traversal vulnerability in jupyter-server caused by an improper root directory containment check. The _get_os_path method in jupyter_server/services/contents/fileio.py used a plain string startswith() comparison to verify that a requested file path lies within the configured root directory. Because startswith() matches string prefixes rather than path-component boundaries, a sibling directory whose name merely shares a prefix with the root directory (e.g., root=/tmp/data, sibling=/tmp/datasecret) would incorrectly pass the containment check when reached via a relative path traversal (e.g., ../datasecret/secret.txt). When ContentsManager.allow_hidden=True is set (or when other is_hidden checks are bypassed), this allows an attacker to read files outside the configured root via the HTTP /api/contents/ endpoint.

Impact

• Package: jupyter-server (PyPI)
• Affected versions: <= 2.17.0
• Fixed version: 2.18.0
• Risk level: High (CVSS 7.6)
• Consequences: Any client able to reach the Jupyter Server file/contents API can read arbitrary files located in directories whose absolute path strings start with the root directory path, when the sibling directory name shares a prefix with the root. This is a classic CWE-22 (Path Traversal) issue.

Root Cause

The vulnerable code was in jupyter_server/services/contents/fileio.py, method FileManagerMixin._get_os_path():

root = os.path.abspath(self.root_dir)
os_path = to_os_path(ApiPath(path), root)
if not (os.path.abspath(os_path) + os.path.sep).startswith(root):
    raise HTTPError(404, "%s is outside root contents directory" % path)

The bug: startswith(root) matches any path whose string representation begins with root. If root is /tmp/data, then /tmp/datasecret/secret.txt also starts with /tmp/data (string-wise), so the check passes even though datasecret is a completely different directory outside the root.

Fix commit: 2ee51eccf3ff2e27068cc0b7a39101eeedc4f665 Fix: Changed the check to startswith(root + os.path.sep):

if not (os.path.abspath(os_path) + os.path.sep).startswith(root + os.path.sep):
    raise HTTPError(404, "%s is outside root contents directory" % path)

Appending os.path.sep forces the match to occur at a path-component boundary, so /tmp/datasecret/... no longer matches /tmp/data/.

Reproduction Steps

1. Run repro/reproduction_steps.sh
2. The script:
   • Creates a virtualenv and installs jupyter-server==2.17.0
   • Creates a root directory (data/) and a prefix-sharing sibling directory (datasecret/) with a secret file inside it
   • Starts the Jupyter Server with ContentsManager.allow_hidden=True (this bypasses the is_hidden defense that would otherwise block the traversal before reaching _get_os_path)
   • Issues an HTTP GET to /api/contents/%2e%2e%2fdatasecret/secret.txt?content=1
   • Observes HTTP 200 with the secret file contents on the vulnerable version
   • Repeats with jupyter-server==2.18.0
   • Observes HTTP 404 on the fixed version

Expected evidence:

• Vulnerable (2.17.0): HTTP 200 with JSON response body containing "content": "SECRET CONTENT\n"
• Fixed (2.18.0): HTTP 404 with body file or directory '/../datasecret/secret.txt' does not exist

Evidence

Log files produced by the reproduction script:

• logs/vulnerable.log — Jupyter Server stdout/stderr for the 2.17.0 run
• logs/vulnerable_http_body.json — HTTP response body for the exploit request
• logs/vulnerable_manifest.json — runtime manifest capturing request URL, HTTP status, and file paths
• logs/fixed.log — Jupyter Server stdout/stderr for the 2.18.0 run
• logs/fixed_http_body.json — HTTP response body for the fixed version request
• logs/fixed_manifest.json — runtime manifest for the fixed version

Key excerpts from logs/vulnerable_http_body.json:

{"name": "secret.txt", "path": "../datasecret/secret.txt", "content": "SECRET CONTENT\n", ...}

HTTP status: 200

Key excerpts from logs/fixed_http_body.json:

file or directory '/../datasecret/secret.txt' does not exist

HTTP status: 404

Environment:

• Python 3.11.15
• pip 24.0
• Linux (x86_64)
• Jupyter Server 2.17.0 (vulnerable) and 2.18.0 (fixed)

Recommendations / Next Steps

1. Upgrade immediately to jupyter-server>=2.18.0.
2. Path containment checks should always use path-boundary-aware comparisons, not plain string prefix matching. In Python, pathlib.Path.is_relative_to() or appending os.path.sep to both sides of a startswith() check are reliable patterns.
3. Regression test: The fix commit already adds a pytest test (test_path_traversal_when_sibling_dir_starts_with_root_dir) that should be kept and run in CI.
4. Audit similar checks: Search the codebase for other uses of startswith() on filesystem paths that may have the same flaw.

Additional Notes

• Idempotency confirmed: The reproduction script was run twice consecutively and produced identical results (HTTP 200 on vulnerable, HTTP 404 on fixed).
• Edge case: The HTTP /api/contents/ endpoint is protected by an is_hidden check in jupyter_core.paths that uses Path.is_relative_to(). This check blocks the traversal BEFORE _get_os_path is reached when allow_hidden=False (the default). However, if a deployment sets ContentsManager.allow_hidden=True (e.g., to serve files in hidden directories), the is_hidden gate is bypassed and the buggy _get_os_path check becomes the only remaining defense — which fails due to the startswith() bug. This makes the vulnerability exploitable in real deployments that enable hidden file serving.
• The /files/ handler has the same is_hidden check, so it is similarly protected by default but becomes vulnerable when allow_hidden=True.