Cross site scripting (XSS) in JupyterHub via Self-XSS leveraged by Cookie Tossing
High8.1CVE-2024-28233 · Published Mar 28, 2024 · updated Sep 10, 2026
### Impact Affected configurations: - Single-origin JupyterHub deployments - JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. By tricking a user into visiting a malicious subdomain, the attacker can achieve an XSS directly affecting the former's session. More precisely, in the context of JupyterHub, this XSS could achieve the following: - Full access to JupyterHub API and user's single-user server, e.g. - Create and exfiltrate an API Token - Exfiltrate all files hosted on the user's single-user server: notebooks, images, etc. - Install malicious extensions. They can be used as a backdoor to silently regain access to victim's session anytime. ### Patches To prevent cookie-tossing: - Upgrade to JupyterHub 4.1 (both hub and user environment) - enable per-user domains via `c.JupyterHub.subdomain_host = "https://mydomain.example.org"` - set `c.JupyterHub.cookie_host_prefix_enabled = True` to enable domain-locked cookies or, if available (applies to earlier JupyterHub versions): - deploy jupyterhub on its own domain, not shared with any other services - enable per-user domains via `...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| jupyterhub PyPI | < 4.1.0 | 4.1.0 |
Details and references
### Impact Affected configurations: - Single-origin JupyterHub deployments - JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. By tricking a user into visiting a malicious subdomain, the attacker can achieve an XSS directly affecting the former's session. More precisely, in the context of JupyterHub, this XSS could achieve the following: - Full access to JupyterHub API and user's single-user server, e.g. - Create and exfiltrate an API Token - Exfiltrate all files hosted on the user's single-user server: notebooks, images, etc. - Install malicious extensions. They can be used as a backdoor to silently regain access to victim's session anytime. ### Patches To prevent cookie-tossing: - Upgrade to JupyterHub 4.1 (both hub and user environment) - enable per-user domains via `c.JupyterHub.subdomain_host = "https://mydomain.example.org"` - set `c.JupyterHub.cookie_host_prefix_enabled = True` to enable domain-locked cookies or, if available (applies to earlier JupyterHub versions): - deploy jupyterhub on its own domain, not shared with any other services - enable per-user domains via `c.JupyterHub.subdomain_host = "https://mydomain.example.org"`
More Jupyter advisories
All Jupyter| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Aug 82024 | JupyterHub has a privilege escalation vulnerability with the `admin:users` scope | High7.2 | 4.1.6+1 more |
| Jul 162024 | JupyterLab extension template is a `copier` template for JupyterLab extensions | Critical9.8 | 4.3.0 |
| Jun 62024 | Jupyter server on Windows discloses Windows user password hash | High7.5 | 2.14.1 |
| Jan 192024 | JupyterLab vulnerable to potential authentication and CSRF tokens leak | High7.6 | 3.6.7+2 more |
| Jan 192024 | JupyterLab vulnerable to SXSS in Markdown Preview | Medium6.5 | 4.0.11+1 more |
| Dec 52023 | jupyter-server errors include tracebacks with path information | Medium4.3 | 2.11.2 |