CVE-2024-28233

### 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"`

JupyterHub is an open source multi-user server for Jupyter notebooks. 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 full access to JupyterHub API and user's single-user server. The affected configurations are single-origin JupyterHub deployments and JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. This vulnerability is fixed in 4.1.0.

### 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"`